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

التطور من المعاملات المحلية إلى المعاملات الموزعة

ما هي الصفقة؟ قبل الإجابة على هذا السؤال ، دعنا نلقي نظرة على سيناريو كلاسيكي: نقل منصات التداول مثل Alipay. لنفترض أن Xiao Ming يحتاج إلى استخدام Alipay لتحويل 100،000 يوان إلى Xiaohong. في هذا الوقت ، سيكون حساب Xiaooming أقل بـ 100،000 يوان ، وحساب Xiaohong سيكون 100،000 يوان أكثر. إذا تعطل النظام أثناء عملية النقل ، وكان حساب Xiaohong أقل من 100000 يوان ، وظل مبلغ حساب Xiaohong دون تغيير ، فستكون هناك مشكلة كبيرة ، لذلك نحتاج إلى استخدام المعاملات في هذا الوقت.

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

تضمن المعاملات المحلية اتساق البيانات القوي من خلال ACID. ACID هو اختصار لـ Atomic ، و Consistency ، و Isolation ، و Durability. في عملية التطوير الفعلية ، استخدمنا الشؤون المحلية بشكل أو بآخر. على سبيل المثال ، تبدأ استخدامات معالجة معاملات MySQL في بدء المعاملة ، والتراجع عن المعاملة ، وتأكيد تنفيذ المعاملة. هنا ، بعد تنفيذ المعاملة ، يتم تسجيل التغييرات من خلال سجل الإعادة ، ويتم استخدام سجل التراجع للتراجع عندما يفشل في ضمان ذرية المعاملة. يضيف المؤلف أن جميع المطورين الذين يستخدمون لغة Java قد تواصلوا مع Spring. يستخدم Spring التعليق التوضيحيTransactional للحصول على وظيفة المعاملة. في الواقع ، يُلخص Spring هذه التفاصيل. عند إنشاء حبوب ذات صلة ، عندما تحتاج إلى حقن حبوب ذات صلة مع التعليقات التوضيحيةTransactional ، يتم استخدام الحقن الوكيل ، ويتم فتح معاملة الالتزام / التراجع لنا في الوكيل.

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

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

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

في هذا الوقت ، تطرح نظرية BASE حلاً للاتساق والتوافر. BASE هو اختصار لـ Basically Available ، Soft-state ، وفي نهاية المطاف متسقة. إنها الدعم النظري للاتساق النهائي. . افهم ببساطة أنه في النظام الموزع ، يُسمح بفقد التوافر الجزئي ، وهناك تأخير في عملية مزامنة البيانات بين العقد المختلفة ، ولكن بعد فترة من الإصلاح ، يمكن تحقيق الاتساق النهائي للبيانات في النهاية. تؤكد BASE على التناسق النهائي للبيانات. بالمقارنة مع ACID ، تكتسب BASE التوافر من خلال السماح بفقدان الاتساق الجزئي.

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

حل تناسق قوي

اتفاق الالتزام على مرحلتين

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

يضمن بروتوكول XA الاتساق القوي من خلال بروتوكول التقديم على مرحلتين.

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

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

اتفاق الالتزام على ثلاث مراحل

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

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

حل متسق في نهاية المطاف

وضع TCC

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

يقسم وضع TCC المهمة إلى ثلاث عمليات: حاول ، تأكيد ، إلغاء. إذا كان لدينا طريقة func () ، فعندئذٍ في وضع TCC ، ستصبح tryFunc () ، ConfirmFunc () ، وcellFunc () ثلاث طرق.

نسخ الكود

tryFunc () ؛ ConfirmFunc () ؛ إلغاء الأمر () ؛

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

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

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

هناك العديد من المشاريع الناضجة مفتوحة المصدر لإطار تنفيذ TCC ، مثل إطار معاملة TCC. (للحصول على تفاصيل حول إطار عمل معاملة tcc ، يمكنك قراءة: https://github.com/changmingxie/tcc-transaction).

يشتمل إطار معاملة tcc بشكل أساسي على ثلاث وحدات: tcc-transaction-core و tcc-transaction-api و tcc-transaction-spring. من بينها ، tcc-transaction-core هو التنفيذ الأساسي لمعاملة tcc ، و tcc-transaction-api هو واجهة برمجة التطبيقات المستخدمة بواسطة معاملة tcc ، و tcc-transaction-spring هو دعم الربيع لمعاملة tcc. تلخص tcc-transaction كل عملية تجارية في مشارك في المعاملة ، ويمكن أن تحتوي كل معاملة على عدة مشاركين. يحتاج المشاركون إلى التصريح عن ثلاثة أنواع من الطرق: المحاولة / التأكيد / الإلغاء. هنا ، نحدد طريقة المحاولة مع التعليق التوضيحيCompensable ونحدد طريقة التأكيد / الإلغاء المقابلة.

نسخ الكود

// try methodCompensable (definitelyMethod = "definitelyRecord" ،cellMethod = "cellRecord "، transactionContextEditor = MethodTransactionContextEditor.class)Transactionalpublic String Record (TransactionContext transactionContext و CapitalTradeOrderDto tradeOrderDto) {} // Confirmpublic TransactionTransactional TransactionContext CapitalTradeOrderDto tradeOrderDto) {} // cancell methodTransactionalpublic void cancellRecord (TransactionContext transactionContext، CapitalTradeOrderDto tradeOrderDto) {}

من أجل تحقيق إطار معاملة tcc ، دعونا نفهم بعض الأفكار الأساسية. يتم اعتراض إطار عمل المعاملة tcc من خلال جانبCompensable ، والذي يمكنه استدعاء طريقة تأكيد / إلغاء المشارك بشفافية ، وبالتالي تحقيق وضع TCC. هنا ، معاملة tcc لها اعتراضان ، انظر الشكل 6-10.

• org.mengyun.tcctransaction.interceptor.CompensableTransactionInterceptor ، معترض معاملات قابل للتعويض.
• org.mengyun.tcctransaction.interceptor.ResourceCoordinator المعترض ، منسق الموارد المعترض.

هنا ، نحتاج إلى إيلاء اهتمام خاص لسياق معاملة TransactionContext ، لأننا نحتاج إلى تمرير المعاملة إلى المشارك البعيد في شكل معلمات عند الاتصال بمشارك الخدمة عن بُعد. في معاملة tcc ، يمكن أن يكون لمعاملة منظمة mengyun.tcctransaction عدة مشاركين org.mengyun.tcctransaction أو مشارك للمشاركة في الأنشطة التجارية. من بينها ، يتم استخدام رقم المعاملة TransactionXid لتحديد المعاملة بشكل فريد ، ويتم إنشاؤه باستخدام خوارزمية UUID لضمان التفرد. عندما يقوم أحد المشتركين بإجراء مكالمة عن بُعد ، يكون رقم المعاملة الخاصة بمعاملة الفرع البعيد مساويًا لرقم المعاملة الخاص بالمشارك. من خلال طريقة تأكيد / إلغاء TCC لاتفاق رقم المعاملة ، يتم استخدام رقم معاملة المشارك لربط معاملة الفرع البعيد ، وذلك لتحقيق الالتزام والتراجع عن المعاملة. تتضمن حالة المعاملة "حالة المعاملة": محاولة الحالة "محاولة" (1) ، تأكيد الحالة "تأكيد" (2) ، "إلغاء الحالة" إلغاء (3). بالإضافة إلى ذلك ، يتضمن نوع المعاملة TransactionType: معاملة الجذر ROOT (1) ، معاملة الفرع BRANCH (2). عندما يتم استدعاء TransactionManager # begin () لبدء المعاملة الجذرية ، النوع هو MethodType.ROOT ، ويتم استدعاء طريقة المحاولة. قم باستدعاء أسلوب TransactionManager # propagationNewBegin () لنشر وبدء معاملة فرع. تقوم هذه الطريقة باستدعاء MethodType.PROVIDER ويتم استدعاء أسلوب محاولة المعاملة. قم باستدعاء طريقة TransactionManager # الالتزام () لتنفيذ المعاملة. يتم استدعاء هذه الطريقة عندما تكون المعاملة في طريقة التأكيد / الإلغاء. وبالمثل ، قم باستدعاء أسلوب TransactionManager # rollback () لإلغاء المعاملة.

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

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

وضع التعويض

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

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

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

وضع حدث موثوق

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

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

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

نسخ الكود

public void doServer () {// Send message send ()؛ // Perform business exec ()؛ // Update message status updateMsg ()؛}

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

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

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

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

تفسير تنفيذ المعاملات الموزعة لمشاريع مفتوحة المصدر

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

صاروخ

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

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

ServiceComb

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

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

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

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

حالة الاستخدام: https://github.com/apache/servicecomb-saga/tree/master/saga-demo

نسخ الكود

EnableOmegapublic class Application {public static void main (String args) {SpringApplication.run (Application.class، args)؛}}SagaStartpublic void xxx () {}Compensablepublic void transfer () {}

الآن ، دعنا نلقي نظرة على مخطط انسيابي للأعمال.

نبذة عن الكاتب:

Liang Guizhao ، بنية الخدمات المصغرة القابلة للتطوير بدرجة عالية: استنادًا إلى Dubbo و Spring Cloud و Service Mesh "المؤلف المشارك لـ WeChat العام" التفكير بالخادم ".