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

الموسوعة الحرة
تسلسل نموذجي لعملية الالتزام على مرحلتين.

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

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

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

يجب عدم الخلط بين بروتوكول الالتزام ثنائي المرحلة (2PC) وبروتوكول القفل ثنائي المرحلة (2PL)، وهو بروتوكول للتحكم في التزامن .

الافتراضات

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

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

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

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

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

مرحلة تنفيذ الطلب (أو التصويت)

  1. يقوم المنسق بإرسال رسالة استعلام إلى جميع المشاركين وينتظر حتى يتلقى ردًا من جميع المشاركين.
  2. ينفذ المشاركون المعاملة حتى النقطة التي سيُطلب منهم فيها تأكيدها. ويكتب كل منهم إدخالاً في سجل التراجع الخاص به وإدخالاً في سجل الإعادة الخاص به .
  3. يجيب كل مشارك بما يلي:
إما رسالة اتفاق ( يصوت المشارك بنعم للالتزام)، إذا نجحت إجراءات المشارك؛
أو رسالة إجهاض (يصوت المشارك بـ "لا" للتأكيد)، إذا واجه المشارك فشلاً من شأنه أن يجعل التأكيد مستحيلاً.

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

نجاح

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

  1. يقوم المنسق بإرسال رسالة تأكيد إلى جميع المشاركين.
  2. يكمل كل مشارك العملية، ويحرر جميع الأقفال والموارد التي تم الاحتفاظ بها أثناء المعاملة.
  3. يرسل كل مشارك إشعارًا إلى المنسق.
  4. يُكمل المنسق المعاملة عند استلام جميع الإشعارات.

فشل

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

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

تدفق الرسائل

منسق مشارك طلب الالتزام --------------------------------> صوّت بنعم/لا استعد/ألغِ <------------------------------- الالتزام/الإلغاء الالتزام/التراجع --------------------------------> تأكيد الالتزام/إلغاء <-------------------------------- نهاية

تشير علامة * بجوار نوع السجل إلى أن السجل مُجبر على التخزين الثابت. [ 4 ]

العيوب

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

تطبيق بروتوكول الالتزام على مرحلتين

هندسة معمارية مشتركة

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

يُعد هذا التصميم المعماري المشترك فعالاً أيضاً لتوزيع بروتوكولات الالتزام الذري الأخرى إلى جانب بروتوكول الالتزام ثنائي المرحلة (2PC)، حيث تستخدم جميع هذه البروتوكولات آلية التصويت نفسها ونشر النتائج إلى المشاركين في البروتوكول. [ 1 ] [ 2 ]

تحسينات البروتوكول

لقد تم إجراء أبحاث قواعد البيانات حول طرق الحصول على معظم فوائد بروتوكول الالتزام ثنائي المرحلة مع تقليل التكاليف عن طريق تحسينات البروتوكول [ 1 ] [ 2 ] [ 3 ] وتوفير عمليات البروتوكول في ظل افتراضات سلوك النظام.

تم افتراض الإجهاض وتم افتراض الالتزام

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

بروتوكول الالتزام ثنائي المرحلة للشجرة

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

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

انظر أيضاً

مراجع

  1. 1 2 3 فيليب أ. بيرنشتاين ، فاسوس هادزيلاكوس، ناثان غودمان (1987): التحكم في التزامن والاسترداد في أنظمة قواعد البيانات ، الفصل 7، شركة أديسون ويسلي للنشر، ISBN 0-201-10715-5
  2. 1 2 3 4 5 6 غيرهارد ويكوم ، جوتفريد فوسين (2001): نظم معلومات المعاملات ، الفصل 19، إلسفير، ISBN 1-55860-508-8
  3. 1 2 3 فيليب أ. بيرنشتاين، إريك نيومر (2009): مبادئ معالجة المعاملات ، الطبعة الثانية ، مؤرشفة في 7 أغسطس 2010 على موقع Wayback Machine ، الفصل 8، مورغان كوفمان (إلسيفير)، رقم ISBN 978-1-55860-623-4
  4. ↑ سي. موهان ، بروس ليندسي، و ر. أوبرمارك (1986): "إدارة المعاملات في نظام إدارة قواعد البيانات الموزعة R*" ، معاملات ACM لأنظمة قواعد البيانات (TODS) ، المجلد 11، العدد 4، ديسمبر 1986، الصفحات 378-396
  5. ↑ سي. موهان ، بروس ليندسي (1985): "بروتوكولات الالتزام الفعالة لنموذج شجرة العمليات للمعاملات الموزعة" ، مجلة أنظمة التشغيل ACM SIGOPS ، 19(2)، ص 40-52 (أبريل 1985)
  6. ↑ يواف راز (1995): "بروتوكول الالتزام الديناميكي ثنائي المرحلة (D2PC)" ، نظرية قواعد البيانات - المؤتمر الدولي لتكنولوجيا البيانات 1995 ، سلسلة محاضرات في علوم الحاسوب ، المجلد 893/1995، الصفحات 162-176، سبرينغر، ISBN 978-3-540-58907-5