شرح Distributed Consensus: كيف تتفق الخوادم في الأنظمة الموزعة

في الأنظمة الموزعة، لدينا عدة خوادم (Nodes) تعمل معاً لتقديم خدمة واحدة للمستخدمين. لكن ماذا يحدث عندما نحتاج لاتخاذ قرار موحّد بين هذه الخوادم؟ كيف نتأكد أن جميع الخوادم لديها نفس البيانات، وتنفذ نفس القرار، حتى في وجود أعطال في الشبكة أو سقوط بعض الخوادم؟ هنا يأتي دور Distributed Consensus Algorithms.

هذه الخوارزميات هي القلب النابض للأنظمة الموزعة الحديثة: قواعد البيانات الموزعة، أنظمة التخزين، منصات الرسائل، وحتى أنظمة الـ Microservices المعقّدة. بدون اتفاق موزع ثابت وموثوق، لن نستطيع ضمان صحة البيانات أو استمرارية الخدمة.

في هذا المقال من افهم صح سنشرح:

• ما هو الاتفاق الموزع Distributed Consensus ولماذا هو مهم؟
• التحديات الأساسية في الاتفاق بين الخوادم
• أهم خوارزميات الاتفاق: Paxos وRaft
• أين تُستخدم هذه الخوارزميات في العالم الحقيقي (مثل قواعد البيانات الموزعة)
• كيف ترتبط هذه المفاهيم بمواضيع مثل الأنظمة الموزعة و تصميم الأنظمة System Design

ما هو Distributed Consensus؟

الاتفاق الموزع هو عملية اتخاذ قرار واحد متفق عليه بين مجموعة من الخوادم في نظام موزع، على الرغم من:

• احتمال سقوط بعض الخوادم (Node Failures)
• تأخر أو فقدان رسائل الشبكة
• وجود طلبات متعددة ومتنافسة في نفس الوقت

بشكل مبسّط، نريد أن نضمن أن:

• كل الخوادم ترى نفس الحالة (نفس البيانات وتسلسل الأوامر)
• القرارات لا تتعارض مع بعضها
• المنظومة تستطيع الاستمرار في العمل حتى لو فشلت بعض الأجزاء

المثال الكلاسيكي: لديك قواعد بيانات موزعة على عدة خوادم. عندما يأتي طلب تحديث (مثلاً: خصم مبلغ من رصيد حساب)، يجب أن يتم تطبيق هذا التغيير على كل النسخ المتفق عليها من قاعدة البيانات، وبنفس الترتيب، حتى لا يحدث تضارب في الأرصدة.

لماذا نحتاج خوارزميات Distributed Consensus Algorithms؟

يمكنك أن تتخيل أن الاتفاق الموزع مثل اجتماع لعدة مدراء يجب أن يوقّعوا على نفس القرار. إذا وقّع البعض ورفض البعض، أو تأخر توقيع البعض، تظهر الفوضى.

في الأنظمة الموزعة، المشكلة أعقد بكثير بسبب:

• تأخير الشبكة (Network Latency): الرسائل قد تصل متأخرة أو بترتيب مختلف.
• انقسام الشبكة (Network Partition): جزء من الخوادم قد ينفصل عن البقية ولا يستطيع التواصل معهم.
• سقوط الخوادم (Node Crashes): خادم قد يتوقف فجأة أثناء تنفيذ عملية حساسة.

هنا تأتي خوارزميات Distributed Consensus Algorithms لتوفر ضمانات أساسية:

• Safety (السلامة): لا يتم قبول قرارين متناقضين أبداً.
• Liveness (الحيوية): طالما أن أغلب الخوادم تعمل والشبكة معقولة، سيستمر النظام في اتخاذ القرارات.

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

أين نستخدم Distributed Consensus في العالم الحقيقي؟

خوارزميات الاتفاق الموزع ليست نظرية فقط، بل هي جزء أساسي من أغلب البنى التحتية الحديثة، مثل:

• قواعد البيانات الموزعة مثل: Etcd، Consul، TiDB، CockroachDB
• أنظمة التنسيق (Coordination Systems) مثل: ZooKeeper
• أنظمة إدارة التهيئة (Configuration Management) و Service Discovery
• أنظمة Queue وStreaming مثل: بعض أجزاء Kafka (لتنسيق الـ Controllers)

هذه الأنظمة تحتاج إلى "مصدر حقيقة موحّد" (Single Source of Truth) لحالة النظام، إعدادات الخدمات، أو بيانات الميتا (Metadata). وهنا يتم الاعتماد على خوارزميات الاتفاق مثل Raft وPaxos.

إذا كنت مهتماً أكثر ببناء الأنظمة الكبيرة، فقد يفيدك قراءة: شرح Horizontal Scaling وكيفية تعامل الأنظمة الكبيرة مع ملايين المستخدمين.

المفاهيم الأساسية في الاتفاق الموزع

1. الأغلبية (Majority / Quorum)

أغلب خوارزميات الاتفاق تعتمد على مفهوم الأغلبية (Quorum). بدلاً من انتظار جميع الخوادم (التي قد يفشل بعضها)، نحتاج فقط إلى موافقة أغلبها.

إذا كان عندك 5 خوادم، الأغلبية تكون 3. بمجرد أن توافق 3 خوادم على قرار معين، يمكن اعتباره مقبولاً، حتى لو الخوادم الأخرى متأخرة أو متوقفة.

2. القائد (Leader)

الكثير من خوارزميات Distributed Consensus تتبع نمط Leader-Based، أي:

• يتم انتخاب قائد واحد (Leader) من بين الخوادم.
• كل التحديثات (Writes) تمر عبر هذا القائد.
• القائد ينسّق نشر التحديثات على بقية الخوادم (Followers).

وجود قائد يسهّل الحفاظ على ترتيب موحّد للأوامر، بدلاً من السماح لكل خادم أن يتخذ قرارات مستقلة.

3. سجل التكرار (Replicated Log)

من أجل الحفاظ على نفس الحالة في كل الخوادم، تستخدم كثير من الأنظمة Replicated Log:

• القائد يستقبل الأوامر (مثل: "خصم 100 من رصيد المستخدم X").
• يضيف الأمر إلى سجل (Log) برقم تسلسلي.
• ينسخ هذا السجل لبقية الخوادم، مع الحفاظ على نفس الترتيب.
• عندما تتفق الأغلبية على إدخال معين في السجل، يعتبر "Committed" ويتم تطبيقه على الحالة (State Machine).

هذه الفكرة هي الأساس في Raft والكثير من تطبيقات Paxos، وتسمى أحياناً State Machine Replication.

خوارزمية Paxos: الكلاسيكية والمعقدة

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

الفكرة العامة في Paxos

Paxos تحاول الإجابة على سؤال: كيف تختار مجموعة من الخوادم قيمة واحدة متفق عليها (مثلاً: من هو القائد؟ ما هو القرار الخاص بمعاملة معينة؟) رغم الأعطال؟

الخوارزمية تعتمد على:

• مقترِحين (Proposers)
• مقبِلين (Acceptors)
• متعلّمين (Learners)

وتعمل على جولتين أساسيتين (Prepare / Accept)، حيث يقوم المقترِح بإرسال اقتراح برقم معين، ويحصل على وعود من مجموعة من المقبِلين بعدم قبول اقتراحات أقدم أو أقل أولوية، ثم يحاول تثبيت القيمة عندما يحصل على موافقة الأغلبية.

من الناحية النظرية، Paxos قوية جداً وتضمن السلامة في وجود أعطال الشبكة وسقوط الخوادم. لكن عملياً، عندما نحاول تحويلها إلى نظام كامل لإعادة حالة (Replicated State Machine)، تصبح التفاصيل معقدة، مما دفع المجتمع للبحث عن بدائل أبسط.

خوارزمية Raft: اتفاق موزع بطريقة مفهومة

Raft ظهرت بهدف واحد رئيسي: تقديم نفس قوة Paxos، لكن بطريقة أسهل للفهم والتطبيق. اليوم، Raft هي واحدة من أكثر خوارزميات الاتفاق الموزع استخداماً في المشاريع المفتوحة المصدر.

الأدوار في Raft

في Raft، كل خادم يمكن أن يكون في أحد هذه الأدوار:

• Leader (قائد): يستقبل كل الطلبات من الكلاينت، ويكتب في السجل، وينسخ السجل إلى الآخرين.
• Follower (تابع): يستقبل التحديثات من القائد فقط، ولا يتعامل مباشرة مع الكلاينت.
• Candidate (مرشّح): عندما يظن خادم أنه لا يوجد قائد (بسبب انقطاع أو فشل)، يحاول الترشح ليصبح القائد من خلال انتخابات.

دورات الزمن (Terms)

Raft تقسم الزمن إلى فترات متتالية تسمى Terms. في كل Term، يمكن أن يكون هناك قائد واحد فقط (أو لا يوجد قائد إذا لم تكتمل الانتخابات). هذا يساعد في:

• كشف القادة القدامى الذين فقدوا السيطرة.
• تنظيم الانتخابات.
• تحديد أي سجل هو الأحدث والأكثر موثوقية.

كيفية انتخاب القائد في Raft

آلية الانتخابات في Raft هي جوهر مفهوم الاتفاق:

1. كل Follower ينتظر رسائل “نبضات قلب” (Heartbeats) من القائد.
2. إذا توقف القائد عن إرسال Heartbeats لفترة زمنية عشوائية صغيرة (Election Timeout)، يتحول الـ Follower إلى Candidate.
3. المرشح يرفع رقم الـ Term، ويرسل رسالة طلب تصويت (RequestVote) لباقي الخوادم.
4. كل خادم يعطي صوته لمرشح واحد فقط في كل Term، بشرط أن:
   • يكون سجل المرشح على الأقل حديثاً مثل سجله.
5. إذا حصل المرشح على أغلبية الأصوات، يصبح Leader ويرسل Heartbeats بشكل دوري ليخبر الآخرين أنه القائد.

هذا التصميم يضمن أنه في كل Term يوجد على الأكثر قائد واحد، وأن القائد يمتلك السجل الأكثر تحديثاً.

كيف يكتب القائد في السجل ويضمن الاتفاق؟

عندما يصل طلب من الكلاينت (مثلاً تحديث أوامر معينة):

1. القائد يضيف أمر جديد إلى السجل الخاص به مع Index وTerm.
2. يرسل القائد هذا الإدخال إلى الـ Followers عبر AppendEntries RPC.
3. كل Follower يحاول مطابقة السجل مع ما عنده، ويضيف الإدخال إذا كان متوافقاً مع التاريخ السابق.
4. عندما يحصل القائد على تأكيد من أغلبية الخوادم بأن الإدخال تم تسجيله، يعتبر الإدخال Committed.
5. بعدها يطبق القائد الإدخال على حالة النظام (State Machine)، ويخبر الكلاينت أن العملية تمت بنجاح.
6. بقية الخوادم تطبق الإدخال أيضاً بمجرد أن تعرف أنه Committed.

النقطة الجوهرية: لا يعتبر أي تحديث نهائي (Committed) إلا بعد موافقة الأغلبية، وهذا هو جوهر Distributed Consensus Algorithms.

التعامل مع إعادة تشغيل الخوادم أو سقوطها

Raft مصممة بحيث:

• إذا سقط قائد، يمكن إجراء انتخابات جديدة واختيار قائد آخر.
• الخوادم التي تعود للعمل بعد سقوط، تقوم بمزامنة سجلها مع القائد الحالي.
• لا يمكن لخادم بسجل قديم أن يصبح قائداً؛ لأن الخوارزمية تفضّل من يمتلك سجلاً أحدث.

هذا يضمن أن أي قرار Committed لن يضيع حتى في حالة الأعطال المتكررة، طالما أن هناك أغلبية من الخوادم حية وقادرة على التواصل.

الفرق بين Raft وPaxos باختصار

• Paxos:
  • تصميم نظري قوي، أساس أغلب الأبحاث.
  • معقد في الفهم والتطبيق عملياً.
  • غالباً ما تستخدم نسخ معدّلة وموسّعة منه (Multi-Paxos) لعمل Replicated Logs.
• Raft:
  • تم تصميمه ليكون أسهل في الفهم، مع توثيق وبناء منطقي واضح.
  • يوفّر Replicated Log بشكل مباشر، مع Election وLeader Handling مدمجين.
  • يُستخدم في أنظمة عملية كثيرة مثل etcd وConsul وTiKV وRethinkDB (جزئياً).

من الناحية النظرية، يمكن لكليهما تحقيق نفس الضمانات تقريباً، لكن من الناحية العملية: Raft أصبح الخيار الأكثر شيوعاً في المشاريع الجديدة بسبب بساطته النسبية.

Distributed Consensus وقواعد البيانات الموزعة

خوارزميات الاتفاق الموزع هي الأساس الذي تبني عليه قواعد البيانات الموزعة:

• تخزين الـ Metadata (مثل: مواقع الشظايا Shards، معلومات العقد Nodes، إعدادات التقسيم والنسخ).
• إدارة الـ Leaders لكل مجموعة بيانات (Partition / Shard).
• حفظ إعدادات النظام الحرجة بشكل موثوق (Config Store).

مثلاً، في نظام مثل CockroachDB أو TiDB، يوجد عادة مجموعة صغيرة من الخوادم تدير “سجل اتفاق” باستخدام Raft. هذا السجل يحتوي على قرارات مثل:

• أين توجد نسخة كل جزء من البيانات؟
• من هو القائد الحالي لكل Shard؟
• ما هي إعدادات التكرار والنسخ الحالية؟

بدون اتفاق موزع، يمكن أن يحدث تضارب في المعلومات بين الخوادم، مما يؤدي لضياع بيانات أو ازدواجية معاملات (Double Spending) أو استجابات متناقضة للكلاينت.

إذا كنت مهتماً أكثر ببنية قواعد البيانات والأداء، راجع: كيف تعمل الفهارس في قواعد البيانات؟ شرح B-Tree وHash Index.

العلاقة بين Distributed Consensus وDesign Patterns في الأنظمة الموزعة

عند تصميم نظام موزع كبير، ستستخدم مجموعة من الأنماط (Patterns) لتحقيق الاعتمادية والمرونة، مثل:

• Retry Pattern لإعادة إرسال الطلبات عند الفشل
• Circuit Breaker Pattern لمنع انهيار متسلسل في الخدمات
• Leader Election Pattern لاختيار قائد لخدمة معينة

خوارزميات الاتفاق الموزع مثل Raft وPaxos تُعتبر الطبقة العميقة التي تبني عليها هذه الأنماط:

• Leader Election في المستوى العالي غالباً يعتمد ضمنياً على آلية توافق (Consensus) في الخلفية.
• أنظمة Configuration / Service Discovery تبني قراراتها على سجل متفق عليه.

بمعنى آخر، عندما ترى نظاماً يستخدم Retry أو Leader Election أو Sharding، فغالباً يوجد في الطبقة السفلى Distributed Consensus Algorithm يدير حالة هذا النظام ويضمن اتساقها.

هل تحتاج فعلاً لتطبيق Raft أو Paxos بنفسك؟

في الغالب، لا.

معظم المطوّرين لن يكتبوا خوارزمية Paxos أو Raft من الصفر في مشروع إنتاجي. بدلاً من ذلك:

• ستستخدم أنظمة جاهزة مثل etcd وConsul وZooKeeper لتخزين الحالة الحرجة.
• أو ستستخدم مكتبات / Frameworks توفّر Raft بشكل جاهز.

لكن فهم الفكرة العامة لـ Distributed Consensus Algorithms مهم جداً لكل من يعمل في:

• تصميم الأنظمة (System Design)
• تطوير البنى التحتية (Infrastructure / Platform Engineering)
• قواعد البيانات وأنظمة التخزين

هذا الفهم يساعدك على اتخاذ قرارات صحيحة عند اختيار تقنياتك، وفهم حدود كل نظام (متى يكون Strongly Consistent، ومتى يكون Eventually Consistent فقط).

الخلاصة

خوارزميات Distributed Consensus Algorithms مثل Raft وPaxos هي الأساس الذي تعتمد عليه:

• قواعد البيانات الموزعة
• أنظمة التنسيق والتكوين (Configuration / Coordination)
• خدمات الاكتشاف (Service Discovery)
• العديد من الأنظمة الحساسة في البنية التحتية للإنترنت

فهمك لهذه الخوارزميات يمنحك رؤية واضحة لكيفية:

• اتفاق الخوادم على قرارات موحدة رغم الأعطال
• حفظ تسلسل الأوامر والبيانات بشكل متناسق
• تصميم أنظمة موثوقة وقابلة للتوسع

إذا كنت في بداية طريقك مع الأنظمة الموزعة، ننصحك بقراءة: ما هو Distributed Systems؟ ولماذا يعتمد عليه كل الإنترنت تقريباً، ثم العودة لمفاهيم الاتفاق الموزع لفهم الصورة الكاملة لكيفية عمل البنى التحتية العملاقة في العالم الحقيقي.