В آخری آرٹیکل ہم نے غلطی کی رواداری اور اعلی دستیابی کے لیے RabbitMQ کلسٹرنگ کو دیکھا۔ اب آئیے اپاچی کافکا کی گہرائی میں کھودتے ہیں۔

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

چاول۔ 1. تین بروکرز میں چار حصے تقسیم کیے گئے ہیں۔

تمام پڑھنے لکھنے کی درخواستیں قائد کے پاس جاتی ہیں۔ پیروکار وقتاً فوقتاً رہنما کو تازہ ترین پیغامات وصول کرنے کی درخواستیں بھیجتے ہیں۔ صارفین کبھی بھی پیروکاروں کی طرف متوجہ نہیں ہوتے؛ مؤخر الذکر صرف فالتو پن اور غلطی کو برداشت کرنے کے لیے موجود ہے۔

تقسیم کی ناکامی۔

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

بروکر 3 نیٹ ورک چھوڑ دیتا ہے، اور بروکر 2 پر سیکشن 2 کے لیے ایک نیا لیڈر منتخب ہوتا ہے۔

چاول۔ 2. بروکر 3 کا انتقال ہو گیا اور بروکر 2 پر اس کے پیروکار کو تقسیم 2 کا نیا لیڈر منتخب کیا گیا

پھر بروکر 1 چھوڑ دیتا ہے اور سیکشن 1 بھی اپنے لیڈر کو کھو دیتا ہے، جس کا کردار بروکر 2 کو جاتا ہے۔

چاول۔ 3. ایک بروکر باقی ہے۔ تمام رہنما صفر فالتو پن کے ساتھ ایک بروکر پر ہیں۔

جب بروکر 1 آن لائن واپس آتا ہے، تو یہ چار پیروکاروں کا اضافہ کرتا ہے، ہر پارٹیشن کو کچھ بے کار فراہم کرتا ہے۔ لیکن تمام لیڈر پھر بھی دلال 2 پر قائم رہے۔

چاول۔ 4. قائدین بروکر پر رہتے ہیں 2

جب بروکر 3 آتا ہے، تو ہم فی پارٹیشن تین نقلوں پر واپس آ جاتے ہیں۔ لیکن تمام رہنما اب بھی بروکر 2 پر ہیں۔

چاول۔ 5. بروکرز 1 اور 3 کی بحالی کے بعد رہنماؤں کی غیر متوازن جگہ کا تعین

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

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

اسے ٹھیک کرنے کے لیے، کافکا دو اختیارات پیش کرتا ہے:

• آپشن auto.leader.rebalance.enable=true کنٹرولر نوڈ کو خود بخود لیڈروں کو ترجیحی نقلوں پر دوبارہ تفویض کرنے کی اجازت دیتا ہے اور اس طرح یکساں تقسیم کو بحال کرتا ہے۔
• ایڈمنسٹریٹر اسکرپٹ چلا سکتا ہے۔ kafka-preferred-replica-election.sh دستی دوبارہ تفویض کے لیے۔

چاول۔ 6. دوبارہ توازن کے بعد نقل

یہ ناکامی کا ایک آسان ورژن تھا، لیکن حقیقت زیادہ پیچیدہ ہے، حالانکہ یہاں کچھ زیادہ پیچیدہ نہیں ہے۔ یہ سب مطابقت پذیر ریپلیکس (ان سنک ریپلیکس، آئی ایس آر) پر آتا ہے۔

مطابقت پذیر نقلیں (ISR)

ایک ISR ایک پارٹیشن کی نقلوں کا ایک مجموعہ ہے جسے "مطابقت پذیر" (مطابقت پذیر) سمجھا جاتا ہے۔ لیڈر ہے، لیکن پیروکار نہیں ہوسکتے۔ ایک پیروکار کو مطابقت پذیر سمجھا جاتا ہے اگر اس نے وقفہ ختم ہونے سے پہلے رہنما کے تمام پیغامات کی صحیح کاپیاں بنا لی ہیں۔ replica.lag.time.max.ms.

ایک پیروکار کو ISR سیٹ سے ہٹا دیا جاتا ہے اگر یہ:

• وقفہ کے لیے انتخاب کرنے کی درخواست نہیں کی۔ replica.lag.time.max.ms (موت سمجھا جاتا ہے)
• وقفہ کے دوران اپ ڈیٹ کرنے کا انتظام نہیں کیا۔ replica.lag.time.max.ms (سست سمجھا جاتا ہے)

پیروکار وقفہ میں نمونے لینے کی درخواستیں کرتے ہیں۔ replica.fetch.wait.max.ms، جو ڈیفالٹ 500ms پر ہے۔

ISR کے مقصد کو واضح طور پر بیان کرنے کے لیے، ہمیں پروڈیوسر سے تصدیقات اور کچھ ناکامی کے منظرناموں کو دیکھنے کی ضرورت ہے۔ پروڈیوسر منتخب کر سکتے ہیں جب بروکر تصدیق بھیجے:

• acks=0، تصدیق نہیں بھیجی گئی ہے۔
• acks=1، رہنما کے اپنے مقامی لاگ پر پیغام لکھنے کے بعد تصدیق بھیجی جاتی ہے۔
• acks=all، تصدیق اس وقت بھیجی جاتی ہے جب ISR میں موجود تمام نقلیں مقامی لاگز پر پیغام لکھتی ہیں۔

کافکا کی اصطلاح میں، اگر ISR نے کوئی پیغام محفوظ کیا ہے، تو یہ "عزم" ہے۔ Acks=all سب سے محفوظ آپشن ہے، لیکن اضافی تاخیر بھی کرتا ہے۔ آئیے ناکامی کی دو مثالوں کو دیکھتے ہیں اور کس طرح مختلف 'acks' اختیارات ISR تصور کے ساتھ تعامل کرتے ہیں۔

Acks=1 اور ISR

اس مثال میں، ہم دیکھیں گے کہ اگر لیڈر تمام پیروکاروں کے ہر پیغام کے محفوظ ہونے کا انتظار نہیں کرتا ہے، تو لیڈر ناکام ہونے کی صورت میں ڈیٹا کا نقصان ممکن ہے۔ غیر مطابقت پذیر پیروکار پر نیویگیٹنگ کو ترتیب کے ذریعے فعال یا غیر فعال کیا جا سکتا ہے۔ unclean.leader.election.enable.

اس مثال میں، مینوفیکچرر کے پاس ویلیو acks=1 ہے۔ سیکشن تینوں بروکرز میں تقسیم کیا جاتا ہے۔ بروکر 3 پیچھے ہے، یہ آٹھ سیکنڈ پہلے لیڈر کے ساتھ ہم آہنگ ہوا اور اب 7456 پیغامات پیچھے ہے۔ بروکر 1 صرف ایک سیکنڈ پیچھے تھا۔ ہمارا پروڈیوسر ایک پیغام بھیجتا ہے اور فوری طور پر ایک آک واپس وصول کرتا ہے، بغیر کسی سست یا مردہ پیروکاروں کے جس کا لیڈر انتظار نہیں کر رہا ہوتا ہے۔

چاول۔ 7. تین نقلوں کے ساتھ ISR

بروکر 2 ناکام ہو جاتا ہے اور پروڈیوسر کو کنکشن کی خرابی موصول ہوتی ہے۔ قیادت بروکر 1 کے پاس جانے کے بعد، ہم 123 پیغامات کھو دیتے ہیں۔ بروکر 1 پر پیروکار ISR کا حصہ تھا، لیکن جب گر گیا تو لیڈر کے ساتھ مکمل طور پر ہم آہنگ نہیں ہوا۔

چاول۔ 8. کریش ہونے پر پیغامات ضائع ہو جاتے ہیں۔

ترتیب میں bootstrap.servers مینوفیکچرر کے پاس کئی بروکرز درج ہیں اور وہ کسی دوسرے بروکر سے پوچھ سکتے ہیں کہ نیا سیکشن لیڈر کون ہے۔ اس کے بعد یہ بروکر 1 سے رابطہ قائم کرتا ہے اور پیغامات بھیجنا جاری رکھتا ہے۔

چاول۔ 9. مختصر وقفے کے بعد پیغامات بھیجنا دوبارہ شروع ہوتا ہے۔

بروکر 3 اور بھی پیچھے ہے۔ یہ بازیافت کی درخواستیں کرتا ہے لیکن مطابقت پذیر نہیں ہوسکتا ہے۔ یہ بروکرز کے درمیان سست نیٹ ورک کنکشن، اسٹوریج ایشو وغیرہ کی وجہ سے ہو سکتا ہے۔ اسے ISR سے ہٹا دیا گیا ہے۔ اب ISR ایک نقل پر مشتمل ہے - لیڈر! مینوفیکچرر پیغامات بھیجنا اور تصدیق حاصل کرنا جاری رکھتا ہے۔

چاول۔ 10. بروکر 3 پر فالوور کو ISR سے ہٹا دیا جاتا ہے۔

بروکر 1 نیچے چلا جاتا ہے اور 3 پیغامات کے نقصان کے ساتھ قائدانہ کردار بروکر 15286 کو جاتا ہے! کارخانہ دار کو کنکشن کی خرابی کا پیغام موصول ہوتا ہے۔ ISR سے باہر کسی لیڈر کی منتقلی صرف ترتیب کی وجہ سے ممکن تھی۔ unclean.leader.election.enable=true. اگر اس میں انسٹال ہے۔ جھوٹی، پھر منتقلی واقع نہیں ہوگی اور تمام پڑھنے اور لکھنے کی درخواستوں کو مسترد کردیا جائے گا۔ اس صورت میں، ہم بروکر 1 کے نقل میں اپنے برقرار ڈیٹا کے ساتھ واپس آنے کا انتظار کرتے ہیں، جو دوبارہ قیادت سنبھال لے گا۔

چاول۔ 11. بروکر 1 گرتا ہے۔ جب کوئی ناکامی ہوتی ہے، تو بڑی تعداد میں پیغامات ضائع ہو جاتے ہیں۔

پروڈیوسر آخری بروکر کے ساتھ تعلق قائم کرتا ہے اور دیکھتا ہے کہ اب وہ سیکشن کا لیڈر ہے۔ وہ بروکر 3 کو پیغامات بھیجنا شروع کر دیتا ہے۔

چاول۔ 12. ایک مختصر وقفے کے بعد، پیغامات دوبارہ سیکشن 0 پر بھیجے جاتے ہیں۔

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

Acks=all اور ISR

آئیے اس منظر نامے کو دوبارہ دہراتے ہیں، لیکن ساتھ acks = تمام. بروکر 3 میں چار سیکنڈ کی اوسط تاخیر ہوتی ہے۔ کارخانہ دار اس کے ساتھ ایک پیغام بھیجتا ہے۔ acks = تمام، اور اب فوری جواب موصول نہیں ہوتا ہے۔ رہنما اس پیغام کا انتظار کر رہا ہے کہ وہ ISR میں موجود تمام نقلوں کے ذریعے محفوظ ہو جائے۔

چاول۔ 13. تین نقلوں کے ساتھ ISR۔ ایک سست ہے، جس کے نتیجے میں ریکارڈنگ میں تاخیر ہوتی ہے۔

چار سیکنڈ کی اضافی تاخیر کے بعد، بروکر 2 ایک AC بھیجتا ہے۔ تمام نقلیں اب مکمل طور پر اپ ڈیٹ ہو چکی ہیں۔

چاول۔ 14. تمام نقلیں پیغامات کو محفوظ کرتی ہیں اور ack بھیجتی ہیں۔

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

چاول۔ 15. بروکر 3 پر موجود نقل کو ISR سے ہٹا دیا گیا ہے۔

پھر بروکر 2 گر جاتا ہے اور لیڈر شپ پیغامات کے نقصان کے بغیر بروکر 1 کے پاس جاتی ہے۔

چاول۔ 16. بروکر 2 گرتا ہے۔

مینوفیکچرر ایک نیا لیڈر ڈھونڈتا ہے اور اسے پیغامات بھیجنا شروع کر دیتا ہے۔ تاخیر مزید کم ہو گئی ہے کیونکہ ISR اب ایک نقل پر مشتمل ہے! اس لیے آپشن acks = تمام فالتو پن کا اضافہ نہیں کرتا۔

چاول۔ 17. بروکر 1 پر نقل پیغامات کو کھونے کے بغیر آگے بڑھتا ہے۔

پھر بروکر 1 کریش ہو جاتا ہے اور برتری 3 پیغامات کے نقصان کے ساتھ بروکر 14238 کے پاس جاتی ہے!

چاول۔ 18. بروکر 1 کا انتقال ہو جاتا ہے اور ناپاک ترتیب کے ساتھ قیادت کی منتقلی کے نتیجے میں ڈیٹا کا وسیع نقصان ہوتا ہے۔

ہم آپشن انسٹال نہیں کر سکے۔ unclean.leader.election.enable معنی میں سچ. پہلے سے طے شدہ طور پر یہ برابر ہے۔ جھوٹی. ترتیبات acks = تمام с unclean.leader.election.enable=true کچھ اضافی ڈیٹا سیکیورٹی کے ساتھ رسائی فراہم کرتا ہے۔ لیکن جیسا کہ آپ دیکھ سکتے ہیں، ہم اب بھی پیغامات کو کھو سکتے ہیں۔

لیکن اگر ہم ڈیٹا کی حفاظت کو بڑھانا چاہتے ہیں تو کیا ہوگا؟ آپ لگا سکتے ہیں۔ unclean.leader.election.enable = غلط، لیکن یہ ضروری نہیں کہ ہمیں ڈیٹا کے نقصان سے محفوظ رکھے۔ اگر لیڈر سختی سے گر گیا اور اس کے ساتھ ڈیٹا لے گیا، تب بھی پیغامات ضائع ہو جائیں گے، اور اس وقت تک دستیابی ختم ہو جائے گی جب تک کہ منتظم صورتحال کو بحال نہ کرے۔

یہ یقینی بنانا بہتر ہے کہ تمام پیغامات بے کار ہیں، اور بصورت دیگر ریکارڈنگ کو ضائع کر دیں۔ پھر، کم از کم بروکر کے نقطہ نظر سے، ڈیٹا کا نقصان صرف دو یا زیادہ بیک وقت ناکامیوں کی صورت میں ممکن ہے۔

Acks=all، min.insync.replicas اور ISR

موضوع کی ترتیب کے ساتھ min.insync.replicas ہم ڈیٹا سیکیورٹی کی سطح کو بڑھا رہے ہیں۔ آئیے پچھلے منظر نامے کے آخری حصے کو دوبارہ دیکھتے ہیں، لیکن اس بار min.insync.replicas=2.

لہذا بروکر 2 میں ایک ریپلیکا لیڈر ہے اور بروکر 3 پر پیروکار کو ISR سے ہٹا دیا گیا ہے۔

چاول۔ 19. دو نقلوں سے آئی ایس آر

بروکر 2 گر جاتا ہے اور قیادت پیغامات کے نقصان کے بغیر بروکر 1 کے پاس جاتی ہے۔ لیکن اب ISR صرف ایک نقل پر مشتمل ہے۔ یہ ریکارڈ حاصل کرنے کے لیے کم از کم تعداد کو پورا نہیں کرتا، اور اس لیے بروکر لکھنے کی کوشش کا جواب غلطی کے ساتھ دیتا ہے۔ NotEnoughReplicas.

چاول۔ 20. ISRs کی تعداد min.insync.replicas میں بیان کردہ سے ایک کم ہے

یہ ترتیب مستقل مزاجی کے لیے دستیابی کی قربانی دیتی ہے۔ کسی پیغام کو تسلیم کرنے سے پہلے، ہم اس بات کو یقینی بناتے ہیں کہ اسے کم از کم دو نقلوں پر لکھا گیا ہو۔ یہ کارخانہ دار کو بہت زیادہ اعتماد دیتا ہے۔ یہاں، پیغام کا نقصان صرف اس صورت میں ممکن ہے جب ایک مختصر وقفہ میں دو نقلیں بیک وقت ناکام ہو جائیں جب تک کہ پیغام کو کسی اضافی پیروکار کو نقل نہ کیا جائے، جس کا امکان نہیں ہے۔ لیکن اگر آپ انتہائی بے وقوف ہیں، تو آپ نقل کے عنصر کو 5، اور پر سیٹ کر سکتے ہیں۔ min.insync.replicas بذریعہ 3۔ یہاں ریکارڈ کھونے کے لیے تین بروکرز کو بیک وقت گرنا پڑتا ہے! بلاشبہ، آپ اضافی تاخیر میں اس قابل اعتماد کی ادائیگی کرتے ہیں۔

جب ڈیٹا کی حفاظت کے لیے رسائی ضروری ہو۔

جیسا کہ RabbitMQ کے ساتھ معاملہکبھی کبھی ڈیٹا کی حفاظت کے لیے رسائی ضروری ہوتی ہے۔ یہاں آپ کو اس کے بارے میں سوچنے کی ضرورت ہے:

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

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

ISR کے معنی

ISR سویٹ آپ کو ڈیٹا سیکیورٹی اور لیٹنسی کے درمیان بہترین توازن کا انتخاب کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، زیادہ تر نقلوں کی ناکامی کی صورت میں دستیابی کو یقینی بنائیں، تاخیر کے لحاظ سے مردہ یا سست نقلوں کے اثرات کو کم سے کم کریں۔

ہم معنی خود چنتے ہیں۔ replica.lag.time.max.ms آپ کی ضروریات کے مطابق. بنیادی طور پر، اس پیرامیٹر کا مطلب ہے کہ ہم کتنی تاخیر قبول کرنے کے لیے تیار ہیں۔ acks = تمام. پہلے سے طے شدہ قدر دس ​​سیکنڈ ہے۔ اگر یہ آپ کے لیے بہت طویل ہے، تو آپ اسے کم کر سکتے ہیں۔ پھر ISR میں تبدیلیوں کی تعدد بڑھ جائے گی، کیونکہ پیروکاروں کو ہٹا دیا جائے گا اور زیادہ کثرت سے شامل کیا جائے گا۔

RabbitMQ صرف آئینے کا ایک مجموعہ ہے جسے نقل کرنے کی ضرورت ہے۔ سست آئینے اضافی تاخیر کو متعارف کراتے ہیں، اور مردہ آئینے اس وقت تک انتظار کر سکتے ہیں جب تک کہ پیکٹ جواب دینے کے لیے ہر نوڈ (نیٹ ٹک) کی دستیابی کو چیک کریں۔ ISR ان تاخیری مسائل سے بچنے کا ایک دلچسپ طریقہ ہے۔ لیکن ہمیں بے کار ہونے کا خطرہ ہے کیونکہ ISR صرف لیڈر تک سکڑ سکتا ہے۔ اس خطرے سے بچنے کے لیے، ترتیب استعمال کریں۔ min.insync.replicas.

کلائنٹ کنکشن کی گارنٹی

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

RabbitMQ میں، کلائنٹ کسی بھی نوڈ سے جڑ سکتے ہیں، اور اندرونی روٹنگ درخواست بھیجتی ہے جہاں اسے جانا ہے۔ اس کا مطلب ہے کہ آپ RabbitMQ کے سامنے لوڈ بیلنسر انسٹال کر سکتے ہیں۔ کافکا کو کلائنٹس سے اس نوڈ سے جڑنے کی ضرورت ہوتی ہے جو متعلقہ پارٹیشن لیڈر کی میزبانی کرتا ہے۔ ایسی صورتحال میں آپ لوڈ بیلنسر انسٹال نہیں کر سکتے۔ فہرست bootstrap.servers یہ اہم ہے کہ گاہک ناکامی کے بعد درست نوڈس تک رسائی حاصل کر سکتے ہیں اور تلاش کر سکتے ہیں۔

کافکا متفقہ فن تعمیر

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

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

زوکیپر کلسٹر کی حالت کو محفوظ کرتا ہے:

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

کنٹرولر نوڈ کافکا بروکرز میں سے ایک ہے جو ریپلیکا لیڈروں کو منتخب کرنے کے لیے ذمہ دار ہے۔ زوکیپر کنٹرولر کو کلسٹر ممبرشپ اور موضوع کی تبدیلیوں کے بارے میں اطلاعات بھیجتا ہے، اور کنٹرولر کو ان تبدیلیوں پر عمل کرنا چاہیے۔

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

ہر سیکشن کنٹرولر کے لیے:

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

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

ہر لیڈر ISRs کو بھرتی کرنے کا ذمہ دار ہے۔ ترتیبات replica.lag.time.max.ms اس بات کا تعین کرتا ہے کہ وہاں کون داخل ہوگا۔ جب آئی ایس آر تبدیل ہوتا ہے، لیڈر زوکیپر کو نئی معلومات منتقل کرتا ہے۔

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

چاول۔ 21. کافکا اتفاق رائے

نقل کا پروٹوکول

نقل کی تفصیلات کو سمجھنے سے آپ کو ڈیٹا کے نقصان کے ممکنہ منظرناموں کو بہتر طور پر سمجھنے میں مدد ملتی ہے۔

نمونے لینے کے سوالات، لاگ اینڈ آفسیٹ (LEO) اور ہائی واٹر مارک (HW)

ہم نے غور کیا کہ پیروکار وقفے وقفے سے لیڈر کو بازیافت کی درخواستیں بھیجتے ہیں۔ پہلے سے طے شدہ وقفہ 500ms ہے۔ یہ RabbitMQ سے اس لحاظ سے مختلف ہے کہ RabbitMQ میں نقل قطار کے آئینے سے نہیں بلکہ ماسٹر کے ذریعے شروع کی جاتی ہے۔ ماسٹر تبدیلیوں کو آئینے میں دھکیلتا ہے۔

لیڈر اور تمام پیروکار لاگ اینڈ آفسیٹ (LEO) اور ہائی واٹر (HW) لیبل کو محفوظ کرتے ہیں۔ LEO نشان مقامی نقل میں آخری پیغام کے آفسیٹ کو اسٹور کرتا ہے، اور HW آخری کمٹ کا آفسیٹ رکھتا ہے۔ یاد رکھیں کہ کمٹ اسٹیٹس کے لیے، پیغام کو تمام ISR نقلوں میں برقرار رہنا چاہیے۔ اس کا مطلب ہے کہ LEO عام طور پر HW سے تھوڑا آگے ہوتا ہے۔

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

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

لیڈر کی ناکامی۔

جب کوئی لیڈر گرتا ہے، تو زوکیپر کنٹرولر کو مطلع کرتا ہے، اور یہ ایک نئے لیڈر کی نقل کا انتخاب کرتا ہے۔ نیا لیڈر اپنے LEO کے مطابق ایک نیا HW نشان سیٹ کرتا ہے۔ اس کے بعد پیروکار نئے لیڈر کے بارے میں معلومات حاصل کرتے ہیں۔ کافکا کے ورژن پر منحصر ہے، پیروکار دو میں سے ایک منظرنامے کا انتخاب کرے گا:

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

پیروکار کو درج ذیل وجوہات کی بنا پر لاگ کو تراشنا پڑ سکتا ہے۔

• جب کوئی لیڈر ناکام ہوجاتا ہے، تو زوکیپر کے ساتھ رجسٹرڈ ISR سیٹ میں پہلا پیروکار الیکشن جیتتا ہے اور لیڈر بن جاتا ہے۔ ISR پر تمام پیروکاروں کو، اگرچہ "مطابقت پذیر" سمجھا جاتا ہے، ہو سکتا ہے کہ سابق رہنما کے تمام پیغامات کی کاپیاں موصول نہ ہوں۔ یہ مکمل طور پر ممکن ہے کہ نمایاں پیروکار کے پاس تازہ ترین کاپی نہ ہو۔ کافکا اس بات کو یقینی بناتا ہے کہ نقل کے درمیان کوئی فرق نہیں ہے۔ اس طرح، تضادات سے بچنے کے لیے، ہر پیروکار کو اپنے انتخاب کے وقت نئے لیڈر کی HW قدر کے مطابق لاگ ان کو چھوٹا کرنا چاہیے۔ یہ ترتیب دینے کی ایک اور وجہ ہے۔ acks = تمام مستقل مزاجی کے لیے بہت ضروری ہے۔
• پیغامات وقفے وقفے سے ڈسک پر لکھے جاتے ہیں۔ اگر تمام کلسٹر نوڈس ایک ہی وقت میں ناکام ہوجاتے ہیں، تو مختلف آفسیٹس کے ساتھ نقلیں ڈسکوں پر محفوظ کی جائیں گی۔ یہ ممکن ہے کہ جب بروکرز آن لائن واپس آجائیں تو منتخب ہونے والا نیا لیڈر اپنے پیروکاروں کے پیچھے ہو گا کیونکہ اسے دوسروں سے پہلے ڈسک میں محفوظ کیا گیا تھا۔

کلسٹر کے ساتھ دوبارہ اتحاد

کلسٹر میں دوبارہ شامل ہونے پر، نقلیں وہی کرتی ہیں جیسا کہ جب کوئی لیڈر ناکام ہو جاتا ہے: وہ لیڈر کی نقل کو چیک کرتے ہیں اور اپنے لاگ کو اس کے HW (انتخابات کے وقت) پر تراشتے ہیں۔ اس کے مقابلے میں، RabbitMQ دوبارہ متحد ہونے والے نوڈس کو بالکل نئے تصور کرتا ہے۔ دونوں صورتوں میں، بروکر کسی بھی موجودہ ریاست کو مسترد کر دیتا ہے۔ اگر خودکار مطابقت پذیری کا استعمال کیا جاتا ہے، تو ماسٹر کو "پوری دنیا کو انتظار کرنے دو" کے طریقہ کار میں بالکل موجودہ مواد کو نئے آئینے میں نقل کرنا چاہیے۔ ماسٹر اس آپریشن کے دوران پڑھنے یا لکھنے کی کوئی کارروائی قبول نہیں کرتا ہے۔ یہ نقطہ نظر بڑی قطاروں میں مسائل پیدا کرتا ہے۔

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

نئے یا دوبارہ شامل ہونے والے پیروکار ISR سے باہر شروع ہوتے ہیں اور کمٹ میں حصہ نہیں لیتے ہیں۔ وہ صرف گروپ کے ساتھ مل کر کام کرتے ہیں، جتنی جلدی ہو سکے پیغامات وصول کرتے ہیں جب تک کہ وہ لیڈر کو پکڑ کر ISR میں داخل نہ ہو جائیں۔ کوئی لاک ان نہیں ہے اور آپ کے تمام ڈیٹا کو پھینکنے کی ضرورت نہیں ہے۔

رابطے کا نقصان

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

ذیل میں رابطے کی ناکامی کے کئی منظرنامے ہیں:

• منظر نامہ 1: پیروکار رہنما کو نہیں دیکھتا، لیکن پھر بھی چڑیا گھر کو دیکھتا ہے۔
• منظر نامہ 2: رہنما کوئی پیروکار نہیں دیکھتا، لیکن پھر بھی زوکیپر کو دیکھتا ہے۔
• منظر نامہ 3: پیروکار رہنما کو دیکھتا ہے، لیکن زوکیپر کو نہیں دیکھتا۔
• منظر نامہ 4: رہنما پیروکاروں کو دیکھتا ہے، لیکن زوکیپر کو نہیں دیکھتا۔
• منظر نامہ 5: پیروکار دوسرے کافکا نوڈس اور زوکیپر دونوں سے بالکل الگ ہے۔
• منظر نامہ 6: لیڈر دوسرے کافکا نوڈس اور زوکیپر دونوں سے بالکل الگ ہے۔
• منظر نامہ 7: کافکا کنٹرولر نوڈ دوسرے کافکا نوڈ کو نہیں دیکھ سکتا۔
• منظر نامہ 8: کافکا کنٹرولر زوکیپر کو نہیں دیکھ رہا ہے۔

ہر منظر نامے کا اپنا طرز عمل ہوتا ہے۔

منظر نامہ 1: پیروکار لیڈر کو نہیں دیکھتا، لیکن پھر بھی زوکیپر کو دیکھتا ہے۔

چاول۔ 22. منظر نامہ 1: تین نقلوں کا ISR

رابطے کی ناکامی بروکر 3 کو بروکرز 1 اور 2 سے الگ کرتی ہے، لیکن زوکیپر سے نہیں۔ بروکر 3 اب بازیافت کی درخواستیں نہیں بھیج سکتا ہے۔ وقت گزرنے کے بعد replica.lag.time.max.ms اسے ISR سے ہٹا دیا جاتا ہے اور پیغام کے کمٹ میں حصہ نہیں لیتا ہے۔ ایک بار کنیکٹیویٹی بحال ہو جانے کے بعد، یہ درخواستیں بازیافت کرنا دوبارہ شروع کر دے گا اور لیڈر سے ملنے پر ISR میں شامل ہو جائے گا۔ زوکیپر پنگ وصول کرتا رہے گا اور یہ فرض کرے گا کہ بروکر زندہ اور ٹھیک ہے۔

چاول۔ 23. منظر نامہ 1: بروکر کو ISR سے ہٹا دیا جاتا ہے اگر replica.lag.time.max.ms وقفہ کے اندر اس سے بازیافت کی کوئی درخواست موصول نہیں ہوتی ہے۔

RabbitMQ کی طرح کوئی سپلٹ برین یا نوڈ سسپنشن نہیں ہے۔ اس کے بجائے، فالتو پن کم ہو جاتا ہے۔

منظر نامہ 2: لیڈر کو کوئی پیروکار نظر نہیں آتا، لیکن پھر بھی وہ زوکیپر کو دیکھتا ہے۔

چاول۔ 24. منظر نامہ 2. لیڈر اور دو پیروکار

نیٹ ورک کنیکٹیویٹی میں خرابی لیڈر کو پیروکاروں سے الگ کرتی ہے، لیکن بروکر پھر بھی زوکیپر کو دیکھ سکتا ہے۔ جیسا کہ پہلے منظر نامے میں، ISR سکڑتا ہے، لیکن اس بار صرف لیڈر کے لیے کیونکہ تمام پیروکار بازیافت کی درخواستیں بھیجنا بند کر دیتے ہیں۔ ایک بار پھر، کوئی منطقی تقسیم نہیں ہے. اس کے بجائے، کنیکٹیویٹی بحال ہونے تک نئے پیغامات کی فالتو پن کا نقصان ہے۔ زوکیپر کو پنگ ملنا جاری ہے اور اسے یقین ہے کہ بروکر زندہ اور ٹھیک ہے۔

چاول۔ 25. منظر نامہ 2. ISR صرف لیڈر تک سکڑ گیا ہے۔

منظر نامہ 3۔ پیروکار رہنما کو دیکھتا ہے، لیکن زوکیپر کو نہیں دیکھتا

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

چاول۔ 26. منظر نامہ 3: پیروکار رہنما کو بازیافت کی درخواستیں بھیجتا رہتا ہے۔

منظر نامہ 4۔ لیڈر پیروکاروں کو دیکھتا ہے، لیکن زوکیپر کو نہیں دیکھتا

چاول۔ 27. منظر نامہ 4. لیڈر اور دو پیروکار

لیڈر زوکیپر سے الگ ہوتا ہے، لیکن پیروکاروں کے ساتھ دلالوں سے نہیں۔

چاول۔ 28. منظر نامہ 4: رہنما زوکیپر سے الگ تھلگ

کچھ وقت کے بعد، زوکیپر بروکر کی ناکامی کو رجسٹر کرے گا اور کنٹرولر کو اس کے بارے میں مطلع کرے گا۔ وہ اپنے پیروکاروں میں سے ایک نئے رہنما کا انتخاب کرے گا۔ تاہم اصل لیڈر یہی سوچتا رہے گا کہ یہ لیڈر ہے اور اس سے اندراجات قبول کرتا رہے گا۔ acks = 1. پیروکار اب اسے بازیافت کی درخواستیں نہیں بھیج رہے ہیں، لہذا وہ انہیں مردہ سمجھے گا اور ISR کو خود تک سکڑنے کی کوشش کرے گا۔ لیکن چونکہ اس کا زوکیپر سے کوئی تعلق نہیں ہے، اس لیے یہ ایسا نہیں کر سکے گا، اور اس وقت مزید اندراجات کو قبول کرنے سے انکار کر دے گا۔

Сообщения acks = تمام ایک اعتراف موصول نہیں ہوگا کیونکہ ISR سب سے پہلے تمام نقلوں کو آن کرتا ہے، اور پیغامات ان تک نہیں پہنچتے ہیں۔ جب اصل لیڈر انہیں ISR سے ہٹانے کی کوشش کرے گا، تو وہ ایسا کرنے سے قاصر ہو گا اور کسی بھی پیغام کو قبول کرنا بالکل بند کر دے گا۔

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

چاول۔ 29. منظر نامہ 4. نیٹ ورک بحال ہونے کے بعد بروکر 1 پر لیڈر پیروکار بن جاتا ہے۔

منظر نامہ 5: پیروکار دوسرے کافکا نوڈس اور زوکیپر دونوں سے بالکل الگ ہے۔

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

چاول۔ 30. منظر نامہ 5: الگ تھلگ پیروکار کو ISR سے ہٹا دیا گیا ہے۔

منظر نامہ 6: لیڈر دوسرے کافکا نوڈس اور زوکیپر دونوں سے بالکل الگ ہے۔

چاول۔ 31. منظر نامہ 6. لیڈر اور دو پیروکار

لیڈر اپنے پیروکاروں، کنٹرولر اور زوکیپر سے بالکل الگ تھلگ ہے۔ ایک مختصر مدت کے لیے یہ اندراجات کو قبول کرتا رہے گا۔ acks = 1.

چاول۔ 32. منظر نامہ 6: لیڈر کو دیگر کافکا اور زوکیپر نوڈس سے الگ کرنا

میعاد ختم ہونے کے بعد درخواستیں موصول نہیں ہوئیں replica.lag.time.max.ms، یہ ISR کو اپنے تک سکڑنے کی کوشش کرے گا، لیکن ایسا نہیں کر سکے گا کیونکہ Zookeeper کے ساتھ کوئی رابطہ نہیں ہے، پھر یہ تحریریں قبول کرنا بند کر دے گا۔

دریں اثنا، زوکیپر الگ تھلگ بروکر کو مردہ کے طور پر نشان زد کرے گا اور کنٹرولر ایک نیا لیڈر منتخب کرے گا۔

چاول۔ 33. منظر نامہ 6. دو رہنما

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

چاول۔ 34. منظر نامہ 6: مینوفیکچررز نئے لیڈر کی طرف جاتے ہیں۔

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

چاول۔ 35. منظر نامہ 6: نیٹ ورک کنیکٹیویٹی بحال ہونے کے بعد اصل لیڈر پیروکار بن جاتا ہے۔

اس صورت حال میں، منطقی علیحدگی مختصر مدت کے لیے ہو سکتی ہے، لیکن صرف اس صورت میں acks = 1 и min.insync.replicas بھی 1. منطقی علیحدگی یا تو نیٹ ورک بحال ہونے کے بعد خود بخود ختم ہو جاتی ہے، جب اصل لیڈر کو معلوم ہوتا ہے کہ وہ لیڈر نہیں رہا، یا جب تمام کلائنٹس کو یہ احساس ہو کہ لیڈر بدل گیا ہے اور نئے لیڈر کو لکھنا شروع کر دیتے ہیں - جو بھی پہلے ہوتا ہے۔ کسی بھی صورت میں، کچھ پیغامات کھو جائیں گے، لیکن صرف کے ساتھ acks = 1.

اس منظر نامے کی ایک اور قسم ہے جہاں، نیٹ ورک کی تقسیم سے عین پہلے، پیروکار پیچھے پڑ گئے اور لیڈر نے ISR کو صرف اپنے تک محدود کر لیا۔ اس کے بعد رابطہ منقطع ہونے کی وجہ سے یہ الگ تھلگ ہو جاتا ہے۔ ایک نیا لیڈر منتخب کیا جاتا ہے، لیکن اصل لیڈر اندراجات کو قبول کرتا رہتا ہے، یہاں تک کہ acks = تمامکیونکہ اس کے علاوہ ISR میں کوئی نہیں ہے۔ نیٹ ورک بحال ہونے کے بعد یہ ریکارڈز ضائع ہو جائیں گے۔ اس اختیار سے بچنے کا واحد طریقہ ہے۔ min.insync.replicas = 2.

منظر نامہ 7: کافکا کنٹرولر نوڈ ایک اور کافکا نوڈ نہیں دیکھ سکتا

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

منظر نامہ 8: کافکا کنٹرولر زوکیپر کو نہیں دیکھ رہا ہے۔

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

منظرناموں سے اخذ کردہ نتائج

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

اگر رہنما رابطہ ختم ہونے کی وجہ سے زوکیپر سے الگ ہو جاتا ہے، تو اس کے نتیجے میں پیغامات ختم ہو سکتے ہیں۔ acks = 1. زوکیپر کے ساتھ مواصلات کی کمی دونوں رہنماؤں کے ساتھ ایک مختصر منطقی تقسیم کا سبب بنتی ہے۔ یہ مسئلہ پیرامیٹر کی طرف سے حل کیا جاتا ہے acks = تمام.

پیرامیٹر min.insync.replicas دو یا دو سے زیادہ نقلیں اضافی یقین دہانی فراہم کرتی ہیں کہ اس طرح کے قلیل مدتی منظرناموں کے نتیجے میں گمشدہ پیغامات نہیں ہوں گے جیسا کہ منظرنامہ 6 میں ہے۔

گمشدہ پیغامات کا خلاصہ

آئیے ان تمام طریقوں کی فہرست بنائیں جن سے آپ کافکا میں ڈیٹا کھو سکتے ہیں:

• کسی بھی رہنما کی ناکامی اگر پیغامات کے استعمال کی تصدیق کی گئی تھی۔ acks = 1
• قیادت کی کوئی بھی ناپاک منتقلی، یعنی ISR سے باہر کے پیروکار تک، یہاں تک کہ اس کے ساتھ acks = تمام
• اگر پیغامات کے استعمال کی تصدیق ہو جائے تو رہنما کو زوکیپر سے الگ کرنا acks = 1
• اس لیڈر کی مکمل تنہائی جس نے پہلے ہی ISR گروپ کو اپنے تک محدود کر لیا ہے۔ تمام پیغامات بھی ضائع ہو جائیں گے۔ acks = تمام. یہ صرف اس صورت میں درست ہے۔ min.insync.replicas=1.
• تمام پارٹیشن نوڈس کی بیک وقت ناکامی۔ چونکہ پیغامات کو میموری سے تسلیم کیا جاتا ہے، کچھ ابھی تک ڈسک پر نہیں لکھے جا سکتے ہیں۔ سرورز کو ریبوٹ کرنے کے بعد، کچھ پیغامات غائب ہو سکتے ہیں۔

ناپاک قیادت کی تبدیلیوں کو یا تو ان پر پابندی لگا کر یا کم از کم دو بے کاروں کو یقینی بنا کر بچا جا سکتا ہے۔ سب سے زیادہ پائیدار ترتیب ایک مجموعہ ہے acks = تمام и min.insync.replicas 1 سے زیادہ

RabbitMQ اور Kafka کی وشوسنییتا کا براہ راست موازنہ

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

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

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

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

کافکا کی شرط یہ ہے کہ اگر ایک پیغام کو ایک سے زیادہ نوڈس میں ذخیرہ کیا جاتا ہے، تو وہ میموری سے ٹکراتے ہی پیغامات کو تسلیم کر سکتا ہے۔ اس کی وجہ سے، کسی بھی قسم کے پیغامات (یہاں تک کہ acks = تمام, min.insync.replicas=2) بیک وقت ناکامی کی صورت میں۔

مجموعی طور پر، کافکا سافٹ ویئر کی بہتر کارکردگی کی نمائش کرتا ہے اور اسے کلسٹرز کے لیے زمین سے ڈیزائن کیا گیا ہے۔ اگر قابل اعتمادی کے لیے ضروری ہو تو پیروکاروں کی تعداد 11 تک بڑھائی جا سکتی ہے۔ نقل کا عنصر 5 اور مطابقت پذیری میں نقل کی کم از کم تعداد min.insync.replicas=3 پیغام کے نقصان کو ایک بہت ہی نایاب واقعہ بنا دے گا۔ اگر آپ کا بنیادی ڈھانچہ نقل کے اس تناسب اور فالتو پن کی سطح کو سپورٹ کر سکتا ہے، تو آپ اس اختیار کو منتخب کر سکتے ہیں۔

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

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

آخر میں، RabbitMQ اور Kafka دونوں کے جھرمٹ اور نقل کے طریقہ کار میں بہت سے کیڑے کے بارے میں مت بھولنا۔ وقت گزرنے کے ساتھ، نظام زیادہ پختہ اور مستحکم ہو گئے ہیں، لیکن کوئی پیغام کبھی بھی نقصان سے 100% محفوظ نہیں رہے گا! اس کے علاوہ، ڈیٹا سینٹرز میں بڑے پیمانے پر حادثات ہوتے ہیں!

اگر میں نے کچھ یاد کیا ہے، غلطی کی ہے، یا آپ کسی بھی نکات سے متفق نہیں ہیں، تو بلا جھجھک تبصرہ لکھیں یا مجھ سے رابطہ کریں۔

مجھ سے اکثر پوچھا جاتا ہے: "کس چیز کا انتخاب کرنا ہے، کافکا یا RabbitMQ؟"، "کون سا پلیٹ فارم بہتر ہے؟"۔ سچ یہ ہے کہ یہ واقعی آپ کی صورتحال، موجودہ تجربے وغیرہ پر منحصر ہے۔ میں اپنی رائے دینے میں ہچکچاہٹ محسوس کرتا ہوں کیونکہ استعمال کے تمام معاملات اور ممکنہ حدود کے لیے ایک پلیٹ فارم کی سفارش کرنا بہت زیادہ آسان ہوگا۔ میں نے مضامین کا یہ سلسلہ اس لیے لکھا ہے تاکہ آپ اپنی رائے قائم کر سکیں۔

میں یہ کہنا چاہتا ہوں کہ دونوں نظام اس علاقے میں رہنما ہیں۔ میں تھوڑا متعصب ہو سکتا ہوں کیونکہ پراجیکٹس کے ساتھ اپنے تجربے سے میں ضمانت شدہ پیغام کی ترتیب اور وشوسنییتا جیسی چیزوں کو اہمیت دیتا ہوں۔

میں دوسری ٹکنالوجیوں کو دیکھتا ہوں جن میں اس قابل اعتماد اور ضمانت شدہ ترتیب کی کمی ہے، پھر میں RabbitMQ اور Kafka کو دیکھتا ہوں اور ان دونوں نظاموں کی ناقابل یقین قدر کا احساس کرتا ہوں۔

ماخذ: www.habr.com