ملحمة منظمة أو كيفية بناء المعاملات التجارية في الخدمات باستخدام قاعدة البيانات لكل نمط خدمة

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

أريد أن أخبركم كيف نجحنا في حل أحد تحديات بنية الخدمات الصغيرة - إجراء المعاملات التجارية في البنية التحتية للخدمات التي تم إنشاؤها باستخدام قاعدة البيانات لكل نمط خدمة. لقد قدمت عرضًا تقديميًا حول هذا الموضوع في مؤتمر Highload ++ Siberia 2018 .

النظرية أقصر وقت ممكن

لن أصف بالتفصيل نظرية القصص. سأعطيك مقدمة موجزة فقط حتى تتمكن من فهم السياق.

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

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

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

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

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

• توفير تغييرات البيانات التابعة للبيانات الهامة للأعمال
• تكون قادرة على وضع أمر صارم ؛
• مراقبة الاتساق مائة بالمائة - تنسيق البيانات حتى في حالة وقوع حوادث ؛
• ضمان تشغيل المعاملات على جميع المستويات.

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

تنفيذ ملحمة مدبرة كخدمة PG Saga

هذا ما تبدو عليه خدمة PG Saga.

PG في الاسم ، لأنه يتم استخدام PostgreSQL متزامن كمخزن للخدمة. ماذا يوجد في الداخل:

• API
• المنفذ ؛
• مدقق
• فاحص صحي
• المعوض.

يُظهر الرسم التخطيطي أيضًا مالك الخدمة للقصص ، وفيما يلي الخدمات التي ستؤدي خطوات الملحمة. قد يكون لديهم مستودعات مختلفة.

كيف يعمل

ضع في اعتبارك مثال شراء حزم VAS. VAS (خدمات القيمة المضافة) - خدمات مدفوعة لترويج الإعلان.

أولاً ، يجب على مالك خدمة الملحمة تسجيل إنشاء الملحمة في خدمة الملحمة

بعد ذلك ، يولد فئة ملحمة بالفعل مع Payload.

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

ثم يتم تطبيق عمليات VAS في خدمة المستخدم.

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

تحطم

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

1. نحن نعيد المحاولة.
2. نقوم بتمييز كل عملية بمفتاح idempotent. هذا ضروري لتجنب الازدواجية في العمليات. يمكن العثور على المزيد حول مفاتيح idempotent في هذه المقالة.
3. نحن نعوض المعاملات - خاصية مميزة للقصص.

تعويض المعاملات: كيف يعمل

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

في تنفيذنا ، نقدم سيناريو التعويض التالي:

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

في مثالنا ، ستبدو كما يلي:

1. قم بإيقاف تشغيل حزم VAS.

1. قم بإلغاء عملية المستخدم.

1. نلغي حجز الأموال.

ماذا تفعل إذا لم يعمل التعويض

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

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

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

سيناريو حادث آخر

تخيل أننا نقوم بنفس الاشتراك المميز مرة أخرى.

1. نشتري حزم VAS واحتياطي المال.

1. نطبق الخدمات على المستخدم.

1. نقوم بإنشاء حزم VAS.

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

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

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

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

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

مثال على منطق توليد الملحمة الذي يمكن إخفاؤه في مكتبة العميل

يمكن القيام بذلك بشكل مختلف ، لكنني أقترح النهج التالي.

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

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

كيفية التحقق من كل ذلك

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

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

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

المجموع:

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

ما هو جوهر مركز السيطرة على الأمراض؟ هناك خدمة توفر العقد. لديه واجهة برمجة تطبيقات - هذا مزود. وهناك خدمة أخرى تستدعي API ، وهي استخدام العقد - المستهلك.

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

حول كيفية تنفيذ Avito نهج CDC لاختبار الخدمات الصغيرة تحدث Frol Kryuchkov في RIT ++. يمكن العثور على الملخصات على موقع الويب Backend.conf - أوصي بأن تتعرف على نفسك.

أنواع Sagas

في ترتيب استدعاءات الوظائف

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

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

من خلال الحصول على نتيجة استدعاء الوظيفة

أ) متزامن - تُعرف نتيجة الوظيفة على الفور ؛
ب) غير متزامن - تقوم الوظيفة بإرجاع "موافق" على الفور ، ويتم إرجاع النتيجة لاحقًا ، من خلال رد الاتصال إلى API خدمة sag من خدمة العميل.

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

تحجيم الترهل

يعتمد القياس على حجم النظام الذي تخطط له. ضع في اعتبارك الخيار بمثيل تخزين واحد:

• معالج خطوة ملحمة واحد ، معالجة الخطوات بالدُفعات ؛
• ن معالجات ، نقوم بتنفيذ "مشط" - نتخذ خطوات لما تبقى من القسم: عندما يحصل كل منفذ على خطواته الخاصة.
• n معالجات وتخطي مؤمن - ستكون أكثر كفاءة ومرونة.

وعندها فقط ، إذا كنت تعرف مقدمًا أنك ستعمل في أداء خادم واحد في نظام إدارة قواعد البيانات (DBMS) ، فأنت بحاجة إلى إجراء عمليات تقسيم - n مثيلات قاعدة بيانات تعمل مع مجموعة البيانات الخاصة بهم. يمكن إخفاء المشاركة خلف API sag service.

المزيد من المرونة

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

متى تحتاج إلى قفل

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

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

كيف تفعل ذلك؟ , , , , , - , . . . : , , .

-, , . , , . , , . . — , , .

ACID —

, , . . — durability. . . , . - , - - ,

$$$Ti reads => other rtransaction writes => Tj (or Ci) writes$

— - , - , , - , . , - , - .

$$$Ti writes => other transaction reads => Ci writes$

— .

$$$Ti reads =>other transaction writes =>Tj reads$

:

1. , , , , .
2. , . , , , , , .
3. .
4. payload . eventual consistency — , , , . , , , -.

المراقبة

. , . . checker. . , .

(50%, 75%, 95%, 99%), , - .

, — , . . , - . , — .

. , - ( ) . healthchecker endpoint' info (keep-alive) .

. -. -, - , - . , , , end-to-end. - . , , — .
. .

:

, healthchecker, - , . , . .

, . , , . . choreography — - . , choreography- , . choreography , . , . , , , .

. , , . , + .

API

, - - ( API ), , API. API . — . API , , 100% .

, , , , . — , , . .

, , , . ( ) .

, , , , .

. , , .

saga call ID

. API , .

—

- legacy . , ( «» ). « »? - , , , , - , . , , , . , « », , -. . — . , .

, , . , , , , . , , . .

, . .