در فصل ۳ replication با Leader را دیدیم: یک نقطه تصمیمگیرنده برای نوشتن. خانواده دیگری هم هست — Leaderless: هر نود میتواند نوشتن بپذیرد. Cassandra و DynamoDB اینجاییاند؛ قیمتش، تعارض و کهنگی است و دراینش، دسترسپذیری بیوقفه نوشتن.
DIAGRAMنوشتن و خواندن با Quorum
Client
→
هر نود میپذیرد
→
W نسخه تأیید نوشتن
→
R نسخه برای خواندن
→
W+R > N → تازگی
چهار مکانیزم که Dynamo را Dynamo میکند
Sloppy Quorum
اگر نودهای مسئول یک کلید داوناند، نود دیگری موقتاً نوشتن را نگه میدارد — availability در هزینه سازگاری: «همیشه بنویس».
Hinted Handoff
نود موقت، رکورد را با «راهنما» نگه میدارد؛ وقتی نود اصلی برگشت، داده را تحویلش میدهد و پاک میکند.
Read Repair
هنگام خواندن، نودها پاسخهایشان را مقایسه میکنند؛ نسخه کهنهتر درجا بهروز میشود — خواندن، خودش ترمیم است.
Anti-Entropy + Merkle Tree
فرایند پسزمینه برای یافتن ناهماهنگی: درخت هش از داده؛ مقایسه ریشهها ناهماهنگی را در چند پرش پیدا میکند بدون کپی کل داده.
تعارض: بهای نوشتن همهجا
- دو کلاینت همزمان روی یک کلید در دو نود بنویسند → دو نسخه متعارض. راهها: Last-Write-Wins (ساده، ولی ممکن است داده را بیصدا حذف کند)، Vector Clock/Versioning برای تشخیص همزمانی، یا merge در سطح اپلیکیشن (سبد خرید Dynamo معروف است: اجتماع آیتمها).
- CRDT (فصل ۹) برای دادههایی که merge جبری دارند؛ برای بقیه، قانون دامنه بنویس نه LWW کورکورانه.
- Consistency Level را per-query میتوان تنظیم کرد: ONE سریع و کهنهمحتمل، QUORUM متعادل، ALL سختگیر — همان پنجره N/W/R فصل ۳ در عمل.
به زبان ساده
در مدل Dynamo هیچ رئیسی نیست؛ چند نسخه مینویسند و خواندن با رأیگیری (quorum) صحت میگیرد — اگر دو نسخه ناسازگار شدند، خودِ اپلیکیشن باید تصمیم بگیرد.
مثال واقعی
سبد خرید آمازون را هرگز «بهخاطر خرابی سرور» نمیبندند؛ هر نسخهای از سبد که رسید نگه میدارند و هنگام خواندن ادغام میکنند — فروش از سازگاری مهمتر است.