celld؛ اجرای مدل Durable Objects روی زیرساخت خودت
خلاصهٔ کاملتر
celld یه سیستم توزیعشدهٔ statefulه که به گفتهٔ سازندههاش کاملاً روی S3 سواره: ترکیبی از V8 و SQLite و LTX، یعنی همون فرمت رپلیکای Litestream که کار Ben Johnsonه. ایدهٔ اصلی اینه که مدل Durable Objects — یه آبجکت تکنخی با استوریج خودش که با اسم آدرسدهی میشه — دستنخورده بمونه، ولی جایگذاری و state و شواهد عملیاتی بره روی زیرساختی که خودت انتخاب کردی.
هماهنگی توش عمداً سادهست: خودِ باکت هماهنگکنندهست و خبری از پروتکل عضویت، تشخیصدهندهٔ خطا یا اجماع نیست. مالکیت هر سلول فقط یه رکورد تو باکت توئه که با یه نوشتن اتمیک و compare-and-swap گرفته میشه، و رپلیکاتور داخلی celld هم مدام وضعیت SQLite هر سلول رو به شکل سگمنتهای LTX به همون باکت میفرسته.
تیم celld سه چیز رو بهعنوان تفاوت اصلی برجسته میکنه. اول جایگذاری: هویت یه سلول به ماشین خاصی چسبیده نیست، پس با از دست رفتن یه نود، نود بعدی لیز رو میگیره و سلول رو ظرف چند ثانیه برمیگردونه. دوم دامنهٔ خرابی: هنوز به ماشینها و شبکه و ارائهدهندهٔ باکتت وابستهای، ولی دیگه یه زمانبند و لایهٔ جایگذاری مشترک، اپلیکیشن تو رو به بار کاری مشتری دیگه گره نمیزنه. سوم خوانایی: وقتی یه سلول بد رفتار میکنه، رکورد مالکیت و فایلهای SQLite و LTX و لاگها روی دیسک خودتن.
خودشون هم صریح میگن که self-hosting بهخودیخود قابلاعتمادتر نیست؛ چیزی که عوض میشه اینه که دامنهٔ خرابی صریح و قابلبازرسی میشه. لحن پروژه هم ضد Cloudflare نیست — حتی همین صفحه با یه Cloudflare Worker سرو میشه — و مدل Durable Objects رو کار Kenton Varda و تیم Workers میدونن و celld رو یه نامهٔ عاشقانه به همون ایده معرفی میکنن.
نکات کلیدی:
- celld مدل Durable Objects رو روی زیرساخت خودت اجرا میکنه
- ترکیبی از V8، SQLite و فرمت LTX (رپلیکای Litestream)
- باکت نقش هماهنگکننده رو داره؛ مالکیت با یه نوشتن اتمیک و compare-and-swap
- از دست رفتن یه نود یعنی گرفتن لیز توسط نود دیگه و بازیابی ظرف چند ثانیه
- شواهد خرابی روی دیسک خودته، نه پشت یه صفحهٔ وضعیت
