В المادة الاخيرة نظرنا إلى مجموعات RabbitMQ للتسامح مع الخطأ والتوافر العالي. الآن دعونا نتعمق في أباتشي كافكا.

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

أرز. 1. أربعة أقسام موزعة على ثلاثة سماسرة

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

فشل التقسيم

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

يترك الوسيط 3 الشبكة ، ويتم انتخاب قائد جديد للقسم 2 في الوسيط 2.

أرز. 2. وفاة الوسيط 3 وانتخاب تابعه في الوسيط 2 كقائد جديد للقسم 2

ثم يترك الوسيط 1 ويفقد القسم 1 أيضًا قائده ، الذي ينتقل دوره إلى الوسيط 2.

أرز. 3. غادر سمسار واحد. جميع القادة يعملون في نفس الوسيط بدون أي تكرار

عندما يعود Broker 1 عبر الإنترنت ، فإنه يضيف أربعة متابعين ، مما يوفر بعض التكرار لكل قسم. لكن كل القادة ظلوا على وسيط 2.

أرز. 4. يبقى القادة على Broker 2

عندما يظهر الوسيط 3 ، نعود إلى ثلاث نسخ متماثلة لكل قسم. لكن كل القادة لا يزالون على وسيط 2.

أرز. 5. التنسيب غير المتوازن للقادة بعد استعادة الوسطاء 1 و 3

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

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

لإصلاح هذا ، يقدم كافكا خيارين:

• خيار auto.leader.rebalance.enable = صحيح يسمح لعقدة وحدة التحكم بإعادة تعيين القادة تلقائيًا إلى النسخ المتماثلة المفضلة وبالتالي استعادة التوزيع المتساوي.
• يمكن للمسؤول تشغيل البرنامج النصي كافكا-المفضل-نسخة-election.sh لإعادة التعيين اليدوي.

أرز. 6. النسخ المتماثلة بعد إعادة التوازن

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

النسخ المتماثلة المتزامنة (ISRs)

ISR عبارة عن مجموعة نسخة طبق الأصل من القسم الذي يعتبر "متزامنًا". يوجد قائد هنا ، لكن قد لا يكون هناك أتباع. يعتبر المتابع متزامنًا إذا قام بعمل نسخ طبق الأصل من جميع رسائل القائد قبل انتهاء الفاصل الزمني النسخ المتماثلة. time.max.ms.

تتم إزالة المتابع من مجموعة ISR إذا:

• لم يقدم طلبًا لعينة للفاصل الزمني النسخ المتماثلة. time.max.ms (أعتبر ميتا)
• فشل في التحديث خلال الفاصل الزمني النسخ المتماثلة. time.max.ms (تعتبر بطيئة)

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

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

• acks = 0 ، لا يتم إرسال إقرار بالاستلام
• acks = 1 ، يتم إرسال الإقرار بعد أن يكتب القائد الرسالة إلى السجل المحلي الخاص به
• acks = all ، يتم إرسال الإقرار بعد أن كتبت جميع النسخ المتماثلة في ISR الرسالة إلى السجلات المحلية

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

Acks = 1 و ISR

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

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

أرز. 7. ISR مع ثلاث نسخ طبق الأصل

ينخفض ​​الوسيط 2 ويتلقى المنتج خطأ في الاتصال. بعد انتقال القيادة إلى وسيط 1 ، نفقد 123 رسالة. كان التابع على الوسيط 1 في ISR لكنه لم يكن متزامنًا تمامًا مع القائد عندما سقط.

أرز. 8. تضيع الرسائل عند تعطلها

في التكوين bootstrap.servers لدى الشركة المصنعة العديد من الوسطاء المدرجين ويمكنها أن تطلب من وسيط آخر هو قائد القسم الجديد. ثم يقوم بإنشاء اتصال بالوسيط 1 ويستمر في إرسال الرسائل.

أرز. 9. يستأنف إرسال الرسائل بعد فاصل قصير

وسيط 3 هو أبعد من ذلك. يقوم بإجراء طلبات جلب ولكن لا يمكن مزامنتها. قد يكون هذا بسبب بطء اتصال الشبكة بين الوسطاء ، أو مشكلة التخزين ، وما إلى ذلك. تتم إزالته من ISR. الآن يتكون ISR من نسخة طبق الأصل واحدة - القائد! تواصل الشركة المصنعة إرسال الرسائل وتلقي التأكيدات.

أرز. 10. تمت إزالة التابع على Broker 3 من ISR

ينخفض ​​الوسيط 1 ويتولى الوسيط 3 زمام المبادرة بخسارة 15286 رسالة! يتلقى المنتج رسالة خطأ في الاتصال. كان الانتقال إلى القائد خارج ISR ممكنًا فقط بسبب الإعداد unclean.leader.election.enable = صحيح. إذا تم تثبيته في زائف، فلن يحدث الانتقال ، وسيتم رفض جميع طلبات القراءة والكتابة. في هذه الحالة ، ننتظر عودة الوسيط 1 ببياناته السليمة في النسخة المتماثلة ، والتي ستتولى القيادة مرة أخرى.

أرز. 11. ينخفض ​​الوسيط 1. يتم فقد عدد كبير من الرسائل عند الفشل

ينشئ المنتج اتصالًا مع الوسيط الأخير ويرى أنه الآن زعيم القسم. يبدأ في إرسال رسائل إلى الوسيط 3.

أرز. 12. بعد فاصل قصير ، يتم إرسال الرسائل مرة أخرى إلى القسم 0

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

Acks = الكل و ISR

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

أرز. 13. ISR مع ثلاث نسخ طبق الأصل. أحدهما بطيء ، مما يؤدي إلى تأخير التسجيل

بعد أربع ثوانٍ من التأخير الإضافي ، يرسل الوسيط 2 ack. يتم الآن تحديث كافة النسخ المتماثلة بالكامل.

أرز. 14. جميع النسخ المتماثلة حفظ الرسائل وإرسال ack

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

أرز. 15. تتم إزالة النسخة المتماثلة على الوسيط 3 من ISR

ثم ينخفض ​​الوسيط 2 ، ويذهب العميل المحتمل إلى الوسيط 1 دون فقدان الرسالة.

أرز. 16. أعطال الوسيط 2

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

أرز. 17. تأخذ النسخة المتماثلة على الوسيط 1 زمام المبادرة دون فقدان الرسائل

ثم تعطل الوسيط 1 ويتولى الوسيط 3 زمام المبادرة بخسارة 14238 رسالة!

أرز. 18. وفاة الوسيط 1 وانتقال القيادة مع وضع غير نظيف يؤدي إلى فقدان هائل للبيانات

لم نتمكن من تحديد الخيار غير طاهر. زعيم.اختيار. ممكن في المعنى صحيح. افتراضيا هو عليه زائف. جلسة أكس = الكل с unclean.leader.election.enable = صحيح يوفر إمكانية الوصول مع بعض أمان البيانات الإضافي. ولكن كما ترى ، لا يزال بإمكاننا فقد الرسائل.

ولكن ماذا لو أردنا زيادة أمان البيانات؟ يمكن وضعها unclean.leader.election.enable = خطأ، ولكن هذا لن يحمينا بالضرورة من فقدان البيانات. إذا واجه القائد صعوبة وأخذ البيانات معه ، فستظل الرسائل مفقودة ، بالإضافة إلى فقدان التوافر حتى يستعيد المسؤول الموقف.

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

acks = الكل ، min.insync.replicas و ISR

مع تكوين الموضوع الحد الأدنى من النسخ المتزامنة نزيد من مستوى أمان البيانات. دعنا ننتقل إلى الجزء الأخير من السيناريو السابق مرة أخرى ، ولكن هذه المرة min.insync.replicas = 2.

لذلك ، لدى الوسيط 2 قائد نسخة متماثلة ، وتمت إزالة التابع على الوسيط 3 من ISR.

أرز. 19. ISR من نسختين طبق الأصل

ينخفض ​​الوسيط 2 ويتحول العميل المتوقع إلى الوسيط 1 دون فقدان الرسالة. ولكن الآن يتكون ISR من نسخة طبق الأصل واحدة فقط. هذا لا يفي بالحد الأدنى لعدد الإدخالات ، وبالتالي يستجيب الوسيط لمحاولة الكتابة بخطأ NotEnoughReplicas.

أرز. 20. عدد ISRs أقل من الحد الأدنى للنسخة المتزامنة

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

عندما يكون التوفر ضروريًا لأمن البيانات

كما في حالة مع RabbitMQ، أحيانًا تكون إمكانية الوصول ضرورية لأمن البيانات. إليك ما تحتاج إلى التفكير فيه:

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

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

معنى ISR

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

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

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

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

في الإعدادات bootstrap.servers منتج ومستهلك ، يمكنك تحديد وسطاء متعددين لربط العملاء. الفكرة هي أنه عند تعطل عقدة واحدة ، هناك العديد من العقد الاحتياطية التي يمكن للعميل من خلالها فتح اتصال. هؤلاء ليسوا بالضرورة قادة تقسيم ، لكنهم مجرد نقطة انطلاق للتمهيد. يمكن للعميل أن يسألهم عن العقدة التي تستضيف قائد قسم القراءة / الكتابة.

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

عمارة إجماع كافكا

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

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

يخزن Zookeeper حالة الكتلة:

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

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

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

لكل قسم تحكم:

• تحديث المعلومات في Zookeeper حول ISR والقائد ؛
• يرسل أمر LeaderAndISRC إلى كل وسيط يستضيف نسخة طبق الأصل من هذا القسم ، لإبلاغ الوسطاء بـ ISR والقائد.

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

كل قائد مسؤول عن مجموعة من ISRs. جلسة النسخ المتماثلة. time.max.ms يحدد من يدخل. عندما يتغير ISR ، يرسل القائد المعلومات الجديدة إلى Zookeeper.

يتم إبلاغ Zookeeper دائمًا بأي تغييرات حتى تنتقل القيادة بسلاسة إلى قائد جديد في حالة الفشل.

أرز. 21. إجماع كافكا

بروتوكول النسخ المتماثل

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

حدد الاستعلامات وإزاحة نهاية السجل (LEO) وعلامة Highwater (HW)

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

يحتفظ القائد وجميع المتابعين بعلامة Log End Offset (LEO) و Highwater (HW). تخزن علامة LEO إزاحة الرسالة الأخيرة في النسخة المتماثلة المحلية ، بينما تخزن HW إزاحة آخر التزام. ضع في اعتبارك أنه بالنسبة لحالة الالتزام ، يجب استمرار الرسالة عبر جميع ISRs. هذا يعني أن المدار الأرضي المنخفض عادة ما يكون متقدمًا قليلاً عن المخلفات الخطرة.

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

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

فشل القائد

عندما يسقط القائد ، يقوم Zookeeper بإخطار وحدة التحكم ، ويختار المتحكم نسخة متماثلة جديدة للقائد. يضع القائد الجديد علامة HW جديدة وفقًا لـ LEO الخاص به. ثم يتلقى المتابعون معلومات عن القائد الجديد. اعتمادًا على إصدار كافكا ، سيختار المتابع أحد السيناريوهين:

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

قد يحتاج المتابع إلى اقتطاع السجل للأسباب التالية:

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

التوحيد مع الكتلة

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

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

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

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

يحتوي كافكا على مكونات أكثر من RabbitMQ ، لذلك لديه مجموعة أكثر تعقيدًا من السلوكيات عند انقطاع الاتصال في كتلة. لكن كافكا صُمم في الأصل للعناقيد ، لذا فإن الحلول مدروسة جيدًا.

فيما يلي بعض السيناريوهات لفشل الاتصال:

• السيناريو 1. لا يرى المتابع القائد ، لكنه لا يزال يرى Zookeeper.
• السيناريو 2. لا يرى القائد أي متابعين ، لكنه لا يزال يرى Zookeeper.
• السيناريو 3. يرى المتابع القائد ، لكنه لا يرى Zookeeper.
• السيناريو 4. يرى القائد المتابعين ، لكنه لا يرى Zookeeper.
• السيناريو الخامس: المتابع منفصل تمامًا عن كل من عقد كافكا الأخرى وعقد Zookeeper.
• السيناريو 6: القائد منفصل تمامًا عن كل من عقد كافكا الأخرى و Zookeeper.
• السيناريو السابع: لا تستطيع عقدة تحكم كافكا رؤية عقدة كافكا أخرى.
• السيناريو الثامن: المتحكم كافكا لا يرى Zookeeper.

كل سيناريو له سلوكه الخاص.

السيناريو 1. لا يرى المتابع القائد ، لكنه لا يزال يرى Zookeeper

أرز. 22. السيناريو 1. ISR من ثلاث نسخ متماثلة

يفصل قطع الاتصال بين Broker 3 و Brokers 1 و 2 ، ولكن ليس من Zookeeper. لم يعد بإمكان الوسيط 3 إرسال طلبات الجلب. بعد مرور الوقت النسخ المتماثلة. time.max.ms تمت إزالته من ISR ولا يشارك في التزامات الرسائل. بمجرد استعادة الاتصال ، ستستأنف طلبات الجلب وتنضم إلى ISR عندما تلحق بالقائد. سيستمر Zookeeper في تلقي الأصوات ويفترض أن الوسيط على قيد الحياة وبصحة جيدة.

أرز. 23. السيناريو 1: تتم إزالة الوسيط من ISR إذا لم يتم استلام أي طلب جلب منه داخل الفاصل الزمني المتماثل .lag.time.max.ms

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

السيناريو 2. لا يرى القائد أي متابعين ، لكنه لا يزال يرى Zookeeper

أرز. 24. السيناريو 2. زعيم واثنين من المتابعين

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

أرز. 25. السيناريو 2. يتقلص ISR للقائد فقط

السيناريو 3. يرى المتابع القائد ، لكنه لا يرى Zookeeper

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

أرز. 26. السيناريو 3. التابع يستمر في إرسال طلبات الجلب إلى القائد

السيناريو 4. يرى القائد المتابعين ، لكنه لا يرى Zookeeper

أرز. 27. السيناريو 4. زعيم واثنين من المتابعين

يتم فصل القائد عن Zookeeper ، ولكن ليس عن الوسطاء الذين لديهم أتباع.

أرز. 28. السيناريو 4. زعيم معزول عن Zookeeper

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

Сообщения أكس = الكل لن يتلقى تأكيدًا ، لأنه في البداية يقوم ISR بتشغيل جميع النسخ المتماثلة ، ولا تصل الرسائل إليها. عندما يحاول القائد الأصلي إزالتها من ISR ، فلن يكون قادرًا على القيام بذلك وسيتوقف عن تلقي أي رسائل تمامًا.

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

أرز. 29. السيناريو 4. يصبح القائد في الوسيط 1 تابعًا بعد استعادة الشبكة

السيناريو الخامس: المتابع منفصل تمامًا عن كل من عقد كافكا الأخرى وعقد Zookeeper

التابع معزول تمامًا عن كل من عقد كافكا الأخرى و Zookeeper. يتم إزالته ببساطة من ISR حتى يتم استعادة الشبكة ، ثم اللحاق بالباقي.

أرز. 30. السيناريو 5. تتم إزالة المتابع المعزول من ISR

السيناريو 6: القائد منفصل تمامًا عن كل من عقد كافكا الأخرى و Zookeeper

أرز. 31. السيناريو 6. زعيم واثنين من المتابعين

الزعيم معزول تمامًا عن أتباعه ، المتحكم و Zookeeper. لفترة قصيرة ، سيستمر قبول الإدخالات من أكس = 1.

أرز. 32. السيناريو 6. عزل القائد عن العقد الأخرى من نوع كافكا وزوكيبير

عدم تلقي الطلبات بعد انتهاء الصلاحية النسخ المتماثلة. time.max.ms، سيحاول ضغط ISR على نفسه ، لكنه لن يكون قادرًا على القيام بذلك لأنه لا يوجد اتصال بـ Zookeeper ، ثم سيتوقف عن قبول عمليات الكتابة.

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

أرز. 33. السيناريو 6. زعيمان

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

أرز. 34. السيناريو 6. يتحول المصنعون إلى قائد جديد

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

أرز. 35. السيناريو 6. يصبح القائد الأصلي تابعًا بعد استعادة اتصال الشبكة

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

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

السيناريو السابع: لا تستطيع عقدة تحكم كافكا رؤية عقدة كافكا أخرى

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

السيناريو الثامن: المتحكم كافكا لا يرى Zookeeper

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

الوجبات الجاهزة من النصوص

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

إذا تم فصل القائد عن Zookeeper بسبب فقدان الاتصال ، فقد يؤدي ذلك إلى فقد الرسائل من أكس = 1. يتسبب عدم التواصل مع Zookeeper في انقسام منطقي مؤقت بين زعيمين. يتم حل هذه المشكلة بواسطة المعلمة أكس = الكل.

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

ملخص فقدان الرسالة

نسرد كل الطرق التي يمكنك من خلالها فقدان البيانات في كافكا:

• أي فشل قائد إذا تم الاعتراف بالرسائل أكس = 1
• أي انتقال غير نظيف للقيادة ، أي إلى تابع خارج نظام أمن الدولة ، حتى مع أكس = الكل
• اعزل القائد عن Zookeeper إذا تم الإقرار بالرسائل أكس = 1
• العزلة الكاملة للزعيم الذي ضغط بالفعل على مجموعة ISR لنفسه. ستفقد كل الرسائل ، حتى أكس = الكل. هذا صحيح فقط إذا min.insync.replicas = 1.
• الفشل المتزامن لجميع العقد في القسم. نظرًا لأنه يتم التعرف على الرسائل من الذاكرة ، فقد لا تتم كتابة بعضها على القرص. بعد إعادة تشغيل الخوادم ، قد تكون بعض الرسائل مفقودة.

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

مقارنة مباشرة بين RabbitMQ وموثوقية كافكا

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

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

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

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

يراهن كافكا على أنه إذا تم تخزين رسالة عبر عقد متعددة ، فيمكن التعرف على الرسائل بمجرد أن تكون في الذاكرة. لهذا السبب ، هناك خطر فقدان الرسائل من أي نوع (حتى أكس = الكل, min.insync.replicas = 2) في حالة الفشل المتزامن.

بشكل عام ، يُظهر كافكا أداء برمجيًا فائقًا وقد تم تصميمه في الأصل للتجمعات. يمكن زيادة عدد المتابعين إلى 11 إذا لزم الأمر من أجل الموثوقية. عامل النسخ المتماثل 5 والحد الأدنى لعدد النسخ المتماثلة المتزامنة min.insync.replicas = 3 جعل فقدان رسالة حدثًا نادرًا جدًا. إذا كانت البنية الأساسية الخاصة بك قادرة على توفير عامل النسخ هذا ومستوى التكرار ، فيمكنك اختيار هذا الخيار.

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

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

أخيرًا ، لا تنس عددًا من الأخطاء في آليات التجميع والتكرار لكل من RabbitMQ و Kafka. بمرور الوقت ، أصبحت الأنظمة أكثر نضجًا واستقرارًا ، ولكن لا توجد رسالة آمنة بنسبة 100٪ ضد الخسارة! بالإضافة إلى ذلك ، تحدث حوادث واسعة النطاق في مراكز البيانات!

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

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

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

أرى تقنيات أخرى تفتقر إلى هذه الموثوقية والطلب المضمون ، ثم ألقي نظرة على RabbitMQ و Kafka - وأنا أفهم القيمة المذهلة لكلا النظامين.

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