تحديات الأنظمة الموزعة

مقدمة

حين لا يكفي جهاز واحد، تبدأ المشكلات الحقيقية. الأنظمة الموزعة هي حجر أساس الإنترنت الحديث — من رسائل WeChat إلى الطلبات على Taobao، تعمل خلف الكواليس مئات أو حتى آلاف الأجهزة بشكل متعاون. لكن "التوزيع" ليس غداءً مجانيًا، فهو يجلب سلسلة من التحديات لم تواجهها الأنظمة أحادية الجهاز من قبل.

ماذا ستتعلم من هذه المقالة؟

بعد إتمام هذا الفصل، ستكتسب:

• النظريات الأساسية: فهم نظرية CAP وتأثيرها على تصميم النظام
• نماذج التناسق: التمييز بين التناسق القوي، والتناسق النهائي، والتناسق السببي
• التحديات الثمانية: إتقان المشكلات الجوهرية التي تواجه الأنظمة الموزعة
• خوارزميات الإجماع: التعرف على الأفكار الأساسية لخوارزميات الإجماع الموزعة مثل Paxos و Raft
• أنماط عملية: الإلمام بالحلول الشائعة مثل 2PC و Saga و CRDT

الفصل	المحتوى	المفاهيم الأساسية
الفصل 1	لماذا نحتاج الأنظمة الموزعة	القابلية للتوسع، التوافر، التوزيع الجغرافي
الفصل 2	نظرية CAP	التناسق، التوافر، التسامح مع الانقسام
الفصل 3	نماذج التناسق	تناسق قوي، تناسق نهائي، تناسق سببي
الفصل 4	التحديات الثمانية	الشبكة، الساعات، الانقسام، الانقسام الذهني، إلخ
الفصل 5	خوارزميات الإجماع	Paxos، Raft، ZAB
الفصل 6	المعاملات الموزعة	2PC، Saga، TCC

---

0. صورة شاملة: لماذا نحتاج الأنظمة الموزعة؟

الأنظمة أحادية الجهاز بسيطة وموثوقة، لكن لديها ثلاثة اختناقات لا يمكن تجاوزها:

الاختناق	الشرح	الحل بالتوزيع
الحد الأدنى للأداء	المعالج والذاكرة والقرص في جهاز واحد لها حدود فيزيائية	التوسع الأفقي: إضافة المزيد من الأجهزة لتقاسم الحمل
نقطة الفشل الوحيدة	إذا تعطل الجهاز، تتعطل الخدمة بالكامل	نسخ احتياطية متعددة: عدة أجهزة كنسخ احتياطي لبعضها
زمن الوصول الجغرافي	المستخدمون في مختلف أنحاء العالم، والجهاز الواحد في مكان واحد فقط	النشر متعدد المواقع: خدمة المستخدمين من أقرب موقع

ثمن التوزيع

تحل الأنظمة الموزعة المشكلات أعلاه، لكنها تُدخل تعقيدات جديدة: شبكة غير موثوقة، ساعات غير متزامنة، أعطال جزئية، تناسق البيانات... وهذه هي "التحديات" التي سنناقشها في هذه المقالة.

المغالطات الثمانية للحوسبة الموزعة لبيتر دويتش تخبرنا أن الافتراضات التالية خاطئة في البيئات الموزعة:

1. الشبكة موثوقة
2. زمن الوصول صفر
3. عرض النطاق الترددي غير محدود
4. الشبكة آمنة
5. الطوبولوجيا لا تتغير
6. هناك مسؤول واحد فقط
7. تكلفة النقل صفر
8. الشبكة متجانسة

---

1. نظرية CAP: "المثلث المستحيل" للأنظمة الموزعة

في عام 2000، طرح إريك بروير تخمين CAP (الذي أُثبت لاحقًا كنظرية): يمكن للنظام الموزع أن يلبي اثنين فقط من الخصائص الثلاث التالية في نفس الوقت على الأكثر.

الخاصية	المعنى	الفهم المبسط
Consistency (التناسق)	جميع العقد ترى نفس البيانات في نفس اللحظة	رصيدك في أي ماكينة صراف آلي يكون نفس الرقم
Availability (التوافر)	كل طلب يتلقى استجابة غير خاطئة	النظام يستجيب لك دائمًا، ولن يقول "الخدمة غير متاحة"
Partition tolerance (التسامح مع الانقسام)	يستمر النظام في العمل حتى عند انقسام الشبكة	حتى لو انقطعت بعض الكابلات، يظل النظام يعمل

CAP Theorem Interactive Demo

Select two properties to inspect the corresponding system type

C

Consistency

All nodes see the same data

A

Availability

Every request receives a response

P

Partition tolerance

The system keeps running during network partitions

CA system (gives up partition tolerance)

When there is no network partition, the system can provide both consistency and availability. In distributed environments, partitions are unavoidable, so pure CA systems are rare in practice.

Typical systems: Single-node MySQL, PostgreSQL in single-node mode

Sacrifices: Partition tolerance (P): unavailable during network failures

لماذا يمكن اختيار اثنين فقط؟

في البيئات الموزعة، انقسام الشبكة (P) أمر لا مفر منه — تُحفر الألياف الضوئية بالخطأ، وتتعطل المبدّلات، وتنفصل مراكز البيانات. لذا فإن P خيار إجباري، والاختيار الفعلي هو الموازنة بين C و A:

• اختيار CP: عند الانقسام، يتم رفض الطلبات غير المؤكدة لضمان صحة البيانات → مناسب للتمويل والمخزون
• اختيار AP: عند الانقسام، يستمر تقديم الخدمة لكن البيانات قد تكون غير متسقة مؤقتًا → مناسب للتواصل الاجتماعي والمحتوى

CAP ليس أبيض وأسود

الأنظمة في الواقع ليست ببساطة "CP أو AP". العديد من الأنظمة تتخذ خيارات مختلفة في عمليات مختلفة — ففي نفس قاعدة البيانات، يمكن أن تكون عمليات القراءة AP (السماح بقراءة بيانات قديمة)، وعمليات الكتابة CP (تتطلب تأكيد الأغلبية).

---

2. نماذج التناسق: "درجة الصرامة" في مزامنة البيانات

التناسق ليس مفتاح تشغيل (إما موجود أو غير موجود)، بل هو طيف. نماذج التناسق المختلفة توازن بشكل مختلف بين "الصحة" و"الأداء".

Consistency Model Comparison

Click to compare behavior across consistency models

Strong consistency

Eventual consistency

Causal consistency

Strong consistency

After a write succeeds, every node immediately returns the newest value, giving an experience like a single-machine database.

T1

Node A

v1

Node B

v1

Node C

v1

Initial state: all nodes are consistent

T2

Node A

v2 write

Node B

syncing...

Node C

syncing...

The client writes v2 and waits for every node to confirm

T3

Node A

v2

Node B

v2

Node C

v2

Only after all nodes confirm does the write succeed; any node reads v2

Trade-off: Higher latency because all nodes must confirm, and lower availability because node failures may block progress.

مقارنة نماذج التناسق

النموذج	الضمان	زمن الوصول	السيناريو المناسب
التناسق القوي	ما تقرأه هو بالتأكيد آخر قيمة مكتوبة	عالٍ (يتطلب انتظار المزامنة)	التحويلات البنكية، خصم المخزون
التناسق النهائي	ستتطابق جميع النسخ في النهاية، لكن قد تُقرأ قيم قديمة في هذه الأثناء	منخفض (تعود الكتابة فورًا)	التحديثات الاجتماعية، DNS
التناسق السببي	العمليات ذات العلاقة السببية مضمونة الترتيب	متوسط	الردود على التعليقات، التحرير التعاوني
التناسق الخطي	تبدو جميع العمليات وكأنها نُفذت بالتسلسل على جهاز واحد	الأعلى	الأقفال الموزعة، انتخاب القائد
تناسق الجلسة	ضمن نفس الجلسة، يضمن قراءة ما كتبه المستخدم نفسه	منخفض-متوسط	البيانات الشخصية للمستخدم

تناسق "اقرأ ما كتبته"

أكثر الاحتياجات العملية شيوعًا هو: بعد أن يُعدّل المستخدم بياناته، يراها محدثة فورًا (بينما يمكن للمستخدمين الآخرين رؤيتها لاحقًا). يُسمى هذا تناسق "Read Your Own Writes"، وهو تعزيز عملي للتناسق النهائي.

---

3. التحديات الثمانية: "حقل ألغام" الأنظمة الموزعة

تعقيد الأنظمة الموزعة لا يأتي من مشكلة واحدة، بل من تداخل عدة مشكلات معًا. فيما يلي التحديات الثمانية الأساسية.

Eight Challenges in Distributed Systems

Click each challenge to inspect details and mitigation strategies

🔌

Unreliable network

⏰

Clock drift

✂️

Network partition

🔄

Data consistency

💥

Partial failure

🧠

Split brain

📋

Event ordering

🔐

Distributed transaction

🔌 Unreliable network

Nodes communicate over networks that may drop packets, delay messages, or disconnect at any time. This is the fundamental challenge of distributed systems: never assume the network is reliable.

Scenario: Service A calls service B and receives no response after 3 seconds. Did B miss the request, or did B process it and lose the response? A cannot tell.

Mitigation strategies:

• Timeouts and retries with idempotency
• Heartbeat checks to detect connection health
• Circuit breakers to pause calls after repeated failures

العلاقة بين التحديات

هذه التحديات الثمانية ليست معزولة، بل مترابطة:

• الشبكة غير موثوقة ← تؤدي إلى انقسام الشبكة ← يُفعّل موازنة CAP
• الساعات غير متزامنة ← تؤدي إلى صعوبة ترتيب الأحداث ← تؤثر على تناسق البيانات
• الأعطال الجزئية ← قد تؤدي إلى الانقسام الذهني ← تحتاج خوارزميات الإجماع للحل
• تناسق البيانات ← يحتاج معاملات موزعة ← لكن المعاملات تتأثر بـ الشبكة غير الموثوقة

لا توجد رصاصة فضية

لا يوجد حل "مثالي" في الأنظمة الموزعة، بل فقط موازنات "مناسبة". فهم جوهر هذه التحديات هو ما يمكن من اتخاذ القرارات الصحيحة عند تصميم النظام.

---

4. خوارزميات الإجماع: كيف تجعل عدة أجهزة "تتفق"

خوارزميات الإجماع هي جوهر الأنظمة الموزعة — فهي تحل المشكلة: كيف تتفق عُقد متعددة على قيمة معينة؟ حتى مع تعطل بعض العقد أو تأخر الشبكة.

4.1 Paxos

طرحها ليسلي لامبورت عام 1990، وهي أول خوارزمية إجماع أُثبتت صحتها بشكل صارم.

الدور	المسؤولية
Proposer (المُقترح)	طرح المقترحات (القيم)
Acceptor (المُقبل)	التصويت بقبول أو رفض المقترحات
Learner (المُتعلم)	تعلم القيمة النهائية المختارة

عملية ذات مرحلتين:

1. مرحلة Prepare: يُرسل المُقترح رقم المقترح، ويعد المُقبل بعدم قبول مقترحات بأرقام أصغر
2. مرحلة Accept: يُرسل المُقترح القيمة المحددة، وإذا وافق أغلب المُقبلين يُمرر المقترح

مشكلة Paxos

Paxos صحيح رياضيًا، لكنه مشهور بصعوبة فهمه وتنفيذه. استخدم لامبورت في ورقته تشبيه البرلمان اليوناني، مما زاد حيرة الكثيرين.

4.2 Raft: وُلد من أجل الفهم

في عام 2014، طرح دييغو أنغارو خوارزمية Raft، بهدف صنع "Paxos يسهل فهمها". تُحلل مشكلة الإجماع إلى ثلاث مشكلات فرعية:

المشكلة الفرعية	الشرح
انتخاب القائد	اختيار قائد في المجموعة، وتمر جميع عمليات الكتابة عبر القائد
تكرار السجل	ينسخ القائد سجل العمليات إلى جميع المتابعين
السلامة	ضمان عدم الكتابة فوق السجلات المُقدمة

مسار Raft الأساسي:

1. عند بدء تشغيل المجموعة، تكون جميع العُقد Followers (متابعين)
2. إذا لم يتلقَ المتابع نبضات القائد خلال المهلة، يتحول إلى Candidate (مرشح) ويبدأ الانتخابات
3. المرشح الذي يحصل على أغلبية الأصوات يصبح القائد الجديد
4. يتلقى القائد طلبات العملاء، ويُكرر السجل إلى أغلبية العُقد قبل الإيداع

4.3 مقارنة خوارزميات الإجماع

الخوارزمية	سنة الطرح	سهولة الفهم	أنظمة الاستخدام
Paxos	1990	صعبة	Google Chubby
Raft	2014	سهلة	etcd، Consul، TiKV
ZAB	2011	متوسطة	ZooKeeper
EPaxos	2013	صعبة	أبحاث أكاديمية بشكل أساسي

---

5. المعاملات الموزعة: "الكل أو لا شيء" عبر العُقد

في قواعد البيانات أحادية الجهاز، تُحقق المعاملات خصائص ACID باستخدام الأقفال المحلية وسجلات التتبع. لكن عندما تتضمن العملية التجارية عدة خدمات/قواعد بيانات، كيف نضمن الذرية؟

5.1 الإيداع ذو المرحلتين (2PC)

أقدم بروتوكول للمعاملات الموزعة، يُقسم إلى مرحلتين:

المرحلة	إجراء المنسق	إجراء المشارك
Prepare	يسأل جميع المشاركين "هل يمكنك الإيداع؟"	ينفذ العملية دون إيداع، يجيب بنعم/لا
Commit	إذا كانت جميع الإجابات نعم، يُرسل Commit	يُودع رسميًا؛ إذا كانت هناك "لا"، يتراجع الجميع

مشاكل 2PC:

• الحظر: إذا تعطل المنسق بعد Prepare، ينتظر المشاركون إلى الأبد
• نقطة الفشل الوحيدة: المنسق نقطة واحدة، وتعطله يُجمّد المعاملة بالكامل
• أداء ضعيف: يحتاج جولات شبكة متعددة، ومدة احتفاظ الأقفال طويلة

5.2 نمط Saga

يُقسم Saga المعاملة الكبيرة إلى عدة معاملات محلية، لكل معاملة محلية عملية تعويض مقابلة. إذا فشلت خطوة ما، تُنفذ عمليات التعويض بالترتيب العكسي.

مثال Saga لطلب في متجر إلكتروني:

الخطوة	العملية الأمامية	عملية التعويض
T1	إنشاء الطلب (بانتظار الدفع)	إلغاء الطلب
T2	خصم المخزون	استعادة المخزون
T3	خصم الرصيد	إرجاع الرصيد
T4	تأكيد الطلب (مدفوع)	—

إذا فشلت T3 (خصم الرصيد): تُنفذ C2 (استعادة المخزون) ← C1 (إلغاء الطلب).

طريقتان للتنسيق:

• التنسيق بالنمط (Choreography): كل خدمة تستمع للأحداث وتقرر الخطوة التالية. بسيط لكن يصعب تتبع الحالة العامة
• التنسيق المركزي (Orchestration): يوجد منسق مركزي يتحكم في المسار. واضح لكن المنسق نقطة واحدة

5.3 TCC (Try-Confirm-Cancel)

TCC هو تطبيق على مستوى الأعمال لـ 2PC، يُقسم كل عملية إلى ثلاث مراحل:

المرحلة	الشرح	مثال (خصم المخزون)
Try	حجز الموارد، دون التنفيذ الفعلي	تجميد 10 وحدات من المخزون (المخزون المتاح -10، المخزون المُجمّد +10)
Confirm	تأكيد التنفيذ، استهلاك الموارد المحجوزة	المخزون المُجمّد -10 (الخصم الفعلي)
Cancel	إلغاء الحجز، تحرير الموارد	المخزون المُجمّد -10، المخزون المتاح +10 (استعادة)

5.4 مقارنة الحلول الثلاثة

الحل	التناسق	الأداء	التعقيد	السيناريو المناسب
2PC	تناسق قوي	منخفض	متوسط	المعاملات عبر قواعد البيانات على مستوى قاعدة البيانات
Saga	تناسق نهائي	عالٍ	عالٍ	العمليات التجارية الطويلة (الطلبات، الشحن)
TCC	تناسق نهائي	متوسط	الأعلى	سيناريوهات الأموال عالية الموثوقية

نصائح الاختيار العملي

• إذا أمكن استخدام معاملات قاعدة بيانات واحدة، فلا تستخدم معاملات موزعة
• في معظم السيناريوهات التجارية، يكفي Saga + قائمة انتظار الرسائل
• TCC مناسب للسيناريوهات المالية ذات المتطلبات العالية للتناسق، لكن تكلفة التطوير مرتفعة
• 2PC مناسب للبرمجيات الوسيطة لقواعد البيانات (مثل ShardingSphere) للمعالجة التلقائية

---

الخلاصة

الأنظمة الموزعة هي البنية التحتية للإنترنت الحديث، لكن تعقيدها يتجاوز بكثير الأنظمة أحادية الجهاز. فهم هذه التحديات ليس من أجل "حلها" (الكثير منها جذري)، بل من أجل اتخاذ الموازنات الصحيحة عند تصميم النظام.

نراجع النقاط الرئيسية في هذا الفصل:

1. نظرية CAP: انقسام الشبكة لا مفر منه، والاختيار الفعلي هو الموازنة بين التناسق والتوافر
2. نماذج التناسق: من التناسق القوي إلى التناسق النهائي هو طيف، اختر حسب متطلبات العمل
3. التحديات الثمانية: الشبكة غير الموثوقة، الساعات غير المتزامنة، انقسام الشبكة، الانقسام الذهني وغيرها مترابطة
4. خوارزميات الإجماع: Raft هي خوارزمية الإجماع الأكثر عملية حاليًا، etcd و Consul مبنيان عليها
5. المعاملات الموزعة: Saga مناسب لمعظم السيناريوهات، TCC للسيناريوهات المالية، 2PC على مستوى قاعدة البيانات

قراءات إضافية

• Designing Data-Intensive Applications - كتاب مارتن كليبمان الكلاسيكي عن الأنظمة الموزعة
• The Raft Consensus Algorithm - عرض مرئي رسمي لخوارزمية Raft
• CAP Twelve Years Later - إعادة نظر بروير في CAP
• Jepsen - إطار اختبار صحة الأنظمة الموزعة
• أنماط الأنظمة الموزعة - مجموعة أنماط الأنظمة الموزعة لمارتن فاولر