پيغام بروکرز کي سمجهڻ. ActiveMQ ۽ Kafka سان ميسيجنگ جي ميڪنڪس کي سکڻ. باب 3. ڪافڪا

هڪ ننڍڙي ڪتاب جي ترجمي جو تسلسل:
پيغام بروکرز کي سمجهڻ
ليکڪ: Jakub Korab، پبلشر: O'Reilly Media, Inc.، اشاعت جي تاريخ: جون 2017، ISBN: 9781492049296.

اڳيون ترجمو ڪيل حصو: پيغام بروکرز کي سمجهڻ. ActiveMQ ۽ Kafka سان ميسيجنگ جي ميڪنڪس کي سکڻ. باب 1 تعارف

باب 3

ڪوفي

ڪافڪا ڊولپ ڪيو ويو LinkedIn پاران روايتي ميسيج بروڪرز جي ڪجھ حدن کي حاصل ڪرڻ لاءِ ۽ مختلف نقطي کان پوائنٽ رابطي لاءِ گھڻا ميسيج بروڪرز قائم ڪرڻ کان پاسو ڪرڻ لاءِ، جيڪو ھن ڪتاب ۾ صفحي 28 تي ”اسڪيلنگ اپ اينڊ آئوٽ“ ھيٺ ڏنل آھي. ڪيس استعمال ڪريو LinkedIn وڏي پئماني تي ڊيٽا جي تمام وڏي مقدار جي هڪ طرفي انضمام تي انحصار ڪيو آهي، جهڙوڪ پيج ڪلڪس ۽ لاگ لاگز، جڏهن ته اڃا تائين ان ڊيٽا کي ڪيترن ئي سسٽم ذريعي استعمال ڪرڻ جي اجازت ڏئي ٿو پروڊڪٽرن يا ٻين صارفين جي پيداوار کي متاثر ڪرڻ کان سواء. حقيقت ۾، ڪافڪا موجود هجڻ جو سبب اهو آهي ته پيغام رسائيندڙ فن تعمير جو قسم آهي جيڪو يونيورسل ڊيٽا پائپ لائن بيان ڪري ٿو.

هن حتمي مقصد کي ڏنو، ٻيون گهرجون قدرتي طور تي پيدا ٿيون. ڪافڪا کي گهرجي:

• انتهائي تيز ٿي وڃو
• پيغامن سان ڪم ڪرڻ دوران وڌيڪ بينڊوڊٿ مهيا ڪريو
• سپورٽ پبلشر-سبسڪرائبر ۽ پوائنٽ-ٽو-پوائنٽ ماڊل
• صارفين کي شامل ڪرڻ سان سست نه ڪريو. مثال طور، ActiveMQ ۾ قطار ۽ موضوع ٻنهي جي ڪارڪردگي گهٽجي ٿي جيئن منزل تي صارفين جو تعداد وڌي ٿو.
• افقي طور تي اسپيبل هجي؛ جيڪڏهن هڪ بروکر جيڪو پيغام جاري رکي ٿو صرف ايترو ڪري سگهي ٿو وڌ ۾ وڌ ڊسڪ اسپيڊ تي، پوءِ اهو سمجھ ۾ اچي ٿو ته ڪارڪردگي کي وڌائڻ لاءِ هڪ بروکر مثال کان ٻاهر وڃڻ.
• پيغامن کي محفوظ ڪرڻ ۽ ٻيهر حاصل ڪرڻ تائين رسائي کي محدود ڪريو

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

متحد منزل ماڊل

مٿي بيان ڪيل ضرورتن کي پورو ڪرڻ لاءِ، ڪافڪا ھڪڙي قسم جي منزل ھيٺ پبلش-سبسڪرائب ۽ پوائنٽ-ٽو-پوائنٽ پيغامن کي گڏ ڪيو آھي. موضوع. اهو انهن ماڻهن لاءِ مونجهارو آهي جن ميسيجنگ سسٽم سان ڪم ڪيو آهي، جتي لفظ ”موضوع“ هڪ نشرياتي ميکانيزم ڏانهن اشارو ڪري ٿو جنهن مان (موضوع کان) پڙهڻ اڻپورو آهي. ڪافڪا جي عنوانن کي هڪ هائبرڊ منزل جو قسم سمجهيو وڃي، جيئن هن ڪتاب جي تعارف ۾ بيان ڪيو ويو آهي.

هن باب جي باقي رهي، جيستائين اسان ٻي صورت ۾ واضح طور تي بيان نه ڪريون، اصطلاح "موضوع" ڪافڪا جي موضوع ڏانهن اشارو ڪندو.

مڪمل طور تي سمجھڻ لاءِ ته موضوع ڪيئن ڪم ڪن ٿا ۽ ڪھڙي ضمانتون مهيا ڪن ٿا، اسان کي پھريائين ڏسڻو پوندو ته ڪفڪا ۾ انھن کي ڪيئن لاڳو ڪيو ويو آھي.
ڪافڪا ۾ هر موضوع جو پنهنجو هڪ لاگ آهي.
ڪافڪا ڏانهن پيغام موڪليندڙ پروڊيوسر هن لاگ تي لکندا آهن، ۽ صارف لاگ مان پڙهي رهيا آهن پوائنٽر استعمال ڪندي جيڪي مسلسل اڳتي وڌندا آهن. وقتي طور تي، ڪافڪا لاگ جي پراڻن حصن کي حذف ڪري ٿو، ڇا انهن حصن ۾ پيغام پڙهيا ويا آهن يا نه. ڪافڪا جي ڊيزائن جو هڪ مرڪزي حصو اهو آهي ته بروکر کي پرواه ناهي ته پيغام پڙهيا وڃن يا نه - اها ڪلائنٽ جي ذميواري آهي.

اصطلاح "لاگ" ۽ "پوائنٽر" ۾ ظاهر نه ٿيندا آهن ڪافڪا دستاويز. اهي معروف اصطلاح هتي سمجھڻ ۾ مدد لاءِ استعمال ڪيا ويا آهن.

هي ماڊل ActiveMQ کان مڪمل طور تي مختلف آهي، جتي سڀني قطارن جا پيغام هڪ ئي لاگ ۾ محفوظ ڪيا ويندا آهن، ۽ بروکر انهن پيغامن کي نشان لڳندو آهي جيئن اهي پڙهڻ کان پوءِ حذف ٿيل آهن.
اچو ته هاڻي ٿورڙو اونڌو ڪريون ۽ موضوع جي لاگ کي وڌيڪ تفصيل سان ڏسو.
ڪافڪا لاگ ڪيترن ئي حصن تي مشتمل آهي (شڪل 3-1). ڪافڪا هر ورهاڱي ۾ سخت حڪم جي ضمانت ڏئي ٿو. هن جو مطلب آهي ته هڪ خاص ترتيب ۾ ورهاڱي ڏانهن لکيل پيغام ساڳئي ترتيب ۾ پڙهيا ويندا. هر ورهاڱي کي رولنگ لاگ فائل جي طور تي لاڳو ڪيو ويو آهي جنهن ۾ شامل آهي هڪ ذيلي سيٽ (ذيلي سيٽ) سڀني پيغامن جي موڪليل موضوع تي ان جي پيدا ڪندڙن طرفان. ٺهيل موضوع تي مشتمل آهي، ڊفالٽ طور، هڪ ورهاڱي. افقي اسڪيلنگ لاءِ ڪافڪا جو مرڪزي خيال پارٽيشنز جو آهي.

شڪل 3-1. ڪافڪا پارٽيشنز

جڏهن ڪو پروڊيوسر ڪافڪا جي موضوع تي پيغام موڪلي ٿو، اهو فيصلو ڪري ٿو ته ڪهڙي ورهاڱي کي پيغام موڪليو وڃي. اسان ان کي وڌيڪ تفصيل سان بعد ۾ ڏسندا.

پيغام پڙهڻ

ڪلائنٽ جيڪو پيغام پڙهڻ چاهي ٿو هڪ نالي واري پوائنٽر کي منظم ڪري ٿو صارف گروپ، جيڪو اشارو ڪري ٿو بند ڪرڻ ورهاڱي ۾ پيغام. هڪ آفسيٽ هڪ واڌارو پوزيشن آهي جيڪو ورهاڱي جي شروعات ۾ 0 تي شروع ٿئي ٿو. هي صارف گروپ، API ۾ استعمال ڪندڙ جي وضاحت ڪيل گروپ_id ذريعي حوالي ڪيو ويو آهي، انهي سان لاڳاپيل آهي ھڪڙو منطقي صارف يا سسٽم.

اڪثر ميسيجنگ سسٽم متوازي طور تي پيغامن کي پروسيس ڪرڻ لاءِ گھڻن مثالن ۽ موضوعن کي استعمال ڪندي منزل کان ڊيٽا پڙهندا آهن. اهڙيء طرح، اتي عام طور تي ڪيترن ئي صارفين جا مثال هوندا جيڪي ساڳئي صارف گروپ کي حصيداري ڪندا آهن.

پڙهڻ جو مسئلو هن ريت بيان ڪري سگهجي ٿو:

• موضوع ۾ گھڻا ڀاڱا آھن
• صارفين جا ڪيترائي گروپ هڪ ئي وقت ۾ هڪ موضوع استعمال ڪري سگهن ٿا
• صارفين جو هڪ گروپ ڪيترن ئي الڳ الڳ مثالن جي ڪري سگھي ٿو

اھو ھڪڙو غير معمولي گھڻن کان گھڻن مسئلو آھي. سمجھڻ لاءِ ته ڪفڪا ڪھڙيءَ طرح صارفين جي گروپن، صارفين جي مثالن ۽ ورھاڱن جي وچ ۾ لاڳاپن کي سنڀاليندو آھي، اچو ته ڏسون ته ترقي پسنديءَ سان وڌيڪ پيچيده پڙھندڙن جي ھڪڙي سيريز کي.

صارفين ۽ صارفين گروپن

اچو ته هڪ شروعاتي نقطي طور وٺون هڪ موضوع سان هڪ ورهاڱي سان (شڪل 3-2).

شڪل 3-2. صارف ورهاڱي کان پڙهي ٿو

جڏهن هڪ صارف مثال هن موضوع سان پنهنجي پنهنجي گروپ_id سان ڳنڍيندو آهي، ان کي هڪ پڙهڻ واري ورهاڱي ۽ ان ورهاڱي ۾ هڪ آفس مقرر ڪيو ويندو آهي. هن آفسيٽ جي پوزيشن ڪلائنٽ ۾ ترتيب ڏني وئي آهي پوائنٽر جي طور تي سڀ کان تازي پوزيشن (نئين پيغام) يا ابتدائي پوزيشن (پراڻو پيغام). صارفين جي درخواستن (چونڊ) موضوع کان پيغام، جنهن جي ڪري انهن کي ترتيب سان لاگ مان پڙهي سگهجي ٿو.
آفسيٽ پوزيشن باقاعدي طور تي واپس ڪافڪا ڏانهن واعدو ڪيو ويو آهي ۽ هڪ اندروني موضوع ۾ پيغامن جي طور تي ذخيرو ٿيل آهي _صارف_آفيس. پڙهيل نياپا اڃا ڊهي نه ويا آهن، هڪ باقاعده بروکر جي برعڪس، ۽ ڪلائنٽ اڳ ۾ ئي ڏٺل پيغامن کي ٻيهر پروسيس ڪرڻ لاءِ آفسيٽ کي ريوائنڊ ڪري سگهي ٿو.

جڏهن هڪ ٻيو منطقي صارف مختلف group_id استعمال ڪندي ڳنڍي ٿو، اهو هڪ ٻئي پوائنٽر کي منظم ڪري ٿو جيڪو پهرين کان آزاد آهي (شڪل 3-3). اهڙيءَ طرح، هڪ ڪافڪا موضوع هڪ قطار وانگر ڪم ڪري ٿو جتي هڪ صارف هجي ۽ هڪ عام پبلش-سبسڪرائب (پب-سب) موضوع وانگر، جنهن ۾ ڪيترائي صارف رڪنيت حاصل ڪن ٿا، اضافي فائدي سان ته سڀئي پيغام محفوظ ڪيا وڃن ٿا ۽ ڪيترائي ڀيرا پروسيس ڪري سگھجن ٿا.

شڪل 3-3. مختلف صارفين گروپن ۾ ٻه صارف هڪ ئي ورهاڱي مان پڙهي رهيا آهن

صارفين جي گروپ ۾ صارفين

جڏهن هڪ صارف مثال ورهاڱي کان ڊيٽا پڙهي ٿو، ان کي پوائنٽر جو پورو ڪنٽرول آهي ۽ پيغامن کي پروسيس ڪري ٿو جيئن اڳئين حصي ۾ بيان ڪيو ويو آهي.
جيڪڏهن صارفين جا ڪيترائي مثال هڪ ئي گروپ_id سان هڪ ورهاڱي سان هڪ موضوع سان ڳنڍيا ويا آهن، پوء اهو مثال جيڪو آخري ڳنڍيل هوندو ان کي پوائنٽر تي ڪنٽرول ڏنو ويندو ۽ ان وقت کان ان کي سڀئي پيغام ملي ويندا (شڪل 3-4).

شڪل 3-4. ساڳئي صارف گروپ ۾ ٻه صارفين ساڳئي ورهاڱي مان پڙهي رهيا آهن

پروسيسنگ جو هي طريقو، جنهن ۾ صارفين جي مثالن جو تعداد حصون جي تعداد کان وڌيڪ آهي، سمجهي سگهجي ٿو هڪ قسم جي خاص صارف جي طور تي. اهو ڪارائتو ٿي سگهي ٿو جيڪڏهن توهان کي ضرورت آهي "فعال-غير فعال" (يا "گرم-گرم") توهان جي صارفين جي مثالن جي ڪلسٽرنگ، جيتوڻيڪ ڪيترن ئي صارفين کي متوازي ۾ هلائڻ ("فعال-فعال" يا "گرم-گرم") کان وڌيڪ عام آهي. صارفين. اسٽينڊ بائي ۾.

مٿي بيان ڪيل هي پيغام ورهائڻ وارو رويو حيرت انگيز ٿي سگهي ٿو ان جي مقابلي ۾ ته عام JMS قطار ڪيئن عمل ڪري ٿي. هن ماڊل ۾، قطار ڏانهن موڪليل پيغامن کي برابر طور تي ٻن صارفين جي وچ ۾ ورهايو ويندو.

گهڻو ڪري، جڏهن اسان صارفين جا ڪيترائي مثال ٺاهيندا آهيون، اسان اهو ڪندا آهيون يا ته پيغامن کي متوازي طور تي پروسيس ڪرڻ لاءِ، يا پڙهڻ جي رفتار کي وڌائڻ لاءِ، يا پڙهڻ واري عمل جي استحڪام کي وڌائڻ لاءِ. جيئن ته صرف هڪ صارف مثال هڪ وقت ۾ ورهاڱي کان ڊيٽا پڙهي سگهي ٿو، اهو ڪيئن حاصل ڪيو ويو ڪافڪا ۾؟

اهو ڪرڻ جو هڪ طريقو اهو آهي ته هڪ واحد صارف مثال استعمال ڪيو وڃي سڀني پيغامن کي پڙهڻ ۽ انهن کي ٿريڊ پول ڏانهن منتقل ڪرڻ لاءِ. جڏهن ته اهو طريقو پروسيسنگ ذريعي وڌائي ٿو، اهو صارف جي منطق جي پيچيدگي کي وڌائي ٿو ۽ پڙهڻ واري نظام جي مضبوطي کي وڌائڻ لاء ڪجھ به نه ڪندو آهي. جيڪڏهن صارف جي هڪ ڪاپي بجلي جي ناڪامي يا ساڳئي واقعي جي ڪري هيٺ ٿي وڃي ٿي، پوء ذيلي تقسيم بند ٿي ويندي آهي.

ڪافڪا ۾ هن مسئلي کي حل ڪرڻ جو روايتي طريقو استعمال ڪرڻ آهي bОوڌيڪ ورهاڱي.

ورهاڱي

ورهاڱي هڪ واحد بروکر مثال جي بينڊوڊٿ کان ٻاهر هڪ موضوع کي پڙهڻ ۽ اسڪيل ڪرڻ لاءِ بنيادي ميڪانيزم آهن. انهي کي بهتر سمجهڻ لاءِ، اچو ته هڪ اهڙي صورتحال تي غور ڪريون جتي هڪ موضوع آهي ٻه ڀاڱا ۽ هڪ صارف ان موضوع تي سبسڪرائب ڪري ٿو (شڪل 3-5).

شڪل 3-5. هڪ صارف ڪيترن ئي ورهاڱي مان پڙهي ٿو

هن منظر ۾، صارف کي ٻنهي حصن ۾ ان جي گروپ_id سان لاڳاپيل پوائنٽرز تي ڪنٽرول ڏنو ويندو آهي ۽ ٻنهي حصن مان پيغام پڙهڻ شروع ڪندو آهي.
جڏهن هڪ ئي گروپ_id لاءِ هڪ اضافي صارف هن موضوع ۾ شامل ڪيو ويو آهي، ڪافڪا پهرين کان ٻئي صارف تائين هڪ ورهاڱي کي ٻيهر ترتيب ڏئي ٿو. ان کان پوء، صارف جو هر مثال موضوع جي هڪ ورهاڱي مان پڙهي سگهندو (شڪل 3-6).

انهي ڳالهه کي يقيني بڻائڻ لاءِ ته پيغامن کي 20 سلسلي ۾ متوازي طور تي پروسيس ڪيو وڃي، توهان کي گهٽ ۾ گهٽ 20 ورهاڱي جي ضرورت آهي. جيڪڏهن گهٽ ورهاڱي وارا آهن، توهان کي صارفين سان ڇڏي ويندي، جن تي ڪم ڪرڻ لاء ڪجهه به ناهي، جيئن اڳ ۾ خاص صارفين جي بحث ۾ بيان ڪيو ويو آهي.

شڪل 3-6. ساڳئي صارف گروپ ۾ ٻه صارفين مختلف حصن مان پڙهيا آهن

هي اسڪيم JMS قطار کي برقرار رکڻ لاء گهربل پيغام جي تقسيم جي مقابلي ۾ ڪافڪا بروکر جي پيچيدگي کي تمام گهڻو گھٽائي ٿو. هتي توهان کي هيٺ ڏنل نقطي بابت پريشان ٿيڻ جي ضرورت ناهي:

• ڪھڙي صارف کي ايندڙ پيغام وصول ڪرڻ گھرجي، راؤنڊ-رابن مختص ڪرڻ جي بنياد تي، اڳواٽ بفرز جي موجوده گنجائش، يا پوئين پيغام (جيئن JMS پيغام گروپن لاءِ).
• ڪهڙا پيغام موڪليا ويا آهن ڪهڙن صارفين ڏانهن ۽ ڇا انهن کي ناڪام ٿيڻ جي صورت ۾ ٻيهر پهچائڻ گهرجي.

سڀ ڪافڪا بروکر کي اهو ڪرڻو آهي ته پيغامن کي ترتيب سان صارف تائين پهچايو جڏهن بعد ۾ انهن کي درخواست ڪري.

بهرحال، پروف ريڊنگ کي متوازي ڪرڻ ۽ ناڪام پيغامن کي ٻيهر موڪلڻ جون گهرجون پوريون نه ٿيون ٿين - انهن جي ذميواري صرف بروکر کان ڪلائنٽ تائين وڃي ٿي. ان جو مطلب اهو آهي ته انهن کي توهان جي ڪوڊ ۾ اڪائونٽ ۾ ورتو وڃي.

پيغام موڪلڻ

ان پيغام جي پيدا ڪندڙ جي ذميواري آهي ته اهو فيصلو ڪري ته ڪهڙي ورهاڱي کي پيغام موڪليو وڃي. انهي طريقي کي سمجهڻ لاءِ جنهن جي ذريعي اهو ڪيو ويو آهي، اسان کي پهريان غور ڪرڻو پوندو ته اسان اصل ۾ ڇا موڪلي رهيا آهيون.

جڏهن ته JMS ۾ اسان ميٽاڊيٽا (هيڊرز ۽ پراپرٽيز) سان گڏ هڪ پيغام جي جوڙجڪ استعمال ڪندا آهيون ۽ هڪ باڊي جنهن ۾ پيل لوڊ (پي لوڊ) هوندو آهي، ڪافڪا ۾ پيغام آهي. جوڙو "اهم-قدر". پيغام پيل لوڊ هڪ قدر جي طور تي موڪليو ويو آهي. ٻئي طرف، ڪنجي، خاص طور تي ورهاڱي لاء استعمال ڪيو ويندو آهي ۽ لازمي هجي ڪاروباري منطق جي مخصوص ڪنجيساڳئي ورهاڱي ۾ لاڳاپيل پيغام رکڻ لاء.

باب 2 ۾، اسان آن لائن بيٽنگ واري منظرنامي تي بحث ڪيو جتي لاڳاپيل واقعن تي عمل ڪرڻ جي ضرورت آهي هڪ واحد صارف طرفان:

1. يوزر اڪائونٽ ترتيب ڏنل آهي.
2. رقم اڪائونٽ ۾ جمع ڪئي وئي آهي.
3. هڪ شرط لڳايو ويو آهي جيڪو اڪائونٽ مان پئسا ڪڍي ٿو.

جيڪڏهن هر واقعي هڪ پيغام آهي جيڪو هڪ موضوع تي پوسٽ ڪيو ويو آهي، پوء قدرتي چيڪ هوندو اڪائونٽ ID.
جڏهن ڪافڪا پروڊيوسر API استعمال ڪندي هڪ پيغام موڪليو ويندو آهي، اهو هڪ ورهاڱي واري فنڪشن ڏانهن منتقل ڪيو ويندو آهي، جيڪو پيغام ڏنو ويو آهي ۽ ڪافڪا ڪلستر جي موجوده حالت، ورهاڱي جي ID واپس ڪري ٿو جنهن ڏانهن پيغام موڪليو وڃي. هي فيچر جاوا ۾ پارٽشنر انٽرفيس ذريعي لاڳو ڪيو ويو آهي.

هي انٽرفيس هن طرح نظر اچي ٿو:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

توهان جي پنهنجي ورهاڱي واري حڪمت عملي لکڻ

اچو ته هڪ مثال تي نظر رکون جتي توهان پيغام پيل لوڊ سان گڏ ميٽا ڊيٽا موڪلڻ چاهيو ٿا. اسان جي مثال ۾ پيل لوڊ راند جي اڪائونٽ ۾ جمع ڪرڻ لاء هڪ هدايت آهي. هڪ هدايت اها شيءِ آهي جنهن جي اسان ضمانت ٿيڻ چاهيون ٿا ته ٽرانسميشن تي ترميم نه ڪئي وڃي ۽ پڪ ڪرڻ چاهيون ٿا ته صرف هڪ قابل اعتماد اپ اسٽريم سسٽم ان هدايت کي شروع ڪري سگهي ٿو. انهي صورت ۾، موڪلڻ ۽ وصول ڪرڻ وارو نظام پيغام جي تصديق ڪرڻ لاء دستخط جي استعمال تي متفق آهن.
عام JMS ۾، اسان صرف وضاحت ڪريون ٿا "پيغام جي دستخط" ملڪيت ۽ ان کي پيغام ۾ شامل ڪريو. بهرحال، ڪافڪا اسان کي ميٽاڊيٽا پاس ڪرڻ لاءِ ڪو ميکانيزم نه ٿو ڏئي، فقط هڪ اهم ۽ قدر.

جيئن ته قيمت هڪ بينڪ جي منتقلي پيلي لوڊ آهي جنهن جي سالميت کي اسان بچائڻ چاهيون ٿا، اسان وٽ ٻيو ڪو به اختيار ناهي ته ڊيٽا جي جوڙجڪ کي وضاحت ڪرڻ لاء استعمال ڪرڻ لاء. فرض ڪيو ته اسان کي ورهاڱي لاءِ هڪ اڪائونٽ ID جي ضرورت آهي، ڇاڪاڻ ته اڪائونٽ سان لاڳاپيل سڀئي پيغام لازمي طور تي پروسيس ٿيڻ گهرجن، اسان هيٺ ڏنل JSON جوڙجڪ سان گڏ ڪنداسين:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

ڇاڪاڻ ته دستخط جو قدر مختلف هوندو پئلوڊ جي لحاظ سان، پارٽيشنر انٽرفيس جي ڊفالٽ هيشنگ حڪمت عملي قابل اعتماد طور تي لاڳاپيل پيغامن کي گروپ نه ڪندي. تنهن ڪري، اسان کي پنهنجي حڪمت عملي لکڻ جي ضرورت پوندي جيڪا هن ڪيئي کي پارس ڪندي ۽ اڪائونٽ آئي ڊي جي قيمت کي ورهاڱي ڪندي.

ڪافڪا ۾ اسٽور ۾ پيغامن جي بدعنواني کي ڳولڻ لاء چيڪسم شامل آهن ۽ حفاظتي خاصيتن جو مڪمل سيٽ آهي. ان جي باوجود، صنعت جي مخصوص گهرجن، جهڙوڪ مٿي ڏنل، ڪڏهن ڪڏهن ظاهر ٿيندا آهن.

صارف جي ورهاڱي واري حڪمت عملي کي يقيني بڻائڻ گهرجي ته سڀئي لاڳاپيل پيغام ساڳئي ورهاڱي ۾ ختم ٿي وڃن. جڏهن ته اهو سادو لڳي ٿو، گهرج لاڳاپيل پوسٽن کي ترتيب ڏيڻ جي اهميت جي لحاظ کان پيچيده ٿي سگهي ٿو ۽ هڪ موضوع ۾ ورهاڱي جو تعداد ڪيئن مقرر ڪيو ويو آهي.

ھڪڙي موضوع ۾ ورهاڱي جو تعداد وقت سان تبديل ٿي سگھي ٿو، جيئن اھي شامل ڪري سگھجن ٿيون جيڪڏھن ٽريفڪ ابتدائي اميدن کان ٻاھر وڃي. اهڙيءَ طرح، پيغام جي چاٻين کي ورهاڱي سان لاڳاپيل ڪري سگهجي ٿو جيڪي اهي اصل ۾ موڪليا ويا هئا، رياست جو هڪ ٽڪرو پيدا ڪندڙ مثالن جي وچ ۾ شيئر ڪيو وڃي.

غور ڪرڻ لاءِ هڪ ٻيو عنصر آهي پيغامن جي برابر ورڇ ورهاڱي ۾. عام طور تي، ڪنجيون پيغامن ۾ هڪجهڙائي سان ورهائي نه وينديون آهن، ۽ هيش فنڪشن ڪنجي جي ننڍڙي سيٽ لاءِ پيغامن جي منصفاڻي ورڇ جي ضمانت نه ڏيندا آهن.
اهو نوٽ ڪرڻ ضروري آهي ته جڏهن توهان پيغامن کي ورهائڻ لاءِ چونڊيندا آهيو، الڳ ڪندڙ پاڻ کي ٻيهر استعمال ڪرڻ جي ضرورت پوندي.

مختلف جاگرافيائي جڳهن ۾ ڪافڪا ڪلستر جي وچ ۾ ڊيٽا کي نقل ڪرڻ جي ضرورت تي غور ڪريو. انهيءَ مقصد لاءِ، ڪافڪا هڪ ڪمانڊ لائين ٽول سان اچي ٿو، جنهن کي MirrorMaker سڏيو ويندو آهي، جيڪو هڪ ڪلستر مان پيغام پڙهڻ ۽ ٻئي ڏانهن منتقل ڪرڻ لاءِ استعمال ٿيندو آهي.

MirrorMaker کي نقل ٿيل موضوع جي ڪنجين کي سمجھڻ گھرجي ته جيئن پيغامن جي وچ ۾ لاڳاپا ترتيب برقرار رکڻ لاءِ جڏهن ڪلسترن جي وچ ۾ نقل ڪيو وڃي، ڇاڪاڻ ته ان موضوع لاءِ ڀاڱن جو تعداد ٻن ڪلسٽرن ۾ ساڳيو نه ٿي سگھي.

ڪسٽم ورهاڱي واري حڪمت عمليون نسبتاً ناياب آهن، جيئن ڊفالٽ هيشنگ يا گول رابن تمام گهڻين حالتن ۾ سٺو ڪم ڪري ٿو. تنهن هوندي، جيڪڏهن توهان کي مضبوط آرڊرنگ جي ضمانت جي ضرورت آهي يا پئلوڊس مان ميٽاداٽا ڪڍڻ جي ضرورت آهي، پوء ورهاڱي ڪجهه آهي جيڪو توهان کي ويجهي نظر رکڻ گهرجي.

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

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

پيدا ڪندڙ معاهدو

ورهاڱي صرف هڪ شيء ناهي جنهن تي غور ڪيو وڃي جڏهن پيغام موڪلڻ. اچو ته جاوا API ۾ پروڊيوسر ڪلاس جي send() طريقن تي نظر وجهون:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

اهو فوري طور تي نوٽ ڪيو وڃي ٿو ته ٻنهي طريقن کي واپسي مستقبل، جنهن مان ظاهر ٿئي ٿو ته موڪل جو عمل فوري طور تي انجام نه ڏنو ويو آهي. نتيجو اهو آهي ته هڪ پيغام (ProducerRecord) هر فعال ورهاڱي لاءِ موڪليندڙ بفر ڏانهن لکيو ويو آهي ۽ ڪافڪا ڪلائنٽ لائبريري ۾ هڪ پس منظر واري سلسلي جي طور تي بروکر ڏانهن موڪليو ويو آهي. جڏهن ته هي شيون ناقابل يقين حد تائين تيز ڪري ٿو، ان جو مطلب آهي ته هڪ غير تجربيڪار ايپليڪيشن پيغام وڃائي سگهي ٿي جيڪڏهن ان جي عمل کي روڪيو وڃي.

هميشه وانگر، ڪارڪردگي جي خرچ تي موڪلڻ واري آپريشن کي وڌيڪ قابل اعتماد بڻائڻ جو هڪ طريقو آهي. ھن بفر جي سائيز 0 تي سيٽ ڪري سگھجي ٿي، ۽ موڪلڻ واري درخواست واري سلسلي کي انتظار ڪرڻ تي مجبور ڪيو ويندو جيستائين بروکر ڏانھن پيغام جي منتقلي مڪمل ٿي وڃي، ھيٺ ڏنل آھي:

RecordMetadata metadata = producer.send(record).get();

وڌيڪ پيغام پڙهڻ بابت

پيغام پڙهڻ ۾ اضافي پيچيدگيون آهن جن بابت وضاحت ڪرڻ جي ضرورت آهي. JMS API جي برعڪس، جيڪو پيغام جي جواب ۾ هڪ پيغام ٻڌندڙ کي هلائي سگهي ٿو صارفين ڪافڪا صرف پول. اچو ته طريقيڪار تي هڪ ويجهي نظر رکون راءِ ()هن مقصد لاء استعمال ڪيو:

ConsumerRecords < K, V > poll(long timeout);

طريقي جي واپسي جي قيمت ھڪڙي ڪنٽينر جي جوڙجڪ آھي جنھن ۾ گھڻن شيون شامل آھن صارف رڪارڊ ممڪن طور تي ڪيترن ئي حصن مان. صارف رڪارڊ پاڻ هڪ هولڊر شئي آهي هڪ اهم-قدر واري جوڙي لاءِ لاڳاپيل ميٽا ڊيٽا سان، جيئن ته ورهاڱو جنهن مان اهو نڪتل آهي.

جيئن باب 2 ۾ بحث ڪيو ويو آهي، اسان کي ذهن ۾ رکڻ گهرجي ته پيغامن جو ڇا ٿيندو جڏهن اهي ڪاميابيء سان يا ناڪام طريقي سان عمل ڪيا ويا آهن، مثال طور، جيڪڏهن ڪلائنٽ پيغام تي عمل ڪرڻ جي قابل ناهي يا جيڪڏهن اهو ختم ٿي وڃي. JMS ۾، اهو هڪ اعتراف واري طريقي سان سنڀاليو ويو. بروکر يا ته ڪاميابيءَ سان پروسيس ٿيل پيغام کي حذف ڪندو، يا خام يا جعلي پيغام کي ٻيهر پهچائيندو (فرض ڪيو ٽرانزيڪشن استعمال ڪيو ويو).
ڪافڪا بلڪل مختلف ڪم ڪري ٿو. پروف ريڊنگ کان پوءِ بروکر ۾ پيغام ڊليٽ نه ڪيا ويا آهن، ۽ ناڪامي تي ڇا ٿئي ٿو اهو خود پروف ريڊنگ ڪوڊ جي ذميواري آهي.

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

پڙهڻ واري ماڊل ڏانهن واپسي اڳ ۾ بحث ڪيو ويو، پيغام پروسيسنگ ٽن مرحلن تي مشتمل آهي:

1. پڙهڻ لاء هڪ پيغام حاصل ڪريو.
2. پيغام تي عمل ڪريو.
3. پيغام جي تصديق ڪريو.

ڪافڪا صارف هڪ ترتيب واري اختيار سان گڏ اچي ٿو enable.auto.commit. هي اڪثر استعمال ٿيل ڊفالٽ سيٽنگ آهي، جيئن عام آهي سيٽنگون جنهن ۾ لفظ "خودڪار" شامل آهي.

ڪافڪا 0.10 کان اڳ، هڪ ڪلائنٽ هن آپشن کي استعمال ڪندي ايندڙ ڪال تي پڙهيل آخري پيغام جو آفسيٽ موڪليندو. راءِ () پروسيسنگ کان پوء. ان جو مطلب اهو ٿيو ته جيڪي به پيغام جيڪي اڳ ۾ حاصل ڪيا ويا هئا انهن کي ٻيهر پروسيس ڪري سگهجي ٿو جيڪڏهن ڪلائنٽ اڳ ۾ ئي پروسيس ڪري چڪو هو پر ڪال ڪرڻ کان اڳ غير متوقع طور تي تباهه ٿي ويو. راءِ (). ڇاڪاڻ ته بروکر ڪا به حالت نه رکندو آهي ته هڪ پيغام ڪيترا ڀيرا پڙهيو ويو آهي، ايندڙ صارف جيڪو اهو پيغام ٻيهر حاصل ڪري ٿو اهو نه ڄاڻندو ته ڪجهه خراب ٿيو. اهو رويو pseudo-transactional هو. آفسيٽ صرف ان صورت ۾ انجام ڏنو ويو هو ته پيغام ڪاميابي سان عمل ڪيو ويو، پر جيڪڏهن ڪلائنٽ کي ختم ڪيو ويو، بروکر ساڳيو پيغام ٻيهر موڪليندو ٻي ڪلائنٽ ڏانهن. اهو رويو پيغام پهچائڻ جي ضمانت سان مطابقت رکي ٿو "گهٽ ۾ گهٽ هڪ ڀيرو".

ڪافڪا 0.10 ۾، ڪلائنٽ ڪوڊ تبديل ڪيو ويو آهي ته جيئن ترتيب ڏنل ڪلائنٽ لائبريري طرفان وقتي طور تي ڪميٽ شروع ڪيو وڃي. auto.commit.interval.ms. هي رويو JMS AUTO_ACKNOWLEDGE ۽ DUPS_OK_ACKNOWLEDGE طريقن جي وچ ۾ آهي. جڏهن خودڪار ڪمٽ استعمال ڪندي، پيغامن کي انجام ڏئي سگهجي ٿو ته ڇا اهي اصل ۾ پروسيس ڪيا ويا آهن - اهو ٿي سگهي ٿو سست صارف جي صورت ۾. جيڪڏهن هڪ صارف ختم ٿي ويو، پيغام ايندڙ صارف پاران حاصل ڪيا ويندا، ڪم ٿيل پوزيشن کان شروع ٿيندي، جنهن جي نتيجي ۾ هڪ مس ٿيل پيغام ٿي سگهي ٿو. انهي حالت ۾، ڪافڪا پيغامن کي نه وڃائي ڇڏيو، پڙهڻ واري ڪوڊ صرف انهن تي عمل نه ڪيو.

ھن موڊ ۾ ھڪڙو ئي واعدو آھي جيئن ورزن 0.9 ۾: پيغامن تي عمل ڪري سگھجي ٿو، پر جيڪڏھن اھو ناڪام ٿئي ٿو، آفسيٽ انجام نه ٿي سگھي، امڪاني طور تي پهچائڻ جو سبب بڻجندي ٻيڻو ٿي سگھي ٿو. ايگزيڪيوٽو ڪرڻ وقت وڌيڪ پيغام جيڪي توهان حاصل ڪندا راءِ ()، وڌيڪ اهو مسئلو.

جيئن صفحي 21 تي ”ريڊنگ ميسيجز فرام اي قطار“ ۾ بحث ڪيو ويو آهي، ميسيجنگ سسٽم ۾ پيغام جي هڪ دفعي ترسيل جهڙي ڪا به شيءِ ناهي جڏهن ناڪامي جي طريقن کي نظر ۾ رکيو وڃي.

ڪافڪا ۾، ٻه طريقا آهن انجام ڏيڻ (ڪمٽ) هڪ آفسٽ (آفسيٽ): خودڪار ۽ دستي طور. ٻنهي صورتن ۾، پيغامن تي عمل ڪري سگهجي ٿو ڪيترائي ڀيرا جيڪڏهن پيغام تي عمل ڪيو ويو پر ڪم ڪرڻ کان اڳ ناڪام ٿيو. توهان اهو پڻ چونڊي سگهو ٿا ته پيغام تي عمل نه ڪيو وڃي جيڪڏهن ڪمٽ پس منظر ۾ ٿيو ۽ توهان جو ڪوڊ مڪمل ٿي ويو ان کان اڳ پروسيس ٿيڻ کان اڳ (شايد ڪافڪا 0.9 ۽ اڳ ۾).

توھان ڪنٽرول ڪري سگھوٿا مينوئل آفسيٽ ڪمٽ جي عمل کي ڪيفڪا صارف API ۾ پيٽرول سيٽ ڪندي enable.auto.commit هيٺ ڏنل طريقن مان هڪ کي غلط ۽ واضح طور تي سڏڻ لاءِ:

void commitSync();
void commitAsync();

جيڪڏهن توهان "گهٽ ۾ گهٽ هڪ ڀيرو" پيغام تي عمل ڪرڻ چاهيو ٿا، توهان کي دستي طور تي آفسيٽ انجام ڏيڻ گهرجي ڪميٽ سنڪ ()پيغامن کي پروسيس ڪرڻ کان پوءِ فوري طور تي هن حڪم تي عمل ڪندي.

اهي طريقا پيغامن کي پروسيس ٿيڻ کان پهريان تسليم ڪرڻ جي اجازت نه ڏيندا آهن، پر اهي ٽرانزيڪشن جي ظاهر ٿيڻ دوران امڪاني پروسيسنگ دير کي ختم ڪرڻ لاء ڪجھ به نه ڪندا آهن. ڪافڪا ۾ ڪوبه معاملو ناهي. ڪلائنٽ کي هيٺين ڪرڻ جي صلاحيت نه آهي:

• خودڪار طور تي هڪ جعلي پيغام واپس آڻيو. صارفين کي پاڻ کي لازمي طور تي مشڪلاتن واري پيل لوڊ ۽ پس منظر جي بندش مان پيدا ٿيندڙ استثنا کي سنڀالڻ گهرجي، جيئن اهي پيغام ٻيهر پهچائڻ لاء بروکر تي ڀروسو نٿا ڪري سگهن.
• هڪ ايٽمي آپريشن ۾ ڪيترن ئي عنوانن ڏانهن پيغام موڪليو. جيئن اسان جلد ئي ڏسنداسين، مختلف عنوانن تي ڪنٽرول ۽ تقسيم ڪيفڪا ڪلستر ۾ مختلف مشينن تي رهجي سگهن ٿيون جيڪي موڪلڻ وقت ٽرانزيڪشن کي هموار نه ڪن ٿيون. هن لکڻ جي وقت تي، ڪجهه ڪم ڪيو ويو آهي انهي کي ممڪن ڪرڻ لاء KIP-98 سان.
• ھڪڙي موضوع مان ھڪڙو پيغام پڙھڻ سان گڏ ھڪڙو پيغام ٻئي موضوع ڏانھن موڪلڻ سان. ٻيهر، ڪافڪا جو فن تعمير ڪيترن ئي آزاد مشينن تي منحصر آهي جيڪو هڪ بس وانگر هلندو آهي ۽ ان کي لڪائڻ جي ڪا به ڪوشش نه ڪئي وئي آهي. مثال طور، ڪي به API جزا نه آهن جيڪي توهان کي ڳنڍڻ جي اجازت ڏين ٿيون صارف и پيدا ڪندڙ هڪ ٽرانزيڪشن ۾. JMS ۾، هي اعتراض طرفان مهيا ڪيل آهي اجلاسجنهن مان پيدا ٿين ٿا ميسيج پروڊيوسر и پيغام صارفين.

جيڪڏهن اسان ٽرانزيڪشن تي ڀروسو نٿا ڪري سگهون ته، اسان روايتي پيغام رسائيندڙ سسٽم پاران مهيا ڪيل سيمينٽڪس کي ڪيئن ويجھو مهيا ڪري سگهون ٿا؟

جيڪڏهن اهو امڪان آهي ته پيغام تي عمل ٿيڻ کان اڳ صارف جي آفٽ ۾ اضافو ٿي سگهي ٿو، جهڙوڪ صارف جي حادثي دوران، پوء صارف کي اهو ڄاڻڻ جو ڪو طريقو ناهي ته ڇا ان جي صارف گروپ پيغام کي مس ڪيو آهي جڏهن ان کي تقسيم ڪيو ويو آهي. تنهنڪري هڪ حڪمت عملي اها آهي ته آفسيٽ کي پوئين پوزيشن ڏانهن موٽايو وڃي. ڪافڪا صارف API هن لاءِ هيٺيان طريقا مهيا ڪري ٿي:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

طريقو ڳوليو() طريقي سان استعمال ڪري سگهجي ٿو
offsetsForTimes (نقشو ٽائم اسٽيمپس ڳولھا) ماضي ۾ ڪنهن خاص نقطي تي رياست ڏانهن موٽڻ.

واضح طور تي، هن طريقي کي استعمال ڪرڻ جو مطلب اهو آهي ته اهو تمام گهڻو امڪان آهي ته ڪجهه پيغام جيڪي اڳ ۾ پروسيس ڪيا ويا آهن پڙهي ۽ ٻيهر پروسيس ڪيا ويندا. ھن کان بچڻ لاءِ، اسين استعمال ڪري سگھون ٿا idempotent reading، جيئن باب 4 ۾ بيان ڪيو ويو آھي، اڳي ڏٺل پيغامن جي ٽريڪ رکڻ ۽ نقلن کي ختم ڪرڻ لاءِ.

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

ذاتي مشاهدو ڏيکاري ٿو ته جيئن پيغامن جي شدت وڌي ٿي، تيئن تيئن هر فرد جي پيغام جو قدر گهٽجي ٿو. وڏا نياپا قيمتي هوندا آهن جڏهن هڪ مجموعي شڪل ۾ ڏٺو ويندو آهي.

اعلي دستيابي

ڪافڪا جو اعليٰ دستيابي جو طريقو ActiveMQ جي انداز کان بلڪل مختلف آهي. ڪافڪا اسڪيل-آئوٽ ڪلستر جي چوڌاري ٺهيل آهي جتي سڀئي بروکر مثال هڪ ئي وقت پيغام وصول ۽ تقسيم ڪن ٿا.

هڪ ڪافڪا ڪلستر مختلف سرورن تي هلندڙ ڪيترن ئي بروکر مثالن تي مشتمل آهي. ڪافڪا کي عام اسٽينڊ هارڊويئر تي هلائڻ لاءِ ڊزائين ڪيو ويو هو، جتي هر نوڊ کي پنهنجي مخصوص اسٽوريج هوندي آهي. نيٽ ورڪ منسلڪ اسٽوريج (SAN) جي استعمال جي سفارش نه ڪئي وئي آهي ڇاڪاڻ ته ڪيترن ئي ڪمپيوٽ نوڊس وقت لاء مقابلو ڪري سگهن ٿيون.Ыe اسٽوريج وقفو ۽ تڪرار پيدا ڪريو.

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

بروکرز سرور ڪلستر سان ڳنڍيل آهن زو سنڀاليندڙ، جيڪو ڪم ڪري ٿو ترتيب جي ڊيٽا رجسٽري ۽ هر بروکر جي ڪردار کي همٿائڻ لاءِ استعمال ڪيو ويندو آهي. ZooKeeper پاڻ هڪ ورهايل نظام آهي جيڪو معلومات جي نقل ذريعي اعلي دستيابي مهيا ڪري ٿو. ڪورم.

بنيادي صورت ۾، هڪ موضوع هيٺ ڏنل خاصيتن سان ڪافڪا ڪلستر ۾ ٺهيل آهي:

• ورهاڱي جو تعداد. جيئن اڳ ۾ بحث ڪيو ويو آهي، هتي استعمال ٿيل صحيح قدر متوازي پڙهڻ جي گهربل سطح تي منحصر آهي.
• ريپليڪشن فيڪٽر (فڪٽر) اهو طئي ڪري ٿو ته ڪلستر ۾ ڪيترا بروکر مثالن ۾ هن ورهاڱي لاء لاگز شامل ٿيڻ گهرجن.

ڪوآرڊينيشن لاءِ ZooKeepers استعمال ڪندي، ڪافڪا ڪلستر ۾ بروکرز جي وچ ۾ منصفانه طور تي نئين ورهاڱي کي ورهائڻ جي ڪوشش ڪري ٿو. اهو هڪ واحد مثال طرفان ڪيو ويندو آهي جيڪو ڪم ڪري ٿو ڪنٽرولر.

هلڻ وقت هر موضوع جي ورهاڱي لاء ڪنٽرولر هڪ بروکر کي ڪردار تفويض ڪريو aggwan (ليڊر، ماسٽر، پيش ڪندڙ) ۽ پوئلڳ (پوئلڳ، غلام، ماتحت). بروکر، هن ورهاڱي جي اڳواڻ طور ڪم ڪري رهيو آهي، پروڊڪٽرن طرفان موڪليل سڀني پيغامن کي وصول ڪرڻ ۽ پيغامن کي صارفين ڏانهن ورهائڻ جو ذميوار آهي. جڏهن پيغام هڪ موضوع جي ورهاڱي ڏانهن موڪليا ويا آهن، اهي سڀئي بروکر نوڊس ڏانهن نقل ڪيا ويا آهن جيڪي انهي ورهاڱي لاء پيروڪار طور ڪم ڪري رهيا آهن. ورهاڱي جي لاگن تي مشتمل هر نوڊ سڏيو ويندو آهي نقل. هڪ بروکر ڪجهه ورهاڱي لاء اڳواڻ طور ڪم ڪري سگهي ٿو ۽ ٻين لاء پيروڪار جي طور تي.

هڪ پيروڪار کي سڏيو ويندو آهي جنهن ۾ ليڊر طرفان رکيل سڀئي پيغام شامل آهن هم وقت سازي واري نقل (هڪ نقل جيڪا هم وقت سازي واري حالت ۾ آهي، ان-مطابق واري نقل). جيڪڏهن ورهاڱي لاءِ ليڊر جي حيثيت سان ڪم ڪندڙ بروکر هيٺ ٿي وڃي ٿو، ڪو به بروکر جيڪو تازو آهي يا انهي ورهاڱي لاءِ هم وقت سازي ڪري ٿو، اهو ليڊر رول تي قبضو ڪري سگهي ٿو. اهو هڪ ناقابل اعتماد حد تائين پائيدار ڊيزائن آهي.

پروسيسر جي ترتيب جو حصو پيٽرولر آهي acks، جيڪو اهو طئي ڪري ٿو ته ڪيترين نقلن کي لازمي طور تي پيغام جي رسيد کي تسليم ڪرڻ گهرجي (اعتراف ڪرڻ) ان کان اڳ جو ايپليڪيشن ٿريڊ موڪلڻ جاري رکي: 0، 1، يا سڀ. جيڪڏهن مقرر ڪيو وڃي سڀ، پوءِ جڏهن هڪ پيغام ملي ٿو، ليڊر هڪ تصديق واپس موڪليندو پروڊيوسر کي جيئن ئي اهو ڪيترن ئي اشارن مان رڪارڊ جي تصديق (اعترافات) وصول ڪري ٿو (بشمول پاڻ) موضوع جي ترتيب سان بيان ڪيل min.insync.replicas (ڊفالٽ 1). جيڪڏهن پيغام ڪاميابيءَ سان نقل نه ٿي ڪري سگھجي، ته پوءِ پروڊيوسر ايپليڪيشن استثنا اڇلائي ڇڏيندو (NotEnoughReplicas يا NotEnoughReplicasAfterAppend).

هڪ عام تشڪيل 3 جي نقلي عنصر سان هڪ موضوع ٺاهي ٿي (1 ليڊر، 2 پوئلڳ في ورهاڱي) ۽ پيراميٽر min.insync.replicas 2 تي مقرر ڪيو ويو آهي. انهي صورت ۾، ڪلستر هڪ بروکرز کي اجازت ڏيندو جيڪو موضوع جي ورهاڱي کي منظم ڪري رهيو آهي بغير ڪلائنٽ ايپليڪيشنن کي متاثر ڪرڻ کان سواء.

اهو اسان کي ڪارڪردگي ۽ اعتبار جي وچ ۾ اڳ ۾ ئي واقف واپاري بند ڏانهن واپس آڻيندو آهي. نقل ٿئي ٿي اضافي انتظار جي وقت جي خرچ تي پوئلڳن کان تصديق (اعترافات) لاءِ. جيتوڻيڪ، ڇاڪاڻ ته اهو متوازي ۾ هلندو آهي، گهٽ ۾ گهٽ ٽن نوڊس کي نقل ڪرڻ جي ڪارڪردگي ٻن وانگر آهي (نيٽ ورڪ بينڊوڊٿ جي استعمال ۾ واڌ کي نظر انداز ڪندي).

هن نقل واري اسڪيم کي استعمال ڪندي، ڪافڪا چالاڪي سان هر پيغام کي جسماني طور تي لکڻ جي ضرورت کان پاسو ڪري ٿو آپريشن سان ڊسڪ تي هم وقت سازي (). پروڊيوسر پاران موڪليل هر پيغام ورهاڱي جي لاگ ڏانهن لکيو ويندو، پر جيئن باب 2 ۾ بحث ڪيو ويو آهي، فائل ڏانهن لکڻ شروعاتي طور تي آپريٽنگ سسٽم جي بفر ۾ ڪيو ويندو آهي. جيڪڏهن هي پيغام ڪنهن ٻئي ڪافڪا جي مثال تي نقل ڪيو ويو آهي ۽ ان جي ياداشت ۾ آهي، ليڊر جي گم ٿيڻ جو مطلب اهو ناهي ته پيغام خود گم ٿي ويو آهي - اهو هڪ هم وقت سازي نقل ذريعي ورتو وڃي ٿو.
آپريشن ڪرڻ کان انڪار هم وقت سازي () مطلب ته ڪافڪا پيغامن کي ايترو تيزيءَ سان وصول ڪري سگهي ٿو جيترو اهو انهن کي ميموري ۾ لکي سگهي ٿو. برعڪس، جيترو وقت توهان ڊسڪ ۾ ميموري فلش ڪرڻ کان پاسو ڪري سگهو ٿا، اوترو بهتر. انهي سبب لاء، ڪافڪا بروڪرز لاء 64 GB يا وڌيڪ ميموري مختص ڪرڻ غير معمولي ناهي. هن ياداشت جي استعمال جو مطلب اهو آهي ته هڪ واحد ڪافڪا مثال آساني سان تيز رفتار سان هلائي سگهي ٿو هزارين ڀيرا تيز رفتار هڪ روايتي پيغام بروکر کان.

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

هڪ ڪافڪا بروکر جي ڀيٽ ۾ ڪافڪا ڪلستر ۾ گهڻو بهتر ڪارڪردگي ممڪن آهي، ڇاڪاڻ ته موضوع جي ورهاڱي کي ڪيترن ئي الڳ مشينن ۾ ماپ ڪري سگهجي ٿو.

نتيجو

هن باب ۾، اسان ڏٺو ته ڪيئن ڪافڪا فن تعمير ڪلائنٽ ۽ بروکرز جي وچ ۾ لاڳاپن کي ٻيهر تصور ڪري ٿو هڪ ناقابل اعتماد حد تائين مضبوط پيغام رسائيندڙ پائپ لائن مهيا ڪرڻ لاء، هڪ روايتي پيغام بروکر جي ڀيٽ ۾ ڪيترائي ڀيرا وڌيڪ ذريعي. اسان انهي ڪارڪردگي تي بحث ڪيو آهي جيڪو اهو حاصل ڪرڻ لاءِ استعمال ڪري ٿو ۽ مختصر طور تي ايپليڪيشنن جي فن تعمير تي غور ڪيو آهي جيڪي هن ڪارڪردگي کي مهيا ڪن ٿيون. ايندڙ باب ۾، اسان عام مسئلن تي نظر وجهنداسين پيغام رسائيندڙ ايپليڪيشنن کي حل ڪرڻ ۽ انهن کي حل ڪرڻ لاءِ حڪمت عملين تي بحث ڪرڻ جي ضرورت آهي. اسان باب کي ختم ڪنداسين ان بيان سان ته عام طور تي ميسيجنگ ٽيڪنالاجيز بابت ڪيئن ڳالهايو وڃي ته جيئن توهان پنهنجي استعمال جي ڪيسن لاءِ انهن جي مناسبيت جو اندازو لڳائي سگهو.

اڳيون ترجمو ڪيل حصو: پيغام بروکرز کي سمجهڻ. ActiveMQ ۽ Kafka سان ميسيجنگ جي ميڪنڪس کي سکڻ. باب 1

ترجمو ڪيو ويو: tele.gg/middle_java

جاري رکڻ گهرجي…

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

ڇا ڪافڪا توهان جي تنظيم ۾ استعمال ڪيو ويو آهي؟

• ته

• نه

• اڳ استعمال ڪيو ويو، هاڻي نه

• اسان کي استعمال ڪرڻ جو منصوبو آهي

38 صارفين ووٽ ڏنو. 8 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com