غلطي رواداري ۽ اعلي دستيابي وڏا موضوع آهن، تنهنڪري اسان الڳ الڳ مضمون RabbitMQ ۽ Kafka لاء وقف ڪنداسين. هي مضمون RabbitMQ جي باري ۾ آهي، ۽ ايندڙ هڪ RabbitMQ جي مقابلي ۾ ڪافڪا بابت آهي. هي هڪ ڊگهو مضمون آهي، تنهنڪري پنهنجو پاڻ کي آرام سان ٺاهيو.

اچو ته ڏسون غلطي رواداري، مستقل مزاجي، ۽ اعليٰ دستيابي (HA) حڪمت عمليون ۽ واپار جون شيون جيڪي هر حڪمت عملي ٺاهي ٿي. RabbitMQ نوڊس جي ڪلستر تي هلائي سگھي ٿو - ۽ پوءِ ورهايل نظام جي طور تي درجه بندي ڪئي وئي آھي. جڏهن اها ورهايل سسٽم جي ڳالهه اچي ٿي، اسان اڪثر ڪري مستقل مزاجي ۽ دستيابي بابت ڳالهايون ٿا.

اهي تصور بيان ڪن ٿا ته هڪ نظام ڪيئن ڪم ڪندو آهي جڏهن اهو ناڪام ٿئي ٿو. نيٽ ورڪ ڪنيڪشن جي ناڪامي، سرور جي ناڪامي، هارڊ ڊرائيو ناڪامي، سرور جي عارضي غير موجودگيءَ سبب ڪچرو گڏ ڪرڻ، پيڪٽ جي نقصان، يا نيٽ ورڪ ڪنيڪشن جي سستي. اهو سڀ ڪجهه ڊيٽا جي نقصان يا تڪرار جي ڪري سگھي ٿو. اهو ظاهر ٿئي ٿو ته اهو ناممڪن آهي هڪ سسٽم قائم ڪرڻ لاء جيڪو مڪمل طور تي هڪجهڙائي وارو آهي (ڪابه ڊيٽا نقصان نه، ڊيٽا جي ڦيرڦار) ۽ دستياب (پڙهڻ ۽ لکڻ کي قبول ڪندو) سڀني ناڪامي حالتن لاء.

اسان ڏسنداسين ته مطابقت ۽ دستيابي اسپيڪٽرم جي سامهون سرن تي آهن، ۽ توهان کي چونڊڻ جي ضرورت آهي ته ڪهڙي طريقي سان بهتر ڪرڻ لاء. سٺي خبر اها آهي ته RabbitMQ سان هي انتخاب ممڪن آهي. توهان وٽ انهن قسم جا ”نردي“ ليور آهن توازن کي وڌيڪ مستقل مزاجي يا وڏي رسائي جي طرف منتقل ڪرڻ لاءِ.

اسان خاص ڌيان ڏينداسين ته ڪهڙيون ترتيبون تصديق ٿيل رڪارڊ جي ڪري ڊيٽا جي نقصان جي ڪري ٿي. پبلشرز، بروکرز ۽ صارفين جي وچ ۾ ذميواري جو هڪ سلسلو آهي. هڪ دفعو پيغام بروکر ڏانهن منتقل ڪيو ويو آهي، اهو هن جو ڪم آهي پيغام وڃائڻ نه. جڏهن بروکر پبلشر جي پيغام جي رسيد کي تسليم ڪري ٿو، اسان کي اميد ناهي ته اهو گم ٿي ويندو. پر اسان ڏسنداسين ته اهو اصل ۾ ٿي سگهي ٿو توهان جي بروکر ۽ پبلشر جي ترتيب جي بنياد تي.

سنگل نوڊ لچڪدار پرائمري

لچڪدار قطار/روٽنگ

RabbitMQ ۾ قطار جا ٻه قسم آهن: پائيدار ۽ غير پائيدار. سڀئي قطارون Mnesia ڊيٽابيس ۾ محفوظ ٿيل آهن. پائيدار قطارن کي نوڊ جي شروعات تي ٻيهر اشتهار ڏنو ويو آهي ۽ اهڙيء طرح ٻيهر شروع ٿيڻ، سسٽم جي حادثي، يا سرور جي حادثن کي بچايو ويندو آهي (جيستائين ڊيٽا برقرار رهي). هن جو مطلب اهو آهي ته جيستائين توهان روڊن (متبادل) ۽ قطار کي لچڪدار ٿيڻ جو اعلان ڪيو، قطار / روٽنگ انفراسٽرڪچر آن لائن واپس ايندو.

جڏهن نوڊ ٻيهر شروع ٿئي ٿي ته غير مستحڪم قطار ۽ رستن کي هٽايو ويو آهي.

مسلسل پيغام

بس ڇاڪاڻ ته هڪ قطار پائيدار آهي مطلب اهو ناهي ته ان جا سڀئي پيغام هڪ نوڊ ٻيهر شروع ٿيڻ کان بچي ويندا. صرف پبلشر پاران مقرر ڪيل پيغام جيئن پائيدار (مسلسل). مسلسل پيغام بروکر تي اضافي لوڊ ٺاهيندا آهن، پر جيڪڏهن پيغام جو نقصان ناقابل قبول آهي، ته پوء ٻيو ڪو اختيار ناهي.

چانور. 1. استحڪام ميٽرڪس

قطار آئيني سان گڏ ڪلستر

هڪ بروکر جي نقصان کان بچڻ لاء، اسان کي ضرورت آهي بيڪار. اسان ڪيترن ئي RabbitMQ نوڊس کي ڪلستر ۾ گڏ ڪري سگھون ٿا، ۽ پوء ڪيترن ئي نوڊس جي وچ ۾ قطار کي نقل ڪندي اضافي اضافو شامل ڪري سگھون ٿا. اهو طريقو، جيڪڏهن هڪ نوڊ ناڪام ٿئي ٿو، اسان ڊيٽا کي نه وڃايو ۽ موجود رهون ٿا.

قطار آئيني:

• هڪ مکيه قطار (ماسٽر)، جيڪو سڀني لکڻ ۽ پڙهڻ واري حڪمن کي حاصل ڪري ٿو
• هڪ يا وڌيڪ آئيني جيڪي مکيه قطار مان سڀئي پيغام ۽ ميٽا ڊيٽا وصول ڪن ٿا. اهي آئينا ماپڻ لاءِ نه آهن، پر خالصتاً بيڪاريءَ لاءِ آهن.

چانور. 2. قطار آئيني

Mirroring مناسب پاليسي جي ذريعي مقرر ڪيو ويو آهي. ان ۾ توھان replication coefficient ۽ حتي اھي نوڊس چونڊي سگھو ٿا جن تي قطار ھجڻ گھرجي. مثال:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (هڪ ماسٽر ۽ هڪ آئينو)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

پبلشر جي تصديق

مسلسل رڪارڊنگ حاصل ڪرڻ لاء، پبلشر جي تصديق جي ضرورت آهي. انهن جي بغير، پيغامن جي گم ٿيڻ جو خطرو آهي. هڪ تصديق پبلشر ڏانهن موڪليو ويو آهي پيغام کان پوء ڊسڪ تي لکيل آهي. RabbitMQ ڊسڪ تي پيغام لکي ٿو رسيد تي نه، پر وقتي بنياد تي، ڪيترن ئي سئو ملي سيڪنڊن جي علائقي ۾. جڏهن هڪ قطار کي آئينو ڪيو ويندو آهي، هڪ اعتراف صرف موڪليو ويندو آهي جڏهن سڀني آئيني پڻ ڊسڪ تي پيغام جي ڪاپي لکيا آهن. هن جو مطلب اهو آهي ته تصديق استعمال ڪندي دير سان وڌائي ٿو، پر جيڪڏهن ڊيٽا سيڪيورٽي اهم آهي، پوء اهي ضروري آهن.

ناڪامي جي قطار

جڏهن هڪ بروکر ڇڏي ٿو يا حادثو ڪري ٿو، ان سان گڏ سڀني قطار ليڊر (ماسٽر) ان نوڊ حادثي تي. ڪلستر وري هر ماسٽر جي پراڻي ترين آئيني کي منتخب ڪري ٿو ۽ ان کي نئين ماسٽر جي طور تي ترقي ڪري ٿو.

چانور. 3. گھڻن آئيني قطار ۽ انھن جون پاليسيون

بروکر 3 هيٺ اچي ٿو. نوٽ ڪريو ته بروکر 2 تي قطار سي آئيني کي ماسٽر ڏانهن وڌايو پيو وڃي. اهو پڻ نوٽ ڪريو ته بروکر 1 تي قطار سي لاءِ هڪ نئون آئينو ٺاهيو ويو آهي. RabbitMQ هميشه توهان جي پاليسين ۾ بيان ڪيل نقل واري عنصر کي برقرار رکڻ جي ڪوشش ڪندو آهي.

چانور. 4. بروکر 3 ناڪام ٿئي ٿو، قطار سي جي ناڪام ٿيڻ سبب

ايندڙ بروکر 1 پوي ٿو! اسان وٽ صرف هڪ بروکر بچيو آهي. قطار بي آئيني کي ماسٽر ڏانهن وڌايو ويو آهي.

جوڙ. 5

اسان بروکر 1 واپس ڪيو آهي. قطع نظر ته ڊيٽا بروکر جي نقصان ۽ وصولي کان ڪيئن بچي ٿي، سڀني آئيني قطار پيغامن کي ٻيهر شروع ڪرڻ تي رد ڪيو ويندو. اهو نوٽ ڪرڻ ضروري آهي ڇو ته ان جا نتيجا هوندا. اسان جلد ئي انهن اثرن تي نظر وجهنداسين. تنهن ڪري بروکر 1 هاڻي ٻيهر ڪلستر جو ميمبر آهي، ۽ ڪلستر پاليسين سان عمل ڪرڻ جي ڪوشش ڪري ٿو ۽ تنهن ڪري بروکر 1 تي آئيني ٺاهي ٿو.

انهي صورت ۾، بروکر 1 جو نقصان مڪمل ٿي ويو، جيئن ڊيٽا هئي، تنهنڪري اڻڄاتل قطار بي مڪمل طور تي گم ٿي ويو.

چانور. 6. بروکر 1 واپسي جي خدمت ۾

بروکر 3 واپس آن لائن آھي، تنھنڪري قطار A ۽ B پنھنجي HA پاليسين کي پورو ڪرڻ لاءِ ان تي ٺاھيل آئيني کي واپس وٺن. پر هاڻي سڀئي مکيه قطار هڪ نوڊ تي آهن! اهو مثالي نه آهي، نوڊس جي وچ ۾ هڪ به تقسيم بهتر آهي. بدقسمتي سان، ماسٽرن کي بحال ڪرڻ لاء هتي تمام گهڻو اختيار نه آهن. اسان هن مسئلي تي بعد ۾ واپس ايندا ڇو ته اسان کي ڏسڻ جي ضرورت آهي قطار هم وقت سازي کي پهرين.

چانور. 7. بروکر 3 واپسي جي خدمت ۾. سڀ مکيه قطار هڪ نوڊ تي!

تنهن ڪري هاڻي توهان کي اهو خيال رکڻ گهرجي ته آئيني ڪيئن بيڪار ۽ غلطي رواداري مهيا ڪن ٿا. اهو هڪ واحد نوڊ جي ناڪامي جي صورت ۾ دستيابي کي يقيني بڻائي ٿو ۽ ڊيٽا جي نقصان جي خلاف حفاظت ڪري ٿو. پر اسان اڃا تائين نه ڪيو آهي، ڇاڪاڻ ته حقيقت ۾ اهو تمام گهڻو پيچيده آهي.

هم وقت

جڏهن هڪ نئون آئينو ٺاهي، سڀئي نوان پيغام هميشه هن آئيني ۽ ڪنهن ٻئي ڏانهن نقل ڪيا ويندا. جيئن ته ماسٽر قطار ۾ موجود ڊيٽا لاء، اسان ان کي هڪ نئين آئيني ڏانهن نقل ڪري سگهون ٿا، جيڪو ماسٽر جي مڪمل ڪاپي بڻجي ويندو آهي. اسان اهو پڻ چونڊي سگھون ٿا ته موجوده پيغامن کي نقل نه ڪيو وڃي ۽ مکيه قطار ۽ نئين آئيني کي وقت ۾ گڏ ٿيڻ ڏيو، نوان پيغام دم تي پهچي وڃن ۽ موجوده پيغامن کي مکيه قطار جي مٿو ڇڏي وڃي.

هي هم وقت سازي خودڪار طور تي يا دستي طور تي ڪيو ويندو آهي ۽ قطار پاليسي استعمال ڪندي منظم ڪيو ويندو آهي. اچو ته هڪ مثال ڏسو.

اسان وٽ ٻه آئيني قطارون آهن. قطار A خودڪار طريقي سان هم وقت سازي ڪئي وئي آهي، ۽ قطار بي دستي طور تي هم وقت سازي ڪئي وئي آهي. ٻنهي قطارن ۾ ڏهه پيغام آهن.

چانور. 8. مختلف هم وقت سازي جي طريقن سان ٻه قطار

هاڻي اسان بروکر 3 کي وڃائي رهيا آهيون.

چانور. 9. بروکر 3 گر

بروکر 3 واپسي جي خدمت ۾. ڪلستر نئين نوڊ تي هر قطار لاءِ هڪ آئينو ٺاهي ٿو ۽ خودڪار طريقي سان نئين قطار A کي ماسٽر سان هم وقت سازي ڪري ٿو. بهرحال، نئين قطار بي جو آئينو خالي رهي ٿو. اهڙي طرح اسان وٽ قطار A تي مڪمل بيڪار آهي ۽ موجوده قطار B پيغامن لاءِ صرف هڪ آئينو آهي.

چانور. 10. قطار A جو نئون آئيني سڀني موجود پيغامن کي حاصل ڪري ٿو، پر قطار B جو نئون آئينو نٿو ملي.

ڏهه وڌيڪ نياپا ٻنهي قطارن ۾ اچن ٿا. بروکر 2 پوءِ حادثو ٿئي ٿو ۽ قطار A سڀ کان پراڻي آئيني ڏانهن واپس اچي ٿو، جيڪو بروکر 1 تي آهي. جڏهن اهو ناڪام ٿئي ٿو ته ڪو به ڊيٽا نقصان نه آهي. قطار B ۾، ماسٽر ۾ ويهه پيغام آهن ۽ آئيني ۾ صرف ڏهه آهن ڇو ته هن قطار ڪڏهن به اصل ڏهن پيغامن کي نقل نه ڪيو آهي.

چانور. 11. قطار A پيغامن کي وڃائڻ کان سواءِ بروکر 1 ڏانهن واپس اچي ٿو

ڏهه وڌيڪ نياپا ٻنهي قطارن ۾ اچن ٿا. ھاڻي بروکر 1 حادثو. قطار A آساني سان آئيني ڏانھن تبديل ڪري ٿو بغير پيغام وڃائڻ جي. بهرحال، قطار بي مسئلا ٿي رهيو آهي. هن موقعي تي اسان يا ته دستيابي يا استحڪام کي بهتر ڪري سگهون ٿا.

جيڪڏهن اسان رسائي کي بهتر بڻائڻ چاهيون ٿا، ته پوءِ پاليسي ناڪامي تي واڌارو ۾ نصب ٿيڻ گهرجي هميشه. هي ڊفالٽ قيمت آهي، تنهنڪري توهان صرف پاليسي بيان نه ڪري سگهو ٿا. انهي صورت ۾، اسان لازمي طور تي غير مطابقت واري آئيني ۾ ناڪامي جي اجازت ڏئي رهيا آهيون. اهو پيغام گم ٿي ويندو، پر قطار پڙهڻ ۽ لکڻ جي قابل رهندي.

چانور. 12. قطار A کي پيغام وڃائڻ کان سواءِ بروکر 3 ڏانهن واپس ڪيو ويو آهي. قطار B واپس بروکر 3 ڏانھن ڏھن پيغامن سان گڏ گم ٿي ويو

اسان پڻ انسٽال ڪري سگھون ٿا ha-promote-on-failure معنيٰ ۾ when-synced. انهي حالت ۾، آئيني ڏانهن واپس موٽڻ جي بدران، قطار انتظار ڪندو جيستائين بروکر 1 ان جي ڊيٽا سان گڏ آن لائن موڊ تي واپس اچي. ان جي واپسي کان پوء، مکيه قطار واپس آهي بروکر 1 تي بغير ڪنهن ڊيٽا جي نقصان جي. ڊيٽا سيڪيورٽي لاء دستيابي قربان ڪئي وئي آهي. پر اھو ھڪڙو خطرناڪ موڊ آھي جيڪو مڪمل ڊيٽا جي نقصان جي ڪري سگھي ٿو، جنھن کي اسين جلد ئي ڏسنداسين.

چانور. 13. بروکر 1 کي وڃائڻ کان پوءِ قطار B موجود نه رهي

توھان پڇي سگھو ٿا، "ڇا اھو بھتر آھي ته ڪڏھن به خودڪار هم وقت سازي کي استعمال نه ڪيو وڃي؟" جواب اهو آهي ته هم وقت سازي هڪ بلاڪنگ آپريشن آهي. هم وقت سازي جي دوران، مکيه قطار ڪنهن به پڙهڻ يا لکڻ جي عمل کي انجام نه ڏئي سگهي ٿي!

اچو ته هڪ مثال ڏسو. هاڻي اسان وٽ تمام گهڻيون قطارون آهن. اهي اهڙي سائيز تائين ڪيئن وڌي سگهن ٿا؟ ڪيترن ئي سببن لاء:

• قطار فعال طور تي استعمال نه ڪيا ويا آهن
• اهي تيز رفتار قطارون آهن، ۽ هاڻي صارفين سست آهن
• اهو تيز رفتار قطار آهي، اتي هڪ خرابي آهي ۽ صارفين کي پڪڙي رهيا آهن

چانور. 14. مختلف هم وقت سازي جي طريقن سان ٻه وڏيون قطارون

هاڻي بروکر 3 پوي ٿو.

چانور. 15. بروکر 3 پوي ٿو، هر قطار ۾ هڪ ماسٽر ۽ آئيني ڇڏڻ

بروکر 3 واپس آن لائن اچي ٿو ۽ نوان آئيني ٺاهيا ويا آهن. مکيه قطار A موجوده پيغامن کي نئين آئيني ڏانهن نقل ڪرڻ شروع ڪري ٿي، ۽ هن وقت تائين قطار دستياب ناهي. ڊيٽا کي نقل ڪرڻ ۾ ٻه ڪلاڪ لڳن ٿا، نتيجي ۾ هن قطار لاءِ ٻه ڪلاڪ دير جو وقت!

بهرحال، قطار بي پوري عرصي دوران موجود رهي ٿي. هن رسائي لاءِ ڪجهه بيڪار قربان ڪيو.

چانور. 16. هم وقت سازي دوران قطار موجود نه رهي

ٻن ڪلاڪن کان پوء، قطار A پڻ دستياب ٿي ويندي آهي ۽ ٻيهر پڙهڻ ۽ لکڻ شروع ڪري سگهي ٿو.

تازيون

هم وقت سازي جي دوران هي بلاڪ ڪرڻ وارو رويو تمام وڏي قطارن سان ڪلستر کي اپڊيٽ ڪرڻ ڏکيو بڻائي ٿو. ڪجهه نقطي تي، ماسٽر نوڊ کي ٻيهر شروع ڪرڻ جي ضرورت آهي، جنهن جو مطلب آهي يا ته آئيني ڏانهن سوئچ ڪرڻ يا قطار کي بند ڪرڻ جڏهن سرور کي اپڊيٽ ڪيو پيو وڃي. جيڪڏهن اسان منتقلي لاءِ چونڊون ٿا، ته آئيني کي هم وقت سازي نه ڪرڻ جي صورت ۾ اسان پيغام وڃائي ويهنداسين. ڊفالٽ طور، هڪ بروکر جي بندش جي دوران، هڪ غير هم وقت سازي آئيني کي ناڪام نه ڪيو ويو آهي. هن جو مطلب اهو آهي ته جيترو جلدي بروکر واپس اچي ٿو، اسان ڪنهن به پيغام کي نه وڃايو، صرف نقصان هڪ سادي قطار هئي. رويي جا ضابطا جڏهن هڪ بروکر ختم ٿي ويندو آهي پاليسي طرفان مقرر ڪيل آهن ha-promote-on-shutdown. توھان ٻن قدرن مان ھڪڙي سيٽ ڪري سگھو ٿا:

• always= غير هم وقت ٿيل آئيني ڏانهن منتقلي فعال آهي
• when-synced= صرف هڪ هم وقت سازي آئيني ڏانهن منتقلي، ٻي صورت ۾ قطار اڻ پڙهيل ۽ ناقابل لکڻ جي قابل ٿي ويندي. جيئن ئي بروکر جي واپسي تي قطار واپس اچي ٿي خدمت ۾

هڪ طريقو يا ٻيو، وڏي قطار سان توهان کي ڊيٽا جي نقصان ۽ غير موجودگي جي وچ ۾ چونڊڻو پوندو.

جڏهن دستيابي ڊيٽا سيڪيورٽي کي بهتر بڻائي ٿي

فيصلو ڪرڻ کان پهريان غور ڪرڻ لاء هڪ وڌيڪ پيچيدگي آهي. جڏهن ته خودڪار هم وقت سازي فالتو لاءِ بهتر آهي، اهو ڪيئن اثر انداز ٿئي ٿو ڊيٽا سيڪيورٽي؟ يقينا، بهتر بيڪارگي سان، RabbitMQ موجود پيغامن کي وڃائڻ جو امڪان گهٽ آهي، پر پبلشرن جي نئين پيغامن بابت ڇا؟

هتي توهان کي هيٺين تي غور ڪرڻ جي ضرورت آهي:

• ڇا پبلشر صرف هڪ غلطي واپس ڪري سگهي ٿو ۽ اپ اسٽريم سروس يا صارف کي بعد ۾ ٻيهر ڪوشش ڪري سگهي ٿو؟
• ڇا پبلشر پيغام کي مقامي طور تي يا ڊيٽابيس ۾ محفوظ ڪري سگھي ٿو ته پوءِ ٻيهر ڪوشش ڪري؟

جيڪڏهن پبلشر صرف پيغام کي رد ڪري سگهي ٿو، حقيقت ۾، رسائي کي بهتر بنائڻ پڻ ڊيٽا جي حفاظت کي بهتر بڻائي ٿو.

اهڙيء طرح، هڪ توازن ڳولڻ گهرجي، ۽ حل مخصوص صورتحال تي منحصر آهي.

ha-promote-on-failure=جڏهن هم وقت سازي سان مسئلا

نظريه ناڪامي تي واڌارو= جڏهن- هم وقت اهو آهي ته اسان هڪ غير هم وقت ٿيل آئيني کي تبديل ڪرڻ کان روڪيو ۽ ان سان گڏ ڊيٽا جي نقصان کان بچي. قطار اڻ پڙهيل يا لکڻ جي قابل رهي ٿي. ان جي بدران، اسان ڪوشش ڪريون ٿا ته تباهه ٿيل بروکر کي ان جي ڊيٽا برقرار رکڻ سان بحال ڪريو ته جيئن اهو ڊيٽا جي نقصان کان سواء ماسٽر طور ڪم شروع ڪري سگهي.

پر (۽ اھو ھڪڙو وڏو آھي پر) جيڪڏھن بروکر پنھنجي ڊيٽا کي وڃائي ڇڏيو آھي، پوء اسان وٽ ھڪڙو وڏو مسئلو آھي: قطار گم ٿي ويو آھي! سڀ ڊيٽا ختم ٿي وئي آهي! جيتوڻيڪ توهان وٽ آئينا آهن جيڪي اڪثر ڪري مکيه قطار سان پڪڙيندا آهن، اهي آئيني پڻ رد ڪيا ويندا آهن.

ساڳئي نالي سان هڪ نوڊ ٻيهر شامل ڪرڻ لاءِ، اسان ڪلسٽر کي چئون ٿا ته گم ٿيل نوڊ کي وساريو (ڪمانڊ سان rabbitmqctl forget_cluster_node) ۽ ساڳئي ميزبان نالي سان هڪ نئون بروکر شروع ڪريو. جڏهن ته ڪلستر گم ٿيل نوڊ کي ياد ڪري ٿو، اهو پراڻي قطار ۽ غير مطابقت رکندڙ آئيني کي ياد ڪري ٿو. جڏهن هڪ ڪلستر کي يتيم نوڊ کي وسارڻ لاءِ چيو ويندو آهي ته اها قطار به وساري ويندي آهي. هاڻي اسان کي ٻيهر اعلان ڪرڻو پوندو. اسان سڀني ڊيٽا کي وڃائي ڇڏيو، جيتوڻيڪ اسان وٽ ڊيٽا جي هڪ جزوي سيٽ سان آئيني هئي. اهو بهتر ٿيندو ته هڪ غير هم وقت سازي آئيني کي تبديل ڪرڻ لاء!

تنهن ڪري، دستي هم وقت سازي (۽ هم وقت سازي ۾ ناڪامي) سان ميلاپ ۾ ha-promote-on-failure=when-syncedمنهنجي خيال ۾، ڪافي خطرناڪ. دستاويزن جو چوڻ آهي ته هي اختيار موجود آهي ڊيٽا جي حفاظت لاء، پر اهو هڪ ٻٽي چاقو آهي.

ماسٽر ٻيهر توازن

جيئن واعدو ڪيو ويو آهي، اسان هڪ يا ڪيترن ئي نوڊس تي سڀني ماسٽرن جي جمع ٿيڻ جي مسئلي ڏانهن موٽون ٿا. اهو به ٿي سگهي ٿو رولنگ ڪلستر اپڊيٽ جي نتيجي ۾. ٽن نوڊ ڪلستر ۾، سڀ ماسٽر قطارون ھڪڙي يا ٻن نوڊس تي گڏ ٿينديون.

ماهرن کي بحال ڪرڻ ٻن سببن لاءِ مسئلو ٿي سگهي ٿو:

• ريبلانسنگ کي انجام ڏيڻ لاء ڪي سٺا اوزار نه آهن
• قطار جي هم وقت سازي

اتي هڪ ٽين ڌر آهي rebalanceing لاء پلگ ان، جنهن کي سرڪاري طور تي سهڪار نه ڪيو ويو آهي. RabbitMQ دستي ۾ ٽئين پارٽي پلگ ان جي حوالي سان چيو: "پلگ ان ڪجهه اضافي ترتيبن ۽ رپورٽنگ جا اوزار مهيا ڪري ٿي، پر RabbitMQ ٽيم پاران سپورٽ يا تصديق ٿيل ناهي. پنهنجي خطري تي استعمال ڪريو."

HA پاليسين ذريعي مکيه قطار کي منتقل ڪرڻ لاء هڪ ٻي چال آهي. دستي جو ذڪر آهي اسڪرپٽ هن لاء. اهو هن طرح ڪم ڪري ٿو:

• هڪ عارضي پاليسي استعمال ڪندي سڀني آئيني کي هٽائي ٿو جيڪا موجوده HA پاليسي کان اعلي ترجيح آهي.
• نوڊ موڊ استعمال ڪرڻ لاءِ HA عارضي پاليسي کي تبديل ڪري ٿو، نوڊ جي وضاحت ڪندي جنهن ۾ ماسٽر قطار کي منتقل ڪيو وڃي.
• پش لڏپلاڻ لاءِ قطار کي هم وقت سازي ڪري ٿو.
• لڏپلاڻ مڪمل ٿيڻ کان پوء، عارضي پاليسي کي ختم ڪري ٿو. شروعاتي HA پاليسي اثر انداز ٿئي ٿي ۽ آئيني جو گهربل تعداد ٺاھيو ويو آھي.

نقصان اهو آهي ته اهو طريقو ڪم نه ڪري سگھي ٿو جيڪڏهن توهان وٽ وڏيون قطارون آهن يا سخت بيڪار گهربل گهرجن.

هاڻي اچو ته ڏسون ته RabbitMQ ڪلسٽر ڪيئن ڪم ڪن ٿا نيٽ ورڪ پارٽيشنن سان.

رابطي جو نقصان

ورهايل سسٽم جا نوڊس نيٽ ورڪ لنڪس سان ڳنڍيل آهن، ۽ نيٽ ورڪ لنڪس ٿي سگهن ٿا ۽ ختم ٿي ويندا. بندش جي تعدد جو دارومدار مقامي انفراسٽرڪچر يا چونڊيل بادل جي اعتبار تي آهي. ڪنهن به صورت ۾، تقسيم سسٽم انهن سان مقابلو ڪرڻ جي قابل هوندو. هڪ دفعو ٻيهر اسان وٽ دستيابي ۽ استحڪام جي وچ ۾ هڪ انتخاب آهي، ۽ ٻيهر سٺي خبر اها آهي ته RabbitMQ ٻنهي اختيارن کي مهيا ڪري ٿو (صرف ساڳئي وقت نه).

RabbitMQ سان اسان وٽ ٻه مکيه اختيار آهن:

• منطقي تقسيم جي اجازت ڏيو (تقسيم دماغ). هي دستيابي کي يقيني بڻائي ٿو، پر ڊيٽا جي نقصان جو سبب ٿي سگھي ٿو.
• منطقي جدائي کي بند ڪريو. نتيجو ٿي سگھي ٿو مختصر مدت جي دستيابي جي نقصان تي منحصر ڪري ٿو ته ڪئين ڪلائنٽ ڪلستر سان ڳنڍيل آھن. ٻن نوڊ ڪلستر ۾ مڪمل غير موجودگي کي پڻ ڏسجي سگھي ٿو.

پر منطقي جدائي ڇا آهي؟ اهو آهي جڏهن هڪ ڪلستر ٻن حصن ۾ ورهايل آهي نيٽ ورڪ ڪنيڪشن جي نقصان جي ڪري. هر پاسي، آئيني کي هڪ ماسٽر ڏانهن وڌايو ويو آهي، تنهنڪري آخرڪار ڪيترائي ماسٽر في موڙ آهن.

چانور. 17. مکيه قطار ۽ ٻه آئيني، هر هڪ الڳ نوڊ تي. پوء هڪ نيٽ ورڪ ناڪامي ٿئي ٿي ۽ هڪ آئيني الڳ ٿي وڃي ٿي. جدا ٿيل نوڊ ڏسي ٿو ته ٻيا ٻه گر ٿي ويا آهن ۽ پنهنجي آئيني کي ماسٽر ڏانهن وڌايو. اسان وٽ ھاڻي ٻه مکيه قطارون آھن، ٻئي لکڻ جي قابل ۽ پڙھڻ لائق.

جيڪڏهن پبلشر ٻنهي ماسٽرن ڏانهن ڊيٽا موڪليندا آهن، اسان قطار جي ٻن مختلف نقلن سان ختم ڪنداسين.

RabbitMQ جا مختلف طريقا يا ته دستيابي يا استحڪام مهيا ڪن ٿا.

نظر انداز موڊ (ڊفالٽ)

هي موڊ رسائي کي يقيني بڻائي ٿو. رابطي جي نقصان کان پوء، هڪ منطقي جدائي ٿئي ٿي. رابطي جي بحال ٿيڻ کان پوء، منتظم کي اهو فيصلو ڪرڻ گهرجي ته ڪهڙي ورهاڱي کي ترجيح ڏني وڃي. گم ٿيڻ واري پاسي کي ٻيهر شروع ڪيو ويندو ۽ ان پاسي تي گڏ ڪيل سڀ ڊيٽا گم ٿي ويندا.

چانور. 18. ٽي پبلشر ٽن بروکرز سان لاڳاپيل آهن. اندروني طور تي، ڪلستر سڀني درخواستن کي بروکر 2 تي مکيه قطار ڏانهن روانو ڪري ٿو.

هاڻي اسان بروکر 3 کي وڃائي رهيا آهيون. هو ڏسي ٿو ته ٻيا بروکر بند ٿي ويا آهن ۽ پنهنجي آئيني کي ماسٽر ڏانهن وڌايو. اهڙي طرح هڪ منطقي جدائي ٿئي ٿي.

چانور. 19. منطقي تقسيم (تقسيم-دماغ). رڪارڊ ٻن مکيه قطارن ۾ وڃن ٿا، ۽ ٻه ڪاپيون ڌار ٿي وڃن ٿيون.

رابطو بحال ٿيو، پر منطقي جدائي باقي رهي ٿي. منتظم کي دستي طور تي وڃائڻ واري پاسي کي چونڊڻ گهرجي. هيٺ ڏنل صورت ۾، منتظم بروکر 3 کي ريبوٽ ڪري ٿو. سڀئي پيغام جيڪي هن منتقل ڪرڻ جو انتظام نه ڪيو هو گم ٿي ويا آهن.

چانور. 20. منتظم بروکر 3 کي غير فعال ڪري ٿو.

چانور. 21. ايڊمنسٽريٽر بروکر 3 کي شروع ڪري ٿو ۽ اهو ڪلستر ۾ شامل ٿئي ٿو، سڀني پيغامن کي وڃائي ٿو جيڪي اتي ڇڏي ويا هئا.

رابطي جي نقصان جي دوران ۽ ان جي بحالي کان پوء، ڪلستر ۽ هي قطار پڙهڻ ۽ لکڻ لاء موجود هئا.

خودڪار شفا موڊ

ساڳئي طرح ڪم ڪري ٿو نظر انداز موڊ، سواء ان جي ته ڪلستر خود بخود ڪنيڪشن کي ورهائڻ ۽ بحال ڪرڻ کان پوء گم ٿيڻ واري پاسي کي چونڊيندو آهي. گم ٿيل طرف واپس ڪلستر خالي ڪري ٿو، ۽ قطار سڀني پيغامن کي وڃائي ٿو جيڪي صرف ان پاسي ڏانهن موڪليا ويا هئا.

اقليتي موڊ کي روڪيو

جيڪڏهن اسان نٿا چاهيون ته منطقي ورهاڱي جي اجازت ڏيو، ته پوء اسان جو واحد اختيار اهو آهي ته ڪلستر ورهاڱي کان پوء ننڍي پاسي تي پڙهڻ ۽ لکڻ کي رد ڪيو وڃي. جڏهن بروکر ڏسي ٿو ته اهو ننڍڙو پاسي تي آهي، اهو ڪم کي معطل ڪري ٿو، اهو آهي، اهو سڀني موجوده ڪنيڪشن کي بند ڪري ٿو ۽ ڪنهن به نئين کي رد ڪري ٿو. هڪ ڀيرو في سيڪنڊ اهو ڪنيڪشن جي بحالي جي جانچ ڪري ٿو. هڪ دفعو ڪنيڪشن بحال ٿئي ٿي، اهو آپريشن شروع ڪري ٿو ۽ ڪلستر ۾ شامل ٿئي ٿو.

چانور. 22. ٽي پبلشر ٽن بروکرز سان لاڳاپيل آهن. اندروني طور تي، ڪلستر سڀني درخواستن کي بروکر 2 تي مکيه قطار ڏانهن روانو ڪري ٿو.

بروکرز 1 ۽ 2 وري بروکر 3 مان ورهائجن ٿا. پنھنجي آئيني کي ماسٽر ڏانھن وڌائڻ جي بدران، بروکر 3 کي معطل ڪري ٿو ۽ غير موجود ٿي وڃي ٿو.

چانور. 23. بروکر 3 روڪي ٿو، سڀني ڪلائنٽ کي ختم ڪري ٿو، ۽ ڪنيڪشن جي درخواستن کي رد ڪري ٿو.

هڪ دفعو ڪنيڪشن بحال ٿيو، اهو ڪلستر ڏانهن موٽندو.

اچو ته هڪ ٻيو مثال ڏسو جتي مکيه قطار بروکر 3 تي آهي.

چانور. 24. بروکر 3 تي مکيه قطار.

ان کان پوء رابطي جو ساڳيو نقصان ٿئي ٿو. بروکر 3 روڪي ٿو ڇاڪاڻ ته اهو ننڍڙو پاسي تي آهي. ٻئي پاسي، نوڊس ڏسي ٿو ته بروکر 3 بند ٿي ويو آهي، تنهنڪري بروکرز 1 ۽ 2 کان پراڻي آئيني کي ماسٽر ڏانهن وڌايو ويو آهي.

چانور. 25. بروکر 2 ڏانھن منتقلي جيڪڏھن بروکر 3 دستياب نه آھي.

جڏهن ڪنيڪشن بحال ٿئي ٿي، بروکر 3 ڪلستر ۾ شامل ٿيندو.

چانور. 26. ڪلستر عام آپريشن ڏانهن موٽيو آهي.

هتي سمجهڻ لاءِ اهم ڳالهه اها آهي ته اسان کي مستقل مزاجي ملي ٿي، پر اسان دستيابي به حاصل ڪري سگهون ٿا، جيڪڏهن اسان ڪاميابيء سان ڪلائنٽ کي اڪثر سيڪشن ڏانهن منتقل ڪنداسين. اڪثر حالتن لاءِ، مان ذاتي طور چونڊيندس اقليتي موڊ کي روڪيو، پر اهو واقعي انفرادي صورت تي منحصر آهي.

دستيابي کي يقيني بڻائڻ لاء، اهو ضروري آهي ته گراهڪ ڪاميابيء سان ميزبان سان ڳنڍڻ کي يقيني بڻائي. اچو ته اسان جي اختيارن کي ڏسو.

ڪسٽمر رابطي کي يقيني بڻائڻ

اسان وٽ ڪيترائي آپشن آهن ته ڪيئن ڪلسٽر جي مکيه حصي ڏانهن گراهڪن کي سڌو سنئون يا ڪم ڪندڙ نوڊس ڏانهن (هڪ نوڊ ناڪام ٿيڻ کان پوء) رابطي جي نقصان کان پوء. پهرين، اچو ته ياد رکون ته هڪ مخصوص قطار هڪ مخصوص نوڊ تي ميزباني ڪئي وئي آهي، پر رستن ۽ پاليسين سڀني نوڊس تي نقل ٿيل آهن. ڪلائنٽ ڪنهن به نوڊ سان ڳنڍي سگهن ٿا، ۽ اندروني روٽنگ انهن کي سڌو رستو ڏيکاريندو جتي انهن کي وڃڻ جي ضرورت آهي. پر جڏهن هڪ نوڊ معطل ڪيو ويو آهي، اهو ڪنيڪشن کي رد ڪري ٿو، تنهنڪري گراهڪن کي ٻئي نوڊ سان ڳنڍڻ گهرجي. جيڪڏهن نوڊ بند ٿي وڃي، اتي ٿورو ئي آهي جيڪو هو ڪري سگهي ٿو.

اسان جا اختيار:

• ڪلستر کي لوڊ بيلنس استعمال ڪندي پهچايو ويو آهي جيڪو صرف نوڊس ذريعي چڪر ڪندو آهي ۽ ڪلائنٽ ڪامياب ٿيڻ تائين ٻيهر ڳنڍڻ جي ڪوشش ڪندا آهن. جيڪڏهن ڪو نوڊ هيٺ آهي يا معطل آهي، ته پوءِ ان نوڊ سان ڳنڍڻ جون ڪوششون ناڪام ٿينديون، پر بعد ۾ ڪيل ڪوششون ٻين سرورن ڏانهن وينديون (گول-رابن فيشن ۾). ھي موزون آھي مختصر مدت جي ڪنيڪشن جي نقصان يا ھيٺ ٿيل سرور لاءِ جيڪو جلدي واپس آندو ويندو.
• لوڊ بيلنسر ذريعي ڪلستر تائين رسائي ڪريو ۽ لسٽ مان معطل ٿيل / ناڪام ٿيل نوڊس کي هٽايو جيئن اهي معلوم ڪيا وڃن. جيڪڏهن اسان اهو جلدي ڪريون ٿا، ۽ جيڪڏهن گراهڪ ڪنيڪشن کي ٻيهر ڪوشش ڪرڻ جي قابل آهن، ته اسان مسلسل دستيابي حاصل ڪنداسين.
• هر ڪلائنٽ کي سڀني نوڊس جي هڪ فهرست ڏيو، ۽ ڪلائنٽ بي ترتيب سان انهن مان هڪ چونڊيو جڏهن ڳنڍيندي. جيڪڏهن ڳنڍڻ جي ڪوشش ڪندي هڪ غلطي ملي ٿي، اهو فهرست ۾ ايندڙ نوڊ ڏانهن هلندو آهي جيستائين اهو ڳنڍيندو آهي.
• 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 (پر وڏي غير فعال قطارن لاءِ مينوئل موڊ گهربل هجي؛ اهو به غور ڪريو ته ڇا غير موجودگي پيغامن جي گم ٿيڻ جو سبب بڻجندي)
• اقليتي موڊ کي روڪيو
• مسلسل پيغام

اسان اڃا تائين غلطي رواداري ۽ اعلي دستيابي جي سڀني مسئلن کي ڍڪي نه ڇڏيو آهي؛ مثال طور، ڪيئن محفوظ طور تي انتظامي طريقا انجام ڏيڻ (جهڙوڪ رولنگ اپڊيٽ). اسان کي فيڊريشن ۽ شوول پلگ ان بابت پڻ ڳالهائڻ جي ضرورت آهي.

جيڪڏهن مون کي ٻيو ڪجهه ياد اچي ويو آهي، مهرباني ڪري مون کي خبر ڏيو.

پڻ ڏسو منهنجو پوسٽ، جتي آئون هن مضمون ۾ بيان ڪيل ڪجهه پيغام جي نقصان واري منظرنامي کي جانچڻ لاءِ Docker ۽ Blockade استعمال ڪندي RabbitMQ ڪلستر تي تباهي آڻيان ٿو.

گذريل مضمونن جي سلسلي ۾:
نمبر 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