غلطی کی برداشت اور اعلی دستیابی بڑے موضوعات ہیں، اس لیے ہم الگ الگ مضامین 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 نیچے جاتا ہے۔ نوٹ کریں کہ بروکر 2 پر قطار سی آئینے کو ماسٹر پر ترقی دی جا رہی ہے۔ یہ بھی نوٹ کریں کہ بروکر 1 پر قطار C کے لیے ایک نیا آئینہ بنایا گیا ہے۔ RabbitMQ ہمیشہ آپ کی پالیسیوں میں بیان کردہ نقل کے عنصر کو برقرار رکھنے کی کوشش کرتا ہے۔

چاول۔ 4. بروکر 3 ناکام ہو جاتا ہے، جس کی وجہ سے قطار C ناکام ہو جاتی ہے۔

اگلا بروکر 1 گر جائے گا! ہمارے پاس صرف ایک بروکر رہ گیا ہے۔ قطار بی کے آئینہ کو ترقی دے کر ماسٹر بنایا جاتا ہے۔

انجیر 5

ہم نے بروکر 1 واپس کر دیا ہے۔ اس سے قطع نظر کہ ڈیٹا بروکر کے نقصان اور بازیابی سے کتنی اچھی طرح سے بچ جاتا ہے، دوبارہ شروع ہونے پر تمام عکس والے قطار کے پیغامات کو ضائع کر دیا جاتا ہے۔ یہ نوٹ کرنا ضروری ہے کیونکہ اس کے نتائج ہوں گے۔ ہم جلد ہی ان مضمرات کو دیکھیں گے۔ لہذا بروکر 1 اب دوبارہ کلسٹر کا ممبر ہے، اور کلسٹر پالیسیوں کی تعمیل کرنے کی کوشش کرتا ہے اور اس لیے بروکر 1 پر آئینہ بناتا ہے۔

اس صورت میں، بروکر 1 کا نقصان مکمل تھا، جیسا کہ ڈیٹا تھا، اس لیے بغیر عکس والی قطار B مکمل طور پر ختم ہو گئی تھی۔

چاول۔ 6. بروکر 1 سروس پر واپس آتا ہے۔

بروکر 3 واپس آن لائن ہے، لہذا قطار A اور B اپنی HA پالیسیوں کو پورا کرنے کے لیے اس پر بنائے گئے آئینہ واپس لے لیتے ہیں۔ لیکن اب تمام اہم قطاریں ایک نوڈ پر ہیں! یہ مثالی نہیں ہے، نوڈس کے درمیان یکساں تقسیم بہتر ہے۔ بدقسمتی سے، ماسٹرز کو دوبارہ متوازن کرنے کے لیے یہاں زیادہ اختیارات نہیں ہیں۔ ہم بعد میں اس مسئلے پر واپس آئیں گے کیونکہ ہمیں پہلے قطار کی مطابقت پذیری کو دیکھنے کی ضرورت ہے۔

چاول۔ 7. بروکر 3 سروس پر واپس آتا ہے۔ ایک نوڈ پر تمام اہم قطاریں!

تو اب آپ کو اندازہ ہونا چاہیے کہ آئینے کس طرح بے کار اور غلطی برداشت کرتے ہیں۔ یہ سنگل نوڈ کی ناکامی کی صورت میں دستیابی کو یقینی بناتا ہے اور ڈیٹا کے نقصان سے بچاتا ہے۔ لیکن ہم نے ابھی تک کام نہیں کیا، کیونکہ حقیقت میں یہ بہت زیادہ پیچیدہ ہے۔

ہم آہنگی

نیا آئینہ بناتے وقت، تمام نئے پیغامات ہمیشہ اس آئینے اور کسی دوسرے پر نقل کیے جائیں گے۔ جہاں تک ماسٹر قطار میں موجود ڈیٹا کا تعلق ہے، ہم اسے ایک نئے آئینے میں نقل کر سکتے ہیں، جو ماسٹر کی مکمل کاپی بن جاتا ہے۔ ہم یہ بھی منتخب کر سکتے ہیں کہ موجودہ پیغامات کی نقل نہ بنائیں اور مرکزی قطار اور نئے آئینے کو وقت کے ساتھ ایک دوسرے کے قریب آنے دیں، نئے پیغامات دم پر پہنچیں اور موجودہ پیغامات مرکزی قطار کے سر سے نکل جائیں۔

یہ مطابقت پذیری خود بخود یا دستی طور پر کی جاتی ہے اور قطار کی پالیسی کا استعمال کرتے ہوئے اس کا نظم کیا جاتا ہے۔ آئیے ایک مثال دیکھتے ہیں۔

ہمارے پاس دو عکس والی قطاریں ہیں۔ قطار A خود بخود مطابقت پذیر ہوتی ہے، اور قطار B دستی طور پر مطابقت پذیر ہوتی ہے۔ دونوں قطاروں میں دس پیغامات ہیں۔

چاول۔ 8. مختلف ہم وقت سازی کے طریقوں کے ساتھ دو قطاریں۔

اب ہم بروکر 3 کو کھو رہے ہیں۔

چاول۔ 9. بروکر 3 گر گیا۔

بروکر 3 سروس پر واپس آتا ہے۔ کلسٹر نئے نوڈ پر ہر قطار کے لیے ایک آئینہ بناتا ہے اور خود بخود نئی قطار A کو ماسٹر کے ساتھ ہم آہنگ کرتا ہے۔ تاہم نئی قطار بی کا عکس خالی رہتا ہے۔ اس طرح ہمارے پاس قطار A پر مکمل فالتو پن ہے اور موجودہ قطار B پیغامات کے لیے صرف ایک آئینہ ہے۔

چاول۔ 10. قطار A کا نیا آئینہ تمام موجودہ پیغامات وصول کرتا ہے، لیکن قطار B کا نیا عکس نہیں ملتا۔

دونوں قطاروں میں مزید دس پیغامات آتے ہیں۔ بروکر 2 پھر کریش ہو جاتا ہے اور قطار A سب سے پرانے آئینے پر واپس آ جاتا ہے، جو بروکر 1 پر ہوتا ہے۔ جب یہ ناکام ہو جاتا ہے تو ڈیٹا کا کوئی نقصان نہیں ہوتا ہے۔ قطار B میں، ماسٹر میں بیس پیغامات ہیں اور آئینے میں صرف دس ہیں کیونکہ اس قطار نے کبھی بھی اصل دس پیغامات کو نقل نہیں کیا۔

چاول۔ 11. قطار A پیغامات کو کھونے کے بغیر بروکر 1 پر واپس آتی ہے۔

دونوں قطاروں میں مزید دس پیغامات آتے ہیں۔ اب بروکر 1 کریش ہو گیا ہے۔ قطار A پیغامات کو کھونے کے بغیر آسانی سے آئینے میں بدل جاتا ہے۔ تاہم، قطار B مسائل کا شکار ہے۔ اس وقت ہم دستیابی یا مستقل مزاجی کو بہتر بنا سکتے ہیں۔

اگر ہم رسائی کو بہتر بنانا چاہتے ہیں، تو پالیسی ha-promote-on-failure میں نصب کیا جانا چاہئے ہمیشہ. یہ پہلے سے طے شدہ قدر ہے، لہذا آپ صرف پالیسی کی وضاحت نہیں کر سکتے۔ اس صورت میں، ہم بنیادی طور پر غیر مطابقت پذیر آئینے میں ناکامیوں کی اجازت دے رہے ہیں۔ اس سے پیغامات ضائع ہو جائیں گے، لیکن قطار پڑھنے اور لکھنے کے قابل رہے گی۔

چاول۔ 12. قطار A کو پیغامات کھونے کے بغیر بروکر 3 پر واپس لایا جاتا ہے۔ قطار B دس پیغامات کے گم ہونے کے ساتھ بروکر 3 پر واپس آ گئی۔

ہم بھی انسٹال کر سکتے ہیں۔ ha-promote-on-failure معنی میں when-synced. اس صورت میں، آئینے پر واپس جانے کے بجائے، قطار اس وقت تک انتظار کرے گی جب تک کہ بروکر 1 اپنے ڈیٹا کے ساتھ آن لائن موڈ پر واپس نہ آجائے۔ اس کے واپس آنے کے بعد، بغیر کسی ڈیٹا کے نقصان کے مرکزی قطار بروکر 1 پر واپس آ جاتی ہے۔ ڈیٹا کی حفاظت کے لیے دستیابی کی قربانی دی جاتی ہے۔ لیکن یہ ایک پرخطر موڈ ہے جو مکمل ڈیٹا ضائع کرنے کا باعث بھی بن سکتا ہے، جسے ہم جلد ہی دیکھیں گے۔

چاول۔ 13. بروکر 1 کو کھونے کے بعد قطار B دستیاب نہیں ہے۔

آپ پوچھ سکتے ہیں، "کیا یہ بہتر ہے کہ کبھی بھی خودکار مطابقت پذیری کا استعمال نہ کیا جائے؟" جواب یہ ہے کہ مطابقت پذیری ایک بلاکنگ آپریشن ہے۔ مطابقت پذیری کے دوران، مرکزی قطار پڑھنے یا لکھنے کی کوئی کارروائی نہیں کر سکتی!

آئیے ایک مثال دیکھتے ہیں۔ اب ہماری بہت لمبی قطاریں ہیں۔ وہ اتنے سائز میں کیسے بڑھ سکتے ہیں؟ کئی وجوہات کی بناء پر:

• قطاریں فعال طور پر استعمال نہیں کی جاتی ہیں۔
• یہ تیز رفتار قطاریں ہیں، اور اس وقت صارفین سست ہیں۔
• یہ تیز رفتار قطاریں ہیں، ایک خرابی ہے اور صارفین پکڑ رہے ہیں

چاول۔ 14. مختلف مطابقت پذیری کے طریقوں کے ساتھ دو بڑی قطاریں۔

اب بروکر 3 گرتا ہے۔

چاول۔ 15. بروکر 3 گرتا ہے، ہر قطار میں ایک ماسٹر اور آئینہ چھوڑتا ہے۔

بروکر 3 آن لائن واپس آتا ہے اور نئے آئینے بنائے جاتے ہیں۔ مین قطار A موجودہ پیغامات کو نئے آئینے میں نقل کرنا شروع کر دیتی ہے، اور اس وقت کے دوران قطار دستیاب نہیں ہوتی ہے۔ اعداد و شمار کو نقل کرنے میں دو گھنٹے لگتے ہیں، جس کے نتیجے میں اس قطار کے لیے دو گھنٹے کا ڈاؤن ٹائم ہوتا ہے!

تاہم، قطار B پوری مدت میں دستیاب رہتی ہے۔ اس نے رسائی کے لیے کچھ فالتو پن کی قربانی دی۔

چاول۔ 16. مطابقت پذیری کے دوران قطار دستیاب نہیں رہتی ہے۔

دو گھنٹے کے بعد، قطار A بھی دستیاب ہو جاتا ہے اور دوبارہ پڑھنا اور لکھنا قبول کرنا شروع کر سکتا ہے۔

تازہ ترین معلومات کے

مطابقت پذیری کے دوران یہ مسدود کرنے والا رویہ بہت بڑی قطاروں والے کلسٹرز کو اپ ڈیٹ کرنا مشکل بناتا ہے۔ کسی وقت، ماسٹر نوڈ کو دوبارہ شروع کرنے کی ضرورت ہے، جس کا مطلب ہے یا تو آئینے پر سوئچ کرنا یا سرور کو اپ گریڈ کرنے کے دوران قطار کو غیر فعال کرنا۔ اگر ہم منتقلی کا انتخاب کرتے ہیں، تو ہم پیغامات سے محروم ہو جائیں گے اگر آئینے مطابقت پذیر نہ ہوں۔ پہلے سے طے شدہ طور پر، بروکر کی بندش کے دوران، غیر مطابقت پذیر آئینے میں ناکامی نہیں کی جاتی ہے۔ اس کا مطلب یہ ہے کہ جیسے ہی بروکر واپس آتا ہے، ہم کوئی پیغام نہیں کھوتے، صرف نقصان ایک سادہ قطار تھا۔ جب بروکر منقطع ہو جاتا ہے تو رویے کے اصول پالیسی کے ذریعے طے کیے جاتے ہیں۔ ha-promote-on-shutdown. آپ دو اقدار میں سے ایک سیٹ کر سکتے ہیں:

• always= غیر مطابقت پذیر آئینے میں منتقلی فعال ہے۔
• when-synced= صرف مطابقت پذیر آئینے میں منتقلی، بصورت دیگر قطار پڑھنے کے قابل اور ناقابل تحریر ہو جاتی ہے۔ بروکر کے واپس آتے ہی قطار سروس پر واپس آجاتی ہے۔

ایک یا دوسرا راستہ، بڑی قطاروں کے ساتھ آپ کو ڈیٹا کے نقصان اور عدم دستیابی کے درمیان انتخاب کرنا ہوگا۔

جب دستیابی ڈیٹا سیکیورٹی کو بہتر بناتی ہے۔

فیصلہ کرنے سے پہلے غور کرنے کے لیے ایک اور پیچیدگی ہے۔ اگرچہ خودکار مطابقت پذیری فالتو پن کے لیے بہتر ہے، لیکن یہ ڈیٹا کی حفاظت کو کیسے متاثر کرتا ہے؟ یقیناً، بہتر فالتو پن کے ساتھ، RabbitMQ کے موجودہ پیغامات سے محروم ہونے کا امکان کم ہے، لیکن پبلشرز کے نئے پیغامات کا کیا ہوگا؟

یہاں آپ کو درج ذیل پر غور کرنے کی ضرورت ہے:

• کیا پبلشر صرف ایک غلطی واپس کر سکتا ہے اور اپ اسٹریم سروس یا صارف کو بعد میں دوبارہ کوشش کر سکتا ہے؟
• کیا ناشر بعد میں دوبارہ کوشش کرنے کے لیے پیغام کو مقامی طور پر یا ڈیٹا بیس میں محفوظ کر سکتا ہے؟

اگر ناشر صرف پیغام کو رد کر سکتا ہے، تو درحقیقت، رسائی کو بہتر بنانے سے ڈیٹا کی حفاظت بھی بہتر ہوتی ہے۔

اس طرح، توازن تلاش کرنا ضروری ہے، اور حل مخصوص صورت حال پر منحصر ہے.

ha-promote-on-failure=when-sync ہونے کے ساتھ مسائل

خیال ha-promote-on-failure= جب مطابقت پذیر یہ ہے کہ ہم غیر مطابقت پذیر آئینے پر سوئچ کرنے سے روکتے ہیں اور اس طرح ڈیٹا کے نقصان سے بچتے ہیں۔ قطار ناقابل پڑھنے یا لکھنے کے قابل رہتی ہے۔ اس کے بجائے، ہم کریش شدہ بروکر کو اس کے ڈیٹا کے ساتھ بحال کرنے کی کوشش کرتے ہیں تاکہ یہ ڈیٹا کے نقصان کے بغیر ماسٹر کے طور پر دوبارہ کام شروع کر سکے۔

لیکن (اور یہ ایک بڑا ہے لیکن) اگر بروکر نے اپنا ڈیٹا کھو دیا ہے، تو ہمارے پاس ایک بڑا مسئلہ ہے: قطار کھو گئی ہے! تمام ڈیٹا چلا گیا! یہاں تک کہ اگر آپ کے پاس آئینے ہیں جو زیادہ تر مرکزی قطار کے ساتھ پکڑتے ہیں، تو وہ آئینے بھی ضائع کردیئے جاتے ہیں۔

اسی نام کے ساتھ نوڈ کو دوبارہ شامل کرنے کے لیے، ہم کلسٹر کو کہتے ہیں کہ کھوئے ہوئے نوڈ کو بھول جائے (کمانڈ کے ساتھ rabbitmqctl forget_cluster_node) اور اسی میزبان نام کے ساتھ ایک نیا بروکر شروع کریں۔ جب کہ کلسٹر کھوئے ہوئے نوڈ کو یاد رکھتا ہے، یہ پرانی قطار اور غیر مطابقت پذیر آئینے کو یاد رکھتا ہے۔ جب کسی کلسٹر کو یتیم نوڈ کو بھول جانے کے لیے کہا جاتا ہے، تو وہ قطار بھی بھول جاتی ہے۔ اب ہمیں اسے دوبارہ اعلان کرنے کی ضرورت ہے۔ ہم نے تمام ڈیٹا کھو دیا، حالانکہ ہمارے پاس ڈیٹا کے جزوی سیٹ کے ساتھ آئینے تھے۔ یہ بہتر ہو گا کہ غیر مطابقت پذیر آئینے پر سوئچ کریں!

لہذا، دستی مطابقت پذیری (اور مطابقت پذیری میں ناکامی) کے ساتھ مجموعہ میں ha-promote-on-failure=when-syncedمیری رائے میں، کافی خطرناک۔ دستاویزات کا کہنا ہے کہ یہ آپشن ڈیٹا سیکیورٹی کے لیے موجود ہے، لیکن یہ ایک دو دھاری چاقو ہے۔

ماسٹر ری بیلنسنگ

جیسا کہ وعدہ کیا گیا ہے، ہم ایک یا کئی نوڈس پر تمام ماسٹرز کے جمع ہونے کے مسئلے پر واپس آتے ہیں۔ یہ رولنگ کلسٹر اپ ڈیٹ کے نتیجے میں بھی ہو سکتا ہے۔ تین نوڈ کلسٹر میں، تمام ماسٹر قطاریں ایک یا دو نوڈس پر جمع ہوں گی۔

دو وجوہات کی بنا پر ماسٹرز کو دوبارہ متوازن کرنا مشکل ہو سکتا ہے:

• ری بیلنس کرنے کے لیے کوئی اچھے ٹولز نہیں ہیں۔
• قطار کی مطابقت پذیری۔

دوبارہ توازن کے لیے ایک تیسرا فریق ہے۔ پلگ انجس کی سرکاری طور پر حمایت نہیں کی جاتی ہے۔ 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 سے الگ ہوگئے۔

چاول۔ 23. بروکر 3 توقف کرتا ہے، تمام کلائنٹس کو منقطع کرتا ہے، اور کنکشن کی درخواستوں کو مسترد کرتا ہے۔

رابطہ بحال ہونے کے بعد، یہ کلسٹر میں واپس آجاتا ہے۔

آئیے ایک اور مثال دیکھیں جہاں مرکزی قطار بروکر 3 پر ہے۔

چاول۔ 24. بروکر 3 پر مین قطار۔

پھر رابطے کا وہی نقصان ہوتا ہے۔ بروکر 3 توقف کرتا ہے کیونکہ یہ چھوٹی طرف ہے۔ دوسری طرف، نوڈس دیکھتے ہیں کہ بروکر 3 گر گیا ہے، لہذا بروکرز 1 اور 2 سے پرانے آئینہ کو ماسٹر میں ترقی دی جاتی ہے۔

چاول۔ 25. بروکر 2 میں منتقلی اگر بروکر 3 دستیاب نہیں ہے۔

رابطہ بحال ہونے پر، بروکر 3 کلسٹر میں شامل ہو جائے گا۔

چاول۔ 26. کلسٹر معمول کے کام پر واپس آ گیا ہے۔

یہاں سمجھنے کی اہم بات یہ ہے کہ ہمیں مستقل مزاجی ملتی ہے، لیکن ہم دستیابی بھی حاصل کر سکتے ہیں، اگر ہم کامیابی کے ساتھ کلائنٹس کو زیادہ تر سیکشن میں منتقل کر دیں گے۔ زیادہ تر حالات کے لیے، میں ذاتی طور پر Pause Minority موڈ کا انتخاب کروں گا، لیکن یہ واقعی انفرادی کیس پر منحصر ہے۔

دستیابی کو یقینی بنانے کے لیے، یہ یقینی بنانا ضروری ہے کہ کلائنٹ کامیابی کے ساتھ میزبان سے جڑے۔ آئیے اپنے اختیارات کو دیکھیں۔

کسٹمر کنیکٹیویٹی کو یقینی بنانا

ہمارے پاس متعدد اختیارات ہیں کہ کس طرح کلسٹر کے مرکزی حصے یا کنیکٹیویٹی کے نقصان کے بعد کام کرنے والے نوڈس (ایک نوڈ کے ناکام ہونے کے بعد) کی طرف کلائنٹس کو ہدایت کی جائے۔ سب سے پہلے، یاد رکھیں کہ ایک مخصوص قطار ایک مخصوص نوڈ پر ہوسٹ کی جاتی ہے، لیکن روٹنگ اور پالیسیاں تمام نوڈس پر نقل کی جاتی ہیں۔ کلائنٹ کسی بھی نوڈ سے جڑ سکتے ہیں، اور اندرونی روٹنگ انہیں ہدایت دے گی کہ انہیں کہاں جانا ہے۔ لیکن جب ایک نوڈ کو معطل کیا جاتا ہے، تو یہ کنکشن کو مسترد کر دیتا ہے، اس لیے کلائنٹس کو دوسرے نوڈ سے جڑنا چاہیے۔ اگر نوڈ گر جاتا ہے، تو وہ کچھ بھی کر سکتا ہے۔

ہمارے اختیارات:

• کلسٹر تک لوڈ بیلنسر کا استعمال کرتے ہوئے رسائی حاصل کی جاتی ہے جو نوڈس کے ذریعے آسانی سے چکر لگاتا ہے اور کلائنٹ کامیاب ہونے تک دوبارہ رابطہ قائم کرنے کی کوشش کرتے ہیں۔ اگر کوئی نوڈ نیچے ہے یا معطل ہے، تو اس نوڈ سے جڑنے کی کوششیں ناکام ہو جائیں گی، لیکن بعد کی کوششیں دوسرے سرورز پر جائیں گی (راؤنڈ رابن انداز میں)۔ یہ کنیکٹیویٹی کے قلیل مدتی نقصان یا ڈاؤن شدہ سرور کے لیے موزوں ہے جسے فوری طور پر واپس لایا جائے گا۔
• لوڈ بیلنسر کے ذریعے کلسٹر تک رسائی حاصل کریں اور جیسے ہی ان کا پتہ چل جائے فہرست سے معطل/ناکام نوڈس کو ہٹا دیں۔ اگر ہم یہ کام جلدی کرتے ہیں، اور اگر کلائنٹ کنکشن کی دوبارہ کوشش کرنے کے قابل ہو جاتے ہیں، تو ہم مستقل دستیابی حاصل کر لیں گے۔
• ہر کلائنٹ کو تمام نوڈس کی فہرست دیں، اور کلائنٹ تصادفی طور پر ان میں سے کسی ایک کو جوڑتے وقت منتخب کرتا ہے۔ اگر اسے کنیکٹ کرنے کی کوشش کرتے وقت کوئی خرابی موصول ہوتی ہے، تو یہ فہرست میں اگلے نوڈ پر چلا جاتا ہے جب تک کہ یہ جڑ نہ جائے۔
• DNS کا استعمال کرتے ہوئے ناکام/معطل نوڈ سے ٹریفک کو ہٹا دیں۔ یہ ایک چھوٹے ٹی ٹی ایل کا استعمال کرتے ہوئے کیا جاتا ہے۔

نتائج

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