اتساق البيانات في الأنظمة المحملة بشكل كبير

العدد

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

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

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

حل تناسق البيانات

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

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

الشكل 1 - المخطط العام للالتزام على مرحلتين

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

الشكل 2 - الاعتماد على سرعة التزام اثنين من قاعدة على عدد من الخوادم في نظام إدارة قواعد البيانات

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

خيار آخر هو توفير آلية تسمح لك بالعمل مع قواعد بيانات مختلفة (للخدمات) كقاعدة بيانات واحدة (لحل المشكلة مع تكامل البيانات في قاعدة بيانات موزعة). في الوقت نفسه ، يلزم وجود تماثل معين للمعاملة لنظام موزع ("معاملة تجارية").

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

ما هي الملحمة وكيف تعمل؟

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

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

الشكل 3 - آلية ساغا وطبيعة التأثير التعويضي

في الشكل 3 ، تم تحديد خطوات الملحمة على أنها T1 ... T4 ، إجراءات التعويض: C1 ... C4.
ساغاس تدعم عدم اليقين من الخطوات (العمل الذي التكرار المتكرر يعادل واحد). يوفر نهج الترهل الفرصة لتكرار أي خطوة (على سبيل المثال ، إذا لم تتلق ردًا عند الانتهاء بنجاح). يسمح لك Idempotency أيضًا باستعادة الحالة عند فقد البيانات على أي عقدة (الفشل والاسترداد). عند تنفيذ خطوة ، يجب أن تحدد كل خدمة (عن طريق مفتاح idempotency) ما إذا كانت قد نفذت بالفعل هذه الخطوة أم لا (إن لم يكن ، تنفيذها ، أو تخطي خلاف ذلك). بالنسبة إلى الإجراءات التعويضية ، من الممكن أيضًا إضافة مفاتيح التباطؤ وتكرار العمليات (ضمان الثبات / الاستقرار).

ملخص

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

تتيح لك Sagas حل المهام التالية:

• توفير تغييرات البيانات التابعة لبيانات الأعمال الهامة ؛
• أن تكون قادرًا على تحديد ترتيب صارم للخطوات ؛
• الامتثال بنسبة 100 ٪ الاتساق (تنسيق البيانات حتى في حالة وقوع حوادث) ؛
• توفير اختبارات الأداء على جميع المستويات.

أمثلة النطاق والتطبيق

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

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

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

المكتبات التي تعمل بنظام Saga

تم تطوير التطبيق على .Net ، ولهذه التقنية هناك العديد من مكتبات مدير الخدمة مع دعم sagas. نظرنا إلى مكتبات NServiceBus و MassTransit و Rebus. نتيجة لذلك ، استقرنا على Rebus - هذه المكتبة أسهل في التعلم ، بينما ندرك تمامًا مبدأ الملحمة وهي مجانية في الاستخدام. NServiceBus و MassTransit أدوات أكثر تطوراً مع الكثير من الميزات الإضافية. لم تكن مطلوبة كجزء من مهمتنا ، ولكن قد يكون من المستحسن استخدامها في المشاريع المستقبلية ذات المنطق الأكثر تعقيدًا.