پرو ہوسٹر > بلاگ > انتظامیہ > پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا

ایک چھوٹی سی کتاب کے ترجمہ کا تسلسل:
پیغام بروکرز کو سمجھنا
مصنف: Jakub Korab، پبلشر: O'Reilly Media, Inc.، اشاعت کی تاریخ: جون 2017، ISBN: 9781492049296۔

گزشتہ ترجمہ شدہ حصہ: پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 1 تعارف

سبق نمبر 3

Kafka

کافکا کو لنکڈ اِن نے روایتی میسج بروکرز کی کچھ حدود کو پورا کرنے اور مختلف پوائنٹ ٹو پوائنٹ انٹریکشن کے لیے ایک سے زیادہ میسج بروکرز قائم کرنے سے بچنے کے لیے تیار کیا تھا، جس کی تفصیل اس کتاب میں صفحہ 28 پر "Scaling up and out" کے تحت دی گئی ہے۔ . استعمال کے کیسز LinkedIn نے بڑی حد تک ڈیٹا کی بہت بڑی مقدار کے یک طرفہ ادخال پر انحصار کیا ہے، جیسے کہ صفحہ کلکس اور رسائی کے لاگ، جبکہ اب بھی اس ڈیٹا کو پروڈیوسرز یا دیگر صارفین کی پیداواری صلاحیت کو متاثر کیے بغیر متعدد سسٹمز کے ذریعے استعمال کرنے کی اجازت دیتا ہے۔ درحقیقت، کافکا کے موجود ہونے کی وجہ یہ ہے کہ یونیورسل ڈیٹا پائپ لائن جس قسم کے میسجنگ فن تعمیر کو بیان کرتی ہے۔

اس حتمی مقصد کو دیکھتے ہوئے، قدرتی طور پر دیگر ضروریات پیدا ہوئیں۔ کافکا کو چاہیے:

  • بہت تیز ہو جاؤ
  • پیغامات کے ساتھ کام کرتے وقت مزید بینڈوتھ فراہم کریں۔
  • پبلشر-سبسکرائبر اور پوائنٹ ٹو پوائنٹ ماڈلز کو سپورٹ کریں۔
  • صارفین کو شامل کرنے میں سست نہ ہوں۔ مثال کے طور پر، ایکٹیو ایم کیو میں قطار اور موضوع دونوں کی کارکردگی کم ہوتی جاتی ہے کیونکہ منزل پر صارفین کی تعداد میں اضافہ ہوتا ہے۔
  • افقی طور پر توسیع پذیر ہو؛ اگر ایک بروکر جو پیغامات کو برقرار رکھتا ہے وہ صرف زیادہ سے زیادہ ڈسک کی رفتار سے ایسا کر سکتا ہے، تو کارکردگی کو بڑھانے کے لیے ایک بروکر مثال سے آگے جانا سمجھ میں آتا ہے۔
  • پیغامات کو ذخیرہ کرنے اور دوبارہ حاصل کرنے تک رسائی کو محدود کریں۔

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

یونیفائیڈ ڈیسٹینیشن ماڈل

اوپر بیان کردہ تقاضوں کو پورا کرنے کے لیے، کافکا نے ایک قسم کی منزل کے تحت پبلش-سبسکرائب اور پوائنٹ ٹو پوائنٹ پیغام رسانی کو یکجا کیا ہے۔ موضوع. یہ ان لوگوں کے لیے الجھا ہوا ہے جنہوں نے پیغام رسانی کے نظام کے ساتھ کام کیا ہے، جہاں لفظ "موضوع" سے مراد براڈکاسٹ میکانزم ہے جس سے (موضوع سے) پڑھنا ناقابل برداشت ہے۔ کافکا کے موضوعات کو ایک ہائبرڈ منزل کی قسم سمجھا جانا چاہیے، جیسا کہ اس کتاب کے تعارف میں بیان کیا گیا ہے۔

اس باب کے بقیہ حصے کے لیے، جب تک کہ ہم واضح طور پر دوسری صورت میں بیان نہ کریں، اصطلاح "موضوع" کافکا کے موضوع کا حوالہ دے گی۔

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

اصطلاحات "لاگ" اور "پوائنٹر" ظاہر نہیں ہوتے ہیں۔ کافکا دستاویزات. یہ معروف اصطلاحات کو سمجھنے میں مدد کے لیے یہاں استعمال کیا گیا ہے۔

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

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-1۔ کافکا پارٹیشنز

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

پیغامات پڑھنا

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

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

پڑھنے کا مسئلہ اس طرح بیان کیا جا سکتا ہے:

  • موضوع میں متعدد پارٹیشنز ہیں۔
  • صارفین کے متعدد گروپ ایک ہی وقت میں ایک موضوع استعمال کر سکتے ہیں۔
  • صارفین کے ایک گروپ کی متعدد الگ الگ مثالیں ہوسکتی ہیں۔

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

صارفین اور صارفین کے گروپ

آئیے ایک پارٹیشن کے ساتھ ایک موضوع کو نقطہ آغاز کے طور پر لیتے ہیں (ساخت، پیکر 3-2).

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-2۔ صارف تقسیم سے پڑھتا ہے۔

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

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

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-3۔ مختلف کنزیومر گروپس میں دو صارفین ایک ہی پارٹیشن سے پڑھتے ہیں۔

صارفین کے گروپ میں صارفین

جب ایک صارف مثال کسی پارٹیشن سے ڈیٹا پڑھتا ہے، تو اس کے پاس پوائنٹر کا مکمل کنٹرول ہوتا ہے اور پچھلے حصے میں بیان کردہ پیغامات پر کارروائی کرتا ہے۔
اگر صارفین کی متعدد مثالیں ایک ہی گروپ_آئی ڈی کے ساتھ ایک پارٹیشن کے ساتھ کسی موضوع سے جڑی ہوئی ہیں، تو جو مثال سب سے آخر میں جڑی ہے اسے پوائنٹر پر کنٹرول دیا جائے گا اور اس لمحے سے اسے تمام پیغامات موصول ہوں گے (ساخت، پیکر 3-4).

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-4۔ ایک ہی صارف گروپ کے دو صارفین ایک ہی پارٹیشن سے پڑھتے ہیں۔

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

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

اکثر، جب ہم صارفین کی متعدد مثالیں بناتے ہیں، تو ہم ایسا کرتے ہیں یا تو پیغامات کو متوازی طور پر پروسیس کرنے کے لیے، یا پڑھنے کی رفتار بڑھانے کے لیے، یا پڑھنے کے عمل کے استحکام کو بڑھانے کے لیے۔ چونکہ صرف ایک صارف مثال ایک وقت میں تقسیم سے ڈیٹا پڑھ سکتا ہے، یہ کافکا میں کیسے حاصل ہوتا ہے؟

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

کافکا میں اس مسئلے کو حل کرنے کا روایتی طریقہ b استعمال کرنا ہے۔Оمزید تقسیم.

تقسیم کرنا

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

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-5۔ ایک صارف متعدد پارٹیشنز سے پڑھتا ہے۔

اس منظر نامے میں، صارف کو دونوں پارٹیشنز میں اس کے گروپ_آئی ڈی سے متعلق پوائنٹرز پر کنٹرول دیا جاتا ہے اور وہ دونوں پارٹیشنز سے پیغامات پڑھنا شروع کر دیتا ہے۔
جب اسی گروپ_آئی ڈی کے لیے ایک اضافی صارف کو اس موضوع میں شامل کیا جاتا ہے، تو کافکا پہلے سے دوسرے صارف تک تقسیم میں سے ایک کو دوبارہ مختص کرتا ہے۔ اس کے بعد، صارف کی ہر مثال موضوع کے ایک حصے سے پڑھے گی (ساخت، پیکر 3-6).

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

پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 3۔ کافکا
شکل 3-6۔ ایک ہی صارف گروپ کے دو صارفین مختلف پارٹیشنز سے پڑھتے ہیں۔

یہ اسکیم 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 بروکرز کو بھی ایسی ضروریات سے نمٹنے کی ضرورت ہے۔ دلچسپ بات یہ ہے کہ ایک ہی صارف کو متعلقہ پیغامات بھیجنے کا طریقہ کار، جو 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 میں بحث کی گئی ہے، ہمیں اس بات کو ذہن میں رکھنا چاہیے کہ پیغامات کے کامیابی یا ناکامی سے پروسیس ہونے کے بعد ان کا کیا ہوتا ہے، مثال کے طور پر، اگر کلائنٹ میسج پر کارروائی کرنے سے قاصر ہے یا اگر یہ اسقاط ہو جاتا ہے۔ جے ایم ایس میں، یہ ایک اعتراف موڈ کے ذریعے سنبھالا گیا تھا۔ بروکر یا تو کامیابی کے ساتھ پروسیس شدہ پیغام کو حذف کر دے گا، یا خام یا جعلی پیغام کو دوبارہ ڈیلیور کر دے گا (فرض کریں کہ لین دین استعمال کیا گیا تھا)۔
کافکا بہت مختلف طریقے سے کام کرتا ہے۔ پروف ریڈنگ کے بعد بروکر میں پیغامات کو ڈیلیٹ نہیں کیا جاتا، اور ناکامی پر جو کچھ ہوتا ہے اس کی ذمہ داری خود پروف ریڈنگ کوڈ کی ہوتی ہے۔

جیسا کہ ہم نے کہا، صارف گروپ لاگ میں آفسیٹ سے وابستہ ہے۔ اس آفسیٹ سے وابستہ لاگ پوزیشن اگلے پیغام کے مساوی ہے جس کے جواب میں جاری کیا جائے گا۔ رائے شماری(). وقت کا وہ نقطہ جب یہ آفسیٹ بڑھتا ہے پڑھنے کے لیے فیصلہ کن ہوتا ہے۔

پہلے زیر بحث پڑھنے والے ماڈل پر واپس آتے ہوئے، میسج پروسیسنگ تین مراحل پر مشتمل ہے:

  1. پڑھنے کے لیے ایک پیغام بازیافت کریں۔
  2. پیغام پر کارروائی کریں۔
  3. پیغام کی تصدیق کریں۔

کافکا صارف کنفیگریشن آپشن کے ساتھ آتا ہے۔ enable.auto.commit. یہ اکثر استعمال ہونے والی ڈیفالٹ ترتیب ہے، جیسا کہ لفظ "آٹو" والی ترتیبات میں عام ہے۔

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

کافکا 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(نقشہ ٹائم سٹیمپ تلاش کریں) ماضی میں کسی خاص مقام پر کسی ریاست کی طرف پلٹنا۔

واضح طور پر، اس نقطہ نظر کو استعمال کرنے کا مطلب یہ ہے کہ اس بات کا بہت امکان ہے کہ کچھ پیغامات جن پر پہلے کارروائی کی گئی تھی انہیں دوبارہ پڑھا اور اس پر کارروائی کی جائے گی۔ اس سے بچنے کے لیے، ہم پہلے سے دیکھے گئے پیغامات پر نظر رکھنے اور نقل کو ختم کرنے کے لیے، جیسا کہ باب 4 میں بیان کیا گیا ہے، استعمال کر سکتے ہیں۔

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

ذاتی مشاہدات سے پتہ چلتا ہے کہ جیسے جیسے پیغامات کی شدت بڑھتی ہے، ہر انفرادی پیغام کی قدر کم ہوتی جاتی ہے۔ جب ایک مجموعی شکل میں دیکھا جائے تو بڑے پیغامات قیمتی ہوتے ہیں۔

اچھی فراہمی

اعلیٰ دستیابی کے لیے کافکا کا نقطہ نظر ActiveMQ کے نقطہ نظر سے بہت مختلف ہے۔ کافکا اسکیل آؤٹ کلسٹرز کے ارد گرد ڈیزائن کیا گیا ہے جہاں تمام بروکر مثالیں ایک ہی وقت میں پیغامات وصول اور تقسیم کرتے ہیں۔

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

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

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

بیس کیس میں، کافکا کلسٹر میں مندرجہ ذیل خصوصیات کے ساتھ ایک موضوع بنایا گیا ہے:

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

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

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

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

پروڈیوسر کنفیگریشن کا حصہ پیرامیٹر ہے۔ اکس، جو اس بات کا تعین کرتا ہے کہ ایپلیکیشن تھریڈ کے بھیجے جانے سے پہلے کتنے نقلوں کو کسی پیغام کی وصولی کو تسلیم کرنا چاہیے: 0، 1، یا تمام۔ اگر مقرر کیا گیا ہے۔ تمام، پھر جب کوئی پیغام موصول ہوتا ہے، تو لیڈر جیسے ہی اسے موضوع کی ترتیب کے ذریعہ بیان کردہ متعدد اشاروں (بشمول خود) سے ریکارڈ کی تصدیقات (اعترافات) موصول ہوتے ہی پروڈیوسر کو ایک تصدیق واپس بھیجے گا۔ min.insync.replicas (پہلے سے طے شدہ 1)۔ اگر پیغام کو کامیابی کے ساتھ نقل نہیں کیا جا سکتا ہے، تو پروڈیوسر درخواست کی رعایت پھینک دے گا (NotEnoughReplicas یا NotEnoughReplicasAfterAppend).

ایک عام ترتیب 3 (1 لیڈر، 2 پیروکار فی پارٹیشن) اور پیرامیٹر کے ساتھ ایک موضوع بناتی ہے۔ min.insync.replicas 2 پر سیٹ کیا گیا ہے۔ اس صورت میں، کلسٹر ٹاپک پارٹیشن کا انتظام کرنے والے بروکرز میں سے ایک کو کلائنٹ ایپلی کیشنز کو متاثر کیے بغیر نیچے جانے کی اجازت دے گا۔

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

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

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

ایک کافکا بروکر کے مقابلے میں کافکا کلسٹر میں زیادہ بہتر کارکردگی ممکن ہے، کیونکہ موضوع کی تقسیم بہت سی الگ الگ مشینوں میں پھیل سکتی ہے۔

کے نتائج

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

گزشتہ ترجمہ شدہ حصہ: پیغام بروکرز کو سمجھنا۔ ActiveMQ اور Kafka کے ساتھ پیغام رسانی کی میکانکس سیکھنا۔ باب 1

ترجمہ ہو گیا: tele.gg/middle_java

جاری رکھنا ...

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

کیا آپ کی تنظیم میں کافکا استعمال ہوتا ہے؟

  • جی ہاں

  • کوئی

  • پہلے استعمال کیا جاتا تھا، اب نہیں۔

  • ہم استعمال کرنے کا ارادہ رکھتے ہیں۔

38 صارفین نے ووٹ دیا۔ 8 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں