في عالم الأنظمة الموزعة، يُعد تحقيق الإجماع الكأس المقدسة. كيف تتفق العقد المتعددة على حالة بيانات واحدة عندما تكون انقسامات الشبكة وفشل العقد وتأخر الرسائل أمراً حتمياً؟ تكمن الإجابة في خوارزميات الإجماع. بالنسبة لمعماريي الأنظمة والمهندسين ذوي الخبرة، فإن فهم هذه البروتوكولات ليس مجرد أمر أكاديمي؛ بل هو أمر أساسي لبناء تطبيقات مرنة وقابلة للتوسع وتحمل الأعطال. اليوم، سنقوم بتحليل خوارزميتين مؤثرين جداً: Paxos و Raft.
تحدي الإجماع الموزع
قبل الغوص في الخوارزميات المحددة، من الضروري فهم نطاق المشكلة. في نظام العقدة الواحدة، يعد الكتابة إلى قاعدة بيانات أمراً مباشراً. ومع ذلك، في مجموعة موزعة، تواجهك مقايضات مبرهنة CAP. للحفاظ على الاتساق والتوافر، نحتاج إلى طريقة لضمان اتفاق جميع النسخ على ترتيب العمليات. هنا يأتي دور الإجماع. الهدف بسيط: بمجموعة من المدخلات، يجب أن تتفق جميع العقد غير المعطلة في النهاية على نفس المخرج.
Paxos: الأساس النظري
تم اقتراح Paxos بواسطة Leslie Lamport، وهو الخوارزمية الأساسية للإجماع الموزع. إنها معقدة بشكل شهير، وغالباً ما توصف بأنها "الخوارزمية التي لا يفهمها أحد". على الرغم من تعقيدها، فإنها توفر ضمانات قوية تحت التزامن الجزئي وفشل الكسر.
يعمل Paxos في مرحلتين: مرحلة التحضير ومرحلة القبول. في مرحلة التحضير، يطلب المقترح (مرشح القائد) من العقد الوعد بعدم قبول المقترحات ذات المعرفات ذات الأولوية الأقل. في مرحلة القبول، إذا وافقت الأغلبية، يقترح المقترح قيمة. إذا قبلت الأغلبية، يتم اختيار القيمة.
على الرغم من قوتها، فإن تنفيذ Paxos بشكل صحيح أمر صعب بسبب التعامل الدقيق مع معرفات المقترحين واختيار القيم. فيما يلي تمثيل برمجي (pseudo-code) للمنطق الأساسي:
// مرحلة انتخاب القائد
on START_ELECTION(node_id):
ballot_id = generate_unique_ballot()
wait_for_majority(reply):
if reply.promises_to(node_id, ballot_id):
move_to_proposal_phase(ballot_id)
// مرحلة الاقتراح
on move_to_proposal_phase(ballot_id):
value = select_value() // عادةً آخر قيمة مكتوبة أو جديدة
broadcast_proposal(ballot_id, value)
wait_for_majority(acceptance):
if accepted:
leader_status = ACTIVE
persist_value(value)Raft: الإجماع للبشر
إدراكاً لصعوبات تنفيذ Paxos، صمم Diego Ongaro و John Ousterhout خوارزمية Raft في عام 2014. تم تصميم Raft لتكون سهلة الفهم. إنها تحلل الإجماع إلى ثلاث مشكلات فرعية: انتخاب القائد، وتكرار السجل، والسلامة. من خلال تقديم نموذج قائد قوي، تبسط Raft آلة الحالة المطلوبة لكل عقدة.
في Raft، توجد العقد في واحدة من ثلاث حالات: تابع (Follower)، مرشح (Candidate)، أو قائد (Leader). يتم تقسيم الوقت إلى فترات (terms). تحدث الانتخابات عندما يشتبه تابع في فشل قائد (مهلة الانتخابات). يطلب المرشح الأصوات؛ وإذا حصل على أغلبية، يصبح قائداً ويبدأ في إرفاق إدخالات السجل.
// انتقالات آلة الحالة في Raft
function on_message(node, msg):
if msg.type == HEARTBEAT:
update_last_seen(msg.leader_id)
reset_election_timeout()
if msg.type == REQUEST_VOTE:
if msg.term >= current_term:
current_term = msg.term
vote_for = msg.candidate_id
send(VOTE_GRANTED, msg.candidate_id)
if msg.type == APPEND_ENTRIES:
if msg.term >= current_term:
append_log(msg.entries)
send(APPEND_RESPONSE, success=true)Raft مقابل Paxos: متى تختار أيهما؟
على الرغم من أن كلتا الخوارزميتين تحلان نفس المشكلة الأساسية، إلا أن تطبيقاتهما العملية تختلف. غالباً ما يُستخدم Paxos في الأنظمة حيث يكون المتانة النظرية أمراً بالغ الأهمية، ويمكن تجريد تعقيد التنفيذ بعيداً عبر المكتبات (مثل Chubby من Google أو ZooKeeper، الذي يستخدم متغيراً من Paxos). ومع ذلك، يُفضل Raft للأنظمة الجديدة مثل etcd و Consul لأنه أسهل في التنفيذ والتصحيح والتوسع. يجعل نموذج القائد الصريح عمليات مثل ضغط السجل وتغيير العضوية أكثر بديهية.
الخاتمة
تُعد خوارزميات الإجماع العمود الفقري للبنية التحتية الموزعة الحديثة. سواء كنت تصمم قاعدة بيانات، أو طابور رسائل، أو خدمة تكوين، فإن فهم المقايضات بين Paxos و Raft أمر حاسم. يقدم Raft نهجاً أكثر عملية لمعظم التحديات الهندسية المعاصرة، حيث يوفر الوضوح دون التضحية بالموثوقية. عند تصميم نظامك الموزع التالي، تذكر أن الإجماع ليس مجرد اتفاق على البيانات؛ بل هو بناء الثقة في بيئة غير مؤكدة.