بروتوكول الالتزام ذو المرحلتين

تصغير| تسلسل نموذجي للالتزام المكون من مرحلتين.
في معالجة المعاملات وقواعد البيانات والشبكات الحاسوبية ، يُعد **بروتوكول الالتزام ثنائي ذو مرحلتين** ( **2PC** ، *tupac* ) نوعًا من بروتوكولات الالتزام الذرّي (ACP). وهو خوارزمية موزعة تنسّق بين جميع العمليات المشاركة في معاملة ذرّية موزعة،لتقرر ما إذا كان سيتم اعتماد المعاملة أو إلغاؤها (التراجع عنها).

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

في "التنفيذ العادي" لأي معاملة موزعة مفردة (أي عندما لا يحدث أي فشل، وهو الوضع الأكثر شيوعًا عادةً)، يتكوّن البروتوكول من مرحلتين وهما :

# مرحلة طلب الالتزام (أو مرحلة التصويت)، حيث تحاول عملية المنسق إعداد جميع العمليات المشاركة في المعاملة (المشاركين أو المجموعات أو العمال المسمين) لاتخاذ الخطوات اللازمة إما لالتزام المعاملة أو إلغائها والتصويت، إما "نعم": الالتزام (إذا انتهى تنفيذ الجزء المحلي لمشارك المعاملة بشكل صحيح)، أو "لا": الإلغاء (إذا تم اكتشاف مشكلة في الجزء المحلي)، و
# مرحلة الالتزام، حيث يقرر المنسق، بناءً على تصويت المشاركين، ما إذا كان سيقوم بالالتزام (فقط إذا صوت الجميع بـ "نعم") أو إلغاء المعاملة (خلاف ذلك)، ويخطر النتيجة لجميع المشاركين. يقوم المشاركون بعد ذلك بتنفيذ الإجراءات المطلوبة (الالتزام أو الإلغاء) باستخدام مواردهم المعاملاتية المحلية (وتسمى أيضًا الموارد القابلة للاسترداد؛ على سبيل المثال، بيانات قاعدة البيانات) والأجزاء الخاصة بهم في الناتج الآخر للمعاملة (إذا كان ذلك ممكنًا).

يجب عدم الخلط بين بروتوكول الالتزام على مرحلتين (2PC) وبروتوكول القفل على مرحلتين (2PL)، إذ ان الأخير هو بروتوكول للتحكم في التزامن .

## الافتراضات
يعمل البروتوكول على النحو التالي: يتم تعيين عقدة واحدة كمنسق، وهو الموقع الرئيسي، ويتم تعيين بقية العقد في الشبكة كمشاركين. يفترض البروتوكول ما يلي :

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

الافتراض الأخير ليس مقيدًا جدًا، إذ يمكن إعادة توجيه الاتصالات الشبكية. أما الافتراضان الأولان فهما أقوى بكثير؛ فإذا تم تدمير عقدة بالكامل، فقد يتم فقدان البيانات.

يبدأ تنفيذ البروتوكول من قِبل المنسّق بعد الوصول إلى الخطوة الأخيرة من المعاملة. ثم يستجيب المشاركون برسالة موافقة أو رسالة إلغاء اعتمادًا على ما إذا كانت المعاملة قد تمت معالجتها بنجاح لدى المشارك.

## الخوارزمية الأساسية

### مرحلة طلب الالتزام (أو التصويت)

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

### مرحلة الالتزام (أو الإكمال)

#### نجاح
إذا تلقّى المنسّق رسائل الموافقة من جميع المشاركين خلال مرحلة طلب الالتزام :

# يقوم المنسق بإرسال رسالة التزام إلى جميع المشاركين.
# يقوم كل مشارك بإكمال العملية، ويطلق جميع الأقفال والموارد التي احتفظ بها أثناء المعاملة.
# يقوم كل مشارك بإرسال إشعار إلى المنسق.
# يقوم المنسق بإكمال المعاملة عندما يتم استلام جميع الإقرارات.

#### فشل
إذا صوّت أيّ من المشاركين بـ "لا" خلال مرحلة طلب الالتزام (أو انتهاء مهلة المنسق):

# يقوم المنسق بإرسال رسالة التراجع إلى جميع المشاركين.
# يقوم كل مشارك بالتراجع عن المعاملة باستخدام سجل التراجع، ويطلق الموارد والأقفال التي تم الاحتفاظ بها أثناء المعاملة.
# يقوم كل مشارك بإرسال إشعار إلى المنسق.
# يقوم المنسق بإلغاء المعاملة عندما يتم استلام جميع الإقرارات.

#### تدفق الرسائل
وجود علامة * بجانب نوع السجل يعني أن السجل مُلزَم على التخزين المستقر.

## العيوب

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

## تنفيذ بروتوكول الالتزام المكون من مرحلتين

### الهندسة المعمارية المشتركة
في العديد من الحالات، يُوزّع بروتوكول الالتزام على مرحلتين 2PC في شبكة حاسوبية. ويتم توزيعه بسهولة عبر تنفيذ عدة مكونات للـ 2PC مشابهة فيما بينها، تُسمى عادةً مدراء المعاملات (TMs؛ والتي تُعرف أيضًا بوكلاء 2PC أو مراقبي معالجة المعاملات)، تقوم هذه المكونات بتنفيذ البروتوكول لكل معاملة ( مثال X/Open XA من The Open Group ). تُسجّل قواعد البيانات المشاركة في معاملة موزعة، سواء المنسّق أو المشاركون، بالتسجيل لإغلاق TMs (عادة ما تكون موجودة على نفس عقد الشبكة الخاصة بالمشاركين) لإنهاء هذه المعاملة باستخدام 2PC. تحتوي كل معاملة موزعة على مجموعة مخصصة من وحدات الترجمة، وهي وحدات الترجمة التي يسجل فيها المشاركون في المعاملة.

يُوجد قائد، وهو مدير المعاملات المنسّق TM، لكل معاملة ليقوم بتنسيق تنفيذ 2PC، وعادةً ما يكون مدير المعاملات الخاص TM بقاعدة بيانات المنسق. ومع ذلك، يمكن نقل دور المنسق إلى TM آخر لأسباب تتعلق بالأداء أو الموثوقية. بدلاً من تبادل رسائل 2PC فيما بينهم، يتبادل المشاركون الرسائل مع TMs الخاصة بهم. تتواصل وحدات الترجمة ذات الصلة فيما بينها لتنفيذ مخطط بروتوكول 2PC المذكور أعلاه، "الذي يمثل" المشاركين المعنيين، لإنهاء هذه المعاملة. مع هذا الهيكل، يتم توزيع البروتوكول بشكل كامل (لا يحتاج إلى أي مكون معالجة مركزية أو بنية بيانات)، ويتناسب مع عدد عقد الشبكة (حجم الشبكة) بشكل فعال.

هذه الهندسة المعمارية المشتركة فعالة أيضًا في توزيع بروتوكولات الالتزام الذرّية الأخرى بجانب 2PC، لأن جميع هذه البروتوكولات تستخدم نفس آلية التصويت ونقل النتائج للمشاركين في البروتوكول. 

### تحسينات البروتوكول
أُجريت أبحاث في مجال قواعد البيانات عن طرق للحصول على معظم فوائد بروتوكول الالتزام على مرحلتين مع تقليل التكاليف من خلال تحسينات البروتوكول   وتوفير عمليات البروتوكول في ظل افتراضات سلوك نظام معين.

#### الإجهاض المفترض والالتزام المفترض
يُعتبر الإجهاض أو الالتزام المفترض من بين التحسينات المشهورة.   وذلك بالافتراض حول نتيجة المعاملات، سواء كانت الالتزام أو الإلغاء، ويمكن أن يحفظ الرسائل وعمليات التسجيل التي يقوم بها المشاركون خلال تنفيذ بروتوكول 2PC. مثال على ذلك، عند افتراض الإجهاض، إذا لم يَتم العثور على أي دليل مسجل لالتزام في بعض المعاملات أثناء استرداد النظام من الفشل بواسطة إجراء الاسترداد، فإنه يفترض أن المعاملة قد تم إلغاؤها، ويتصرف وفقًا لذلك. وهذا يعني أنه لا يُهم إذا تَم تسجيل عمليات الإجهاض على الإطلاق، ويُمكن حفظ مثل هذا التسجيل تحت هذا الافتراض.

وعادةً تدفع غرامة العمليات الإضافية خلال التعافي من الفشل، وذلك يعتمد على نوع التحسين. وبالتالي، يَتم اخِتيار أفضل خيار للتحسين، إذا كان موجودًا، وفقًا لإحصائيات الفشل ونتيجة المعاملات.

#### بروتوكول الالتزام الشجري المكون من مرحلتين
بروتوكول Tree 2PC  ,والذي يُطلق عليه أيضًا Nested 2PC أو Recursive 2PC، هو أحد الأنواع الشائعة من 2PC في الشبكات الحاسوبية ، ويستفيد بشكل أفضل من بنية الاتصال التحتية.

يتم عادةً استدعاء المشاركين في معاملة موزعة وفق ترتيب يُشكل بنية شجرية، تُعرف بـ "شجرة الاستدعاء"، حيث يُمثّل المشاركون العقد، وتمثل الحواف عمليات الاستدعاء (روابط الاتصال). تُستخدم هذه الشجرة عادةً لانهاء المعاملة باستخدام بروتوكول 2PC، ولكن يمكن أيضًا استخدام شجرة اتصال أخرى لهذا الغرض، من حيث المبدأ. في شجرة 2PC، يعتبر المنسق هو الجذر ("الجزء العلوي") لشجرة الاتصالات (الشجرة المقلوبة)، في حين أن المشاركين هم العقد الأخرى. يمكن أن يكون المنسق هو العقدة التي بدأت المعاملة (يتم استدعاؤها بشكل متكرر (متعدي) من قبل المشاركين الآخرين)، ولكن يمكن أيضًا لعقدة أخرى في نفس الشجرة أن تتولى دور المنسق بدلاً من ذلك. يتم نشر رسائل 2PC من المنسق "أسفل" الشجرة، بينما يتم "جمع" الرسائل إلى المنسق بواسطة أحد المشاركين من جميع المشاركين أسفله، قبل إرسال الرسالة المناسبة "أعلى" الشجرة (باستثناء رسالة الإلغاء، والتي يتم نشرها "أعلى" فور استلامها أو إذا بدأ المشارك الحالي عملية الإلغاء).

بروتوكول الالتزام الديناميكي على مرحلتين (الالتزام الديناميكي ثنائي الطور، D2PC)   هو نوع من بروتوكول Tree 2PC لا يحتوي على منسق مُحدد مسبقًا. ويشمل العديد من التحسينات التي تم اقتراحها سابقًا. تبدأ رسائل الاتفاق (أصوات "نعم") في الانتشار من جميع الأوراق، حيث ترسل كل ورقة الرسالة عند إنهاء مهامها المتعلقة بالمعاملة (أي عندما تكون جاهزة).

ترسل العقدة المتوسطة (غير الورقية) رسالة "جاهز" عندما تستلم رسائل الاتفاق من جميع جيرانها باستثناء الجار الأخير الذي لم ترسل منه الرسالة بعد.

يتم تحديد المنسق ديناميكيًا من خلال "سباق" رسائل الاتفاق عبر شجرة المعاملة، حيث تتصادم الرسائل. يحدث التصادم إما عند عقدة شجرة المعاملات، ليكونوا المنسق، أو على حافة الشجرة. في الحالة الأخيرة، يتم انتخاب إحدى عقد الحافتين كمنسق (أي عقدة). D2PC هو الأمثل من حيث الوقت (من بين جميع حالات شجرة المعاملات المحددة، وأي تنفيذ بروتوكول شجرة 2PC محدد؛ جميع الحالات لها نفس الشجرة؛ كل حالة لها عقدة مختلفة كمنسق): من خلال اختيار منسق مثالي، يقوم D2PC بإرسال كل من المنسق وكل مشارك في أقل وقت ممكن، مما يسمح بإصدار أقرب وقت ممكن للموارد المقفولة في كل مشارك في المعاملة (عقدة الشجرة).

## انظر أيضًا

* بروتوكول الالتزام ثلاثي المراحل
* خوارزمية باكسوس
* خوارزمية الطوافة
* مشكلة الجنرالين

## المراجع



تصنيف:نظام معالجة المعاملات
تصنيف:إدارة البيانات
تصنيف:خوارزميات
تصنيف:حوسبة
تصنيف:نظم حاسوب متحملة للأخطاء