يعد التسامح مع الأخطاء والتوافر العالي من الموضوعات الكبيرة ، لذلك سنخصص مقالات منفصلة لـ RabbitMQ و Kafka. هذه المقالة عن RabbitMQ والمقال التالي عن كافكا مقابل RabbitMQ. المقال طويل ، لذا اجعل نفسك مرتاحًا.

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

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

سنرى أن الاتساق والتوافر على طرفي مختلف من الطيف ، وعليك اختيار الطريقة التي يجب تحسينها. والخبر السار هو أنه مع RabbitMQ ، يكون هذا الاختيار ممكنًا. لديك نوع من الرافعات "المهووسة" لتحويل التوازن نحو مزيد من الاتساق أو مزيد من الوصول.

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

أساسيات مرونة العقدة الواحدة

قوائم انتظار / توجيه متينة

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

تتم إزالة قوائم الانتظار والتوجيه المتقلبة عند إعادة تشغيل العقدة.

رسائل مستدامة

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

أرز. 1. مصفوفة الاستقرار

التجميع مع النسخ المتطابق لقائمة الانتظار

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

انعكاس قائمة الانتظار:

• قائمة انتظار رئيسية واحدة (رئيسية) تتلقى جميع أوامر الكتابة والقراءة
• مرآة واحدة أو أكثر تتلقى جميع الرسائل والبيانات الوصفية من قائمة الانتظار الرئيسية. لا توجد هذه المرايا للقياس ، ولكن فقط للتكرار.

أرز. 2. عكس قائمة الانتظار

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

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (سيد واحد ومرآة واحدة)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

تأكيد الناشر

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

قائمة انتظار تجاوز الفشل

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

أرز. 3. قوائم انتظار متعددة معكوسة وسياساتها

الوسيط 3 تعطل. لاحظ أنه تمت ترقية نسخة قائمة الانتظار C في Broker 2 إلى نسخة رئيسية. لاحظ أيضًا أنه تم إنشاء نسخة متطابقة جديدة لقائمة الانتظار C على الوسيط 1. يحاول RabbitMQ دائمًا الحفاظ على عامل النسخ المحدد في سياساتك.

أرز. 4. يسقط الوسيط 3 ، مما يؤدي إلى فشل قائمة الانتظار C

الوسيط 1 التالي هو معطل! لم يتبق لدينا سوى وسيط واحد. تمت ترقية مرآة قائمة الانتظار B إلى المستوى الرئيسي.

التين. 5

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

في هذه الحالة ، يكون فقدان الوسيط 1 كاملاً ، وكذلك فقد البيانات ، وبالتالي يتم فقد قائمة الانتظار B غير المعكوسة تمامًا.

أرز. 6. عودة الوسيط 1 إلى الخدمة

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

أرز. 7. عودة الوسيط 3 إلى الخدمة. جميع قوائم الانتظار الرئيسية في عقدة واحدة!

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

تزامن

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

هذه المزامنة تلقائية أو يدوية ويتم التحكم فيها من خلال سياسة قائمة الانتظار. تأمل في مثال.

لدينا طابوران معكوسان. تتم مزامنة قائمة الانتظار أ تلقائيًا ، بينما تتم مزامنة قائمة الانتظار ب يدويًا. تحتوي كلتا قوائم الانتظار على عشر رسائل.

أرز. 8. طابوران مع أوضاع توقيت مختلفة

الآن نخسر الوسيط 3.

أرز. 9. انخفض الوسيط 3

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

أرز. 10. تتلقى النسخة المتطابقة الجديدة لقائمة الانتظار أ كافة الرسائل الموجودة ، لكن النسخة المتطابقة الجديدة لقائمة الانتظار ب لا تستقبلها

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

أرز. 11. يتراجع الوسيط 1 عن قائمة الانتظار A بدون فقدان الرسالة

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

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

أرز. 12. تتم إعادة قائمة الانتظار A إلى Broker 3 بدون فقد الرسالة. تعود قائمة الانتظار B إلى Broker 3 مع فقد عشر رسائل

يمكننا أيضًا تثبيت ملفات ha-promote-on-failure في المعنى when-synced. في هذه الحالة ، بدلاً من الرجوع إلى المرآة ، ستنتظر قائمة الانتظار حتى يعود Broker 1 عبر الإنترنت ببياناته. بعد عودته ، تعود قائمة الانتظار الرئيسية إلى Broker 1 دون فقد البيانات. يتم التضحية بالتوافر من أجل أمان البيانات. لكن هذا وضع محفوف بالمخاطر ، يمكن أن يؤدي إلى فقدان البيانات بالكامل ، وهو ما سننظر فيه قريبًا.

أرز. 13. تظل قائمة الانتظار B غير متاحة بعد خسارة الوسيط 1

يمكنك طرح السؤال: "ربما من الأفضل عدم استخدام المزامنة التلقائية مطلقًا؟". الجواب هو أن المزامنة عملية حظر. أثناء المزامنة ، لا يمكن لقائمة الانتظار الرئيسية إجراء أي عمليات قراءة أو كتابة!

تأمل في مثال. الآن لدينا قوائم انتظار طويلة جدًا. كيف يمكن أن تنمو إلى هذا الحجم؟ لعدة أسباب:

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

أرز. 14. طابوران كبيران مع أوضاع توقيت مختلفة

الوسيط 3 يتعطل الآن.

أرز. 15. تعطل الوسيط 3 تاركًا سيدًا ومرآة في كل قائمة انتظار

يعود Broker 3 عبر الإنترنت ويتم إنشاء مرايا جديدة. تبدأ قائمة الانتظار الرئيسية أ في النسخ المتماثل للرسائل الموجودة إلى النسخة المتطابقة الجديدة ، وخلال هذا الوقت لا تتوفر قائمة الانتظار. يستغرق نسخ البيانات ساعتين ، مما يؤدي إلى توقف ساعتين عن قائمة الانتظار هذه!

ومع ذلك ، تظل قائمة الانتظار B متاحة طوال الفترة. لقد ضحت ببعض التكرار من أجل الوصول.

أرز. 16. تظل قائمة الانتظار غير متوفرة أثناء المزامنة

بعد ساعتين ، تصبح قائمة الانتظار أ متاحة أيضًا ويمكن أن تبدأ في قبول عمليات القراءة والكتابة مرة أخرى.

تحديثات

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

• always= تمكين تجاوز الفشل في المرايا غير المتزامنة
• when-synced= نقل فقط إلى مرآة متزامنة ، وإلا تصبح قائمة الانتظار غير قابلة للقراءة وقابلة للكتابة. تعود قائمة الانتظار إلى الخدمة بمجرد عودة الوسيط

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

عندما يحسن التوافر أمن البيانات

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

هنا تحتاج إلى مراعاة ما يلي:

• هل يمكن للناشر فقط إرجاع خطأ وجعل خدمة المنبع أو المستخدم يحاول مرة أخرى لاحقًا؟
• هل يمكن للناشر حفظ الرسالة محليًا أو في قاعدة البيانات لإعادة المحاولة لاحقًا؟

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

وبالتالي ، يجب البحث عن توازن ، ويعتمد القرار على الموقف المحدد.

مشكلات ha-Promotion-on-failure = عند المزامنة

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

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

لإعادة إضافة عقدة بنفس الاسم ، نقول للمجموعة أن تنسى العقدة المعزولة (التي لها Rabbitmqctl ننسى_الكتلة_node) وابدأ وسيطًا جديدًا بنفس اسم المضيف. بينما يتذكر الكتلة العقدة المفقودة ، فإنه يتذكر قائمة الانتظار القديمة والمرايا غير المتزامنة. عندما يُطلب من المجموعة أن تنسى عقدة مفقودة ، يتم أيضًا نسيان قائمة الانتظار هذه. الآن نحن بحاجة إلى إعادة إعلانها. لقد فقدنا جميع البيانات على الرغم من وجود مرايا بها مجموعة جزئية من البيانات. سيكون من الأفضل التبديل إلى مرآة غير متزامنة!

لذلك ، فإن المزامنة اليدوية (والفشل في المزامنة) بالاشتراك مع ha-promote-on-failure=when-syncedمخاطرة كبيرة في رأيي. تقول المستندات إن هذا الخيار موجود لأمن البيانات ، لكنه سكين ذو حدين.

إتقان إعادة التوازن

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

يمكن أن تكون إعادة التوازن إلى الماجستير مشكلة لسببين:

• لا توجد أدوات جيدة لإجراء إعادة التوازن
• مزامنة قائمة الانتظار

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

هناك حيلة أخرى لنقل قائمة الانتظار الرئيسية من خلال سياسات HA. يذكر الدليل النصي لهذا. يعمل مثل هذا:

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

الجانب السلبي هو أن هذا النهج قد لا يعمل إذا كان لديك قوائم انتظار كبيرة أو متطلبات التكرار الصارمة.

الآن دعونا نرى كيف تعمل مجموعات RabbitMQ مع أقسام الشبكة.

انقطاع الاتصال

يتم توصيل عقد النظام الموزع عن طريق روابط الشبكة ، ويمكن فصل ارتباطات الشبكة وسيتم فصلها. يعتمد تواتر الانقطاعات على البنية التحتية المحلية أو موثوقية السحابة المختارة. في كلتا الحالتين ، يجب أن تكون الأنظمة الموزعة قادرة على التعامل معها. مرة أخرى ، لدينا خيار بين التوافر والاتساق ، ومرة ​​أخرى الخبر السار هو أن RabbitMQ يوفر كلا الخيارين (فقط ليس في نفس الوقت).

مع RabbitMQ لدينا خياران رئيسيان:

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

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

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

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

توفر الأنماط المختلفة لـ RabbitMQ إما التوافر أو الاتساق.

وضع التجاهل (افتراضي)

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

أرز. 18. ثلاثة ناشرين ينتمون إلى ثلاثة وسطاء. داخليًا ، تقوم المجموعة بتوجيه جميع الطلبات إلى قائمة الانتظار الرئيسية في Broker 2.

الآن نحن نخسر الوسيط 3. إنه يرى أن الوسطاء الآخرين قد سقطوا ويقدم مرآته إلى السيد. هذه هي الطريقة التي يحدث بها الفصل المنطقي.

أرز. 19. القسمة المنطقية (انشقاق الدماغ). تذهب السجلات إلى قائمتين رئيسيتين ، وتخرج النسختان.

تمت استعادة الاتصال ، ولكن يبقى الفصل المنطقي. يجب على المسؤول تحديد الطرف الخاسر يدويًا. في الحالة التالية ، يقوم المسؤول بإعادة تشغيل Broker 3. يتم فقد جميع الرسائل التي لم يكن لديه وقت لإرسالها.

أرز. 20. يعطل المسؤول Broker 3.

أرز. 21. يقوم المسؤول ببدء تشغيل Broker 3 وينضم إلى المجموعة ، ويفقد جميع الرسائل التي تركت هناك.

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

وضع الالتئام الذاتي

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

وقفة الوضع الصغرى

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

أرز. 22. ثلاثة ناشرين ينتمون إلى ثلاثة وسطاء. داخليًا ، تقوم المجموعة بتوجيه جميع الطلبات إلى قائمة الانتظار الرئيسية في Broker 2.

ثم ينفصل الوسطاء 1 و 2 عن الوسيط 3. وبدلاً من الترويج لمرآته للسيطرة ، يتوقف الوسيط 3 مؤقتًا ويصبح غير متاح.

أرز. 23. Broker 3 يوقف ويفصل جميع العملاء ويرفض طلبات الاتصال.

بمجرد استعادة الاتصال ، فإنه يعود إلى الكتلة.

لنلقِ نظرة على مثال آخر حيث توجد قائمة الانتظار الرئيسية في الوسيط 3.

أرز. 24. قائمة الانتظار الرئيسية لدى الوسيط 3.

ثم يحدث نفس فقدان الاتصال. توقف الوسيط 3 مؤقتًا لأنه على الجانب الأصغر. على الجانب الآخر ، ترى العقد أن Broker 3 قد سقط ، لذلك يتم ترقية النسخة الأقدم من Brokers 1 و 2 إلى سيد.

أرز. 25. التحول إلى Broker 2 عندما لا يتوفر Broker 3.

عند استعادة الاتصال ، سينضم Broker 3 إلى المجموعة.

أرز. 26 - عادت الكتلة إلى عملها الطبيعي.

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

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

ضمان اتصال العملاء

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

خياراتنا:

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

النتائج

التجميع RabbitMQ له مزايا وعيوب. أخطر العيوب هي:

• عند الانضمام إلى كتلة ، تتجاهل العقد بياناتها ؛
• يؤدي حظر المزامنة إلى عدم توفر قائمة الانتظار.

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

• شبكة غير موثوقة.
• تخزين غير موثوق.
• طوابير طويلة جدا.

بالنسبة للإعدادات الخاصة بالتوافر العالي ، ضع في اعتبارك ما يلي:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (أو autoheal)
• رسائل مستدامة
• تأكد من اتصال العملاء بالعقدة النشطة عند تعطل بعض العقد

من أجل التناسق (أمان البيانات) ، ضع في اعتبارك الإعدادات التالية:

• يؤكد الناشر وشكرًا يدويًا من جانب المستهلك
• ha-promote-on-failure=when-syncedإذا كان بإمكان الناشرين المحاولة مرة أخرى لاحقًا وإذا كانت لديك سعة تخزينية قوية جدًا! وضع خلاف ذلك =always.
• ha-sync-mode=automatic (ولكن قد تتطلب قوائم الانتظار الكبيرة غير النشطة وضعًا يدويًا ؛ ضع في اعتبارك أيضًا ما إذا كان عدم التوافر سيؤدي إلى فقد الرسائل)
• إيقاف وضع الأقليات مؤقتًا
• رسائل مستدامة

لم نقم بعد بتغطية جميع قضايا التسامح مع الخطأ والتوافر العالي ؛ على سبيل المثال ، كيفية تنفيذ الإجراءات الإدارية بأمان (مثل التحديثات المستمرة). نحتاج أيضًا إلى التحدث عن الاتحاد والمكوِّن الإضافي Shovel.

إذا فاتني أي شيء آخر ، فيرجى إبلاغي بذلك.

انظر أيضا لي بعدحيث أستخدم مجموعة RabbitMQ باستخدام Docker و Blockade لاختبار بعض سيناريوهات فقدان الرسائل الموضحة في هذه المقالة.

المقالات السابقة في السلسلة:
رقم 1 - habr.com/ru/company/itsumma/blog/416629
رقم 2 - habr.com/ru/company/itsumma/blog/418389
رقم 3 - habr.com/ru/company/itsumma/blog/437446

المصدر: www.habr.com