الفكرة
بدل ما كل أبلكيشن يحل أعطال الفصل اللي فات لوحده، بنبني abstractions بضمانات. أهمها consensus: النودز توافق على حاجة واحدة.
أغلب الداتابيزات المنسوخة بتدي eventual consistency، والأدق نسميها convergence: لو الكتابات وقفت، النسخ هتتساوى في وقت مش معروف. ضمان ضعيف. الأقوى ليه تمن في الأداء والـ availability.
Linearizability
السيستم يبان كأن فيه نسخة واحدة. أول ما كتابة تخلص، كل قراءة بعدها تشوف الجديد. مينفعش ترجع للقديم.
محتاجها لما: انتخاب leader أو lock (وإلا split brain)، أو uniqueness (يوزرنيم، تذكرة)، أو قناتين لازم يشوفوا نفس اللحظة (رفعت صورة وبعدين رسالة للـ thumbnail، والطابور أسرع من الـ replication فالخدمة تقرا صورة مش موجودة).
| الطريقة | Linearizable؟ |
|---|---|
| Single-leader | ممكن لو قريت من الـ leader. الـ async failover و split brain يكسرونها |
| Consensus (ZooKeeper, etcd) | أيوه. ده هدفها |
| Multi-leader | لأ. كتابات في أماكن مختلفة |
| Leaderless | غالبًا لأ حتى مع quorum. LWW بالساعات لأ |
CAP من غير الخلط
لو الشبكة اتقطعت بين مجموعتين، مش هتقدر تدي linearizability وتفضل ترد على الاتنين. تختار: ترد بداتا ممكن تكون قديمة (availability)، أو ترفض لحد ما تتفق (consistency بالمعنى الضيق: linearizability).
الـ CAP مش بيقول “الاختيار بين الاتساق والتوافر” بالمعنى التسويقي. هو عن linearizability وقت partition. أنظمة كتير مش linearizable أصلًا، وبرضه بتضحي بحاجات تانية. الجملة “اختر اتنين من تلاتة” بتضيّع التفاصيل.
الترتيب والسببية
الترتيب بيحافظ على السببية: السؤال قبل الجواب، والـ insert قبل الـ update. مش كل العمليات لازم تترتب على بعض. اللي مرتبطين بسبب يكفي.
الساعة الفيزيائية مش بتحفظ السببية كويس. Lamport clocks و version vectors بيحفظوا “مين حصل قبل مين” من غير ما تثق في ساعة الحائط. Total order broadcast: كل النودز تشوف نفس تسلسل الرسائل. ده قريب جدًا من consensus.
Consensus و 2PC
Consensus يعني: النودز تتفق على قيمة، والاتفاق نهائي، والقيمة دي قيمة حد اقترحها فعلًا. Raft و Zab (جوه ZooKeeper و etcd) بيعملوا كده: leader واحد، وأغلبية لازم توافق، والزومبي القديم مش بيكتب.
متكتبهاش بنفسك. استخدم ZooKeeper أو etcd لانتخاب الـ leader والـ locks والـ unique constraints الموزعة.