مسئله: سندی که ده نفر همزمان ویرایشش میکنند، مکاننمای همدیگر را میبینند، و هیچوقت «متن ناپدید میشود». دشوارترین مسئله این فصل — جایی که CRDT های فصل ۱۴ بالاخره به مصرف میرسند.
۱-۲) نیازمندی و تخمین
- FR: ویرایش همزمان چند کاربر، دیدن تغییرات لحظهای، مکاننما/هایلایت دیگران، تاریخچه نسخه، کارکرد آفلاین و ادغام بعدی.
- NFR: تأخیر ارسال تغییر <100ms ،تحمل قطعی شبکه، سند بزرگ (صدها هزار کاراکتر) بدون کندی.
- چالش بنیادی: همزمانی بدون قفل؛ دو نفر همزمان در یک نقطه بنویسند — هر دو باید «برنده» باشند، نه یکی.
۳) طراحی — دو مکتب: OT و CRDT
| مکتب | ایده | قوت | قیمت |
|---|---|---|---|
| OT — Operational Transformation | سرور مرکزی عملیات را نسبت به هم «تبدیل» میکند تا به یک ترتیب واحد برسند | اثباتشده (Google Docs)، تاریخچه تمیز خطی | سرور تکنقطه هماهنگی؛ الگوریتم تبدیل پیچیده و شکننده |
| CRDT | ساختماندادهای که ادغام همزمانیها را ریاضیوار تعمیمی و بدون هماهنگکننده حل میکند | بدون سرور مرکزی، آفلایندوست (Figma ،Apple Notes) | متادیتای بزرگتر per کاراکتر، پیادهسازی ظریف |
DIAGRAMجریان یک تغییر
کلاینت — عملیات محلی فوری
→
WebSocket
→
سرور — ترتیبدهی/نویسندگی
→
پخش به بقیه
→
ذخیره async → DB
→
Snapshot دورهای
- Optimistic UI: تایپ تو فوراً روی صفحه خودت اعمال میشود و بعد به سرور میرود — منتظر RTT ماندن برای هر کلید یعنی مرگ تجربه.
- تفکیک «سند» از «رویداد»: تغییرها (ops) بهصورت الحاقی ذخیره میشوند و snapshot دورهای هزینه بازسازی را کم میکند — event sourcing فصل ۵ در خالصترین شکلش.
- مکاننماها داده فرّارند: اصلاً به DB نرو؛ pub/sub در حافظه (Redis) یا همان کانال WebSocket — اگر گم شود هم مهم نیست.
- آفلاین: تغییرات در صف محلی (IndexedDB) بمانند و هنگام اتصال، ادغام — CRDT این را طبیعی میکند، OT به سرورِ ترتیبده نیاز دارد.
۴) عمق و گلوگاه
- مقیاس اتصال: هر سند یک «اتاق»؛ مسیریابی WebSocket به گره مالک اتاق یا پخش از طریق Redis/Kafka — همان مسئله پیامرسان cs2 با گرانول کوچکتر.
- GC متادیتای CRDT: tombstone ها انباشته میشوند؛ فشردهسازی دورهای سند لازم است (همان فشردگی LSM، این بار برای کاراکترها).
- مجوز: سطح دسترسی (مشاهده/ویرایش) باید هم روی اتصال هم روی هر عملیات چک شود — دعوت لغوشده نباید هنوز بنویسد.
به زبان ساده
ویرایشگر مشترک یعنی جایی که تداخل نباید ممنوع شود بلکه باید قابل ادغام باشد: OT با سرور مرکزی عملیات را مرتب میکند، CRDT با ریاضیات ادغام را ذاتی میکند.
مثال واقعی
مثل ویرایش دستجمعی سرودنامه: بهجای اینکه فقط یک نفر قلم داشته باشد (قفل)، همه مینویسند و یک روش توافقشده (الگوریتم) نسخه نهایی را از همه دستخطها میسازد.