نمط المعاملة التعويضية

Azure

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

السياق والمشكلة

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

يوفر "رئيس تناسق البيانات" معلومات حول سبب عدم تغيير حجم المعاملات الموزعة بشكل جيد. يسرد هذا المورد أيضا مبادئ نموذج التناسق النهائي.

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

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

لا يتم دائما الاحتفاظ بالبيانات المتأثرة بعملية تنفذ التناسق النهائي في قاعدة بيانات. على سبيل المثال، ضع في اعتبارك بيئة بنية موجهة نحو الخدمة (SOA). يمكن لعملية SOA استدعاء إجراء في خدمة والتسبب في تغيير في الحالة التي تحتفظ بها تلك الخدمة. للتراجع عن العملية، يجب عليك أيضا التراجع عن تغيير الحالة هذا. يمكن أن تتضمن هذه العملية استدعاء الخدمة مرة أخرى وتنفيذ إجراء آخر يعكس تأثيرات الأول.

حل

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

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

نقطتان مهمتان هما:

  • قد لا تضطر المعاملة التعويضية إلى التراجع عن العمل بالترتيب العكسي الدقيق للعملية الأصلية.
  • قد يكون من الممكن تنفيذ بعض خطوات التراجع بالتوازي.

يشبه هذا النهج استراتيجية ساغاس التي تمت مناقشتها في مدونة كليمنز فاسترز.

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

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

المسائل والاعتبارات

ضع في اعتبارك النقاط التالية عندما تقرر كيفية تنفيذ هذا النمط:

  • قد لا يكون من السهل تحديد متى تفشل خطوة في عملية تنفذ التناسق النهائي. قد لا تفشل الخطوة على الفور. بدلا من ذلك، قد يتم حظره. قد تحتاج إلى تنفيذ آلية المهلة.

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

  • لا تعمل المعاملات التعويضية دائما. يجب تحديد الخطوات في معاملة تعويضية كأوامر متكررة. إذا قمت بذلك، يمكن تكرار الخطوات إذا فشلت المعاملة التعويضية نفسها.

  • يجب أن تفي البنية الأساسية التي تعالج الخطوات بالمعايير التالية:

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

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

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

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

  • عند تنفيذ معاملة تعويضية، تواجه العديد من نفس التحديات التي تواجهها عند تنفيذ التناسق النهائي. لمزيد من المعلومات، راجع قسم "اعتبارات تنفيذ التناسق النهائي" في "تمهيد تناسق البيانات".

موعد استخدام النمط

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط المعاملة التعويضية في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

- RE:02 التدفقات الهامة
- RE:09 التعافي من الكوارث

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

مثال

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

  1. حجز مقعد على الرحلة F1 من سياتل إلى لندن.
  2. حجز مقعد على الرحلة F2 من لندن إلى باريس.
  3. حجز مقعد على الرحلة F3 من باريس إلى سياتل.
  4. حجز غرفة في فندق H1 في لندن.
  5. حجز غرفة في فندق H2 في باريس.

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

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

يوضح الشكل التالي الخطوات الواردة في معاملة طويلة الأمد لحجز رحلة سفر. يمكنك أيضا رؤية خطوات المعاملة التعويضية التي تتراجع عن المعاملة.

رسم تخطيطي يوضح خطوات إنشاء خط سير. يتم أيضا عرض خطوات المعاملة التعويضية التي تلغي مسار الرحلة.

إشعار

قد تكون قادرا على تنفيذ الخطوات في المعاملة التعويضية بالتوازي، اعتمادا على كيفية تصميم المنطق التعويضي لكل خطوة.

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

الخطوات التالية

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