نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

ارے حبر!

ہم آپ کو یاد دلاتے ہیں کہ کے بارے میں کتاب کے بعد Kafka ہم نے لائبریری کے بارے میں اتنا ہی دلچسپ کام شائع کیا ہے۔ کافکا اسٹریمز API.

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

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

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

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

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

ہم نے کیوں سوچا کہ مشترکہ ریاست کے ساتھ کام کرنے کے طریقے کو تبدیل کرنے کا وقت آگیا ہے۔

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

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

شکل 1: منتقلی سے پہلے دیکھا گیا ایک عام تقسیم ریاست کا منظر
کافکا اور کافکا اسٹریمز: ایجنٹ API کے ذریعے اپنے خیالات کا اظہار کرتے ہیں، تازہ ترین حالت کا حساب مرکزی ڈیٹا بیس کے ذریعے کیا جاتا ہے۔

کافکا اسٹریمز سے ملو، مشترکہ ریاستی مائیکرو سروسز بنانا آسان بناتا ہے۔

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

ہم نے جو اسٹیٹفول مائیکرو سروسز بنائی ہیں ان میں سے ہر ایک کافی آسان ٹوپولوجی کے ساتھ کافکا اسٹریمز کی مثال کے اوپر بنائی گئی تھی۔ یہ 1) ایک ذریعہ 2) ایک پروسیسر پر مشتمل ہے جس میں مستقل کلیدی قدر اسٹور ہے 3) ایک سنک:

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

شکل 2: ریاستی مائیکرو سروسز کے لیے ہماری اسٹریمنگ مثالوں کی ڈیفالٹ ٹوپولوجی۔ نوٹ کریں کہ یہاں ایک ذخیرہ بھی ہے جس میں منصوبہ بندی کا میٹا ڈیٹا ہے۔

اس نئے نقطہ نظر میں، ایجنٹ ایسے پیغامات تحریر کرتے ہیں جو ماخذ کے عنوان میں کھلائے جاتے ہیں، اور صارفین — کہتے ہیں، ایک میل نوٹیفکیشن سروس — سنک (آؤٹ پٹ ٹاپک) کے ذریعے کمپیوٹ شدہ مشترکہ حالت وصول کرتے ہیں۔

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

تصویر 3: مشترکہ مائیکرو سروسز کے ساتھ ایک منظر نامے کے لیے نئی مثال ٹاسک فلو: 1) ایجنٹ ایک پیغام تیار کرتا ہے جو کافکا کے ماخذ موضوع پر پہنچتا ہے۔ 2) مشترکہ حالت کے ساتھ ایک مائیکرو سروس (کافکا اسٹریمز کا استعمال کرتے ہوئے) اس پر کارروائی کرتی ہے اور حساب شدہ حالت کو حتمی کافکا موضوع پر لکھتی ہے۔ جس کے بعد 3) صارفین نئی ریاست کو قبول کرتے ہیں۔

ارے، یہ بلٹ ان کی ویلیو اسٹور دراصل بہت مفید ہے!

جیسا کہ اوپر ذکر کیا گیا ہے، ہماری مشترکہ اسٹیٹ ٹوپولوجی میں کلیدی قدر کی دکان ہے۔ ہمیں اسے استعمال کرنے کے لیے کئی اختیارات ملے، اور ان میں سے دو ذیل میں بیان کیے گئے ہیں۔

آپشن #1: حسابات کے لیے کلیدی قدر کا اسٹور استعمال کریں۔

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

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

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

آپشن #2: کافکا اسٹریمز کے اوپر ایک CRUD API بنانا

اپنے بنیادی کام کے بہاؤ کو قائم کرنے کے بعد، ہم نے اپنی مشترکہ ریاستی مائیکرو سروسز کے لیے ایک RESTful CRUD API لکھنے کی کوشش شروع کی۔ ہم کچھ یا تمام اشیاء کی حالت کو بازیافت کرنے کے ساتھ ساتھ کسی چیز کی حالت کو سیٹ یا ہٹانے کے قابل ہونا چاہتے تھے (بیک اینڈ سپورٹ کے لیے مفید)۔

تمام Get State APIs کو سپورٹ کرنے کے لیے، جب بھی ہمیں پروسیسنگ کے دوران ریاست کی دوبارہ گنتی کرنے کی ضرورت پڑتی ہے، تو ہم نے اسے ایک بلٹ ان کلیدی قدر والے اسٹور میں طویل عرصے تک محفوظ کر لیا تھا۔ اس صورت میں، کافکا اسٹریمز کی ایک مثال کا استعمال کرتے ہوئے اس طرح کے API کو نافذ کرنا کافی آسان ہو جاتا ہے، جیسا کہ ذیل کی فہرست میں دکھایا گیا ہے:

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

شکل 5: کسی شے کی پہلے سے مرتب شدہ حالت کو حاصل کرنے کے لیے بلٹ ان کی ویلیو اسٹور کا استعمال

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

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

شکل 6: آپ کافکا پروڈیوسر کا استعمال کرتے ہوئے کسی چیز کی حالت سیٹ کر سکتے ہیں۔

چھوٹی پیچیدگی: کافکا میں کئی پارٹیشنز ہیں۔

اگلا، ہم پروسیسنگ بوجھ کو تقسیم کرنا چاہتے تھے اور فی منظر نامے میں مشترکہ ریاستی مائیکرو سروسز کا کلسٹر فراہم کرکے دستیابی کو بہتر بنانا چاہتے تھے۔ سیٹ اپ ایک ہوا کا جھونکا تھا: ایک بار جب ہم نے ایک ہی ایپلیکیشن ID (اور ایک ہی بوٹسٹریپ سرورز) کے تحت چلنے کے لیے تمام مثالوں کو ترتیب دیا تو، تقریباً باقی سب کچھ خود بخود ہو گیا۔ ہم نے یہ بھی واضح کیا کہ ہر ماخذ کا موضوع کئی پارٹیشنز پر مشتمل ہوگا، تاکہ ہر مثال کو اس طرح کے پارٹیشنز کا ذیلی سیٹ تفویض کیا جا سکے۔

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

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

نہ صرف پروسیسنگ: ہم نے کافکا اسٹریمز سے تقسیم شدہ ڈیٹا بیس کیسے بنایا، اور اس سے کیا نکلا

شکل 7: سٹریم میٹا ڈیٹا کا استعمال کرتے ہوئے، ہم یہ تعین کرتے ہیں کہ کس مثال سے مطلوبہ چیز کی حالت کے بارے میں استفسار کرنا ہے۔ اسی طرح کا طریقہ GET ALL API کے ساتھ استعمال کیا گیا تھا۔

اہم نتائج

کافکا اسٹریمز میں اسٹیٹ اسٹورز ڈی فیکٹو تقسیم شدہ ڈیٹا بیس کے طور پر کام کر سکتے ہیں،

  • کافکا میں مسلسل نقل کیا جاتا ہے۔
  • ایک CRUD API آسانی سے ایسے سسٹم کے اوپر بنایا جا سکتا ہے۔
  • متعدد پارٹیشنز کو ہینڈل کرنا تھوڑا زیادہ پیچیدہ ہے۔
  • معاون ڈیٹا کو ذخیرہ کرنے کے لیے اسٹریمنگ ٹوپولوجی میں ایک یا زیادہ اسٹیٹ اسٹورز کو شامل کرنا بھی ممکن ہے۔ یہ اختیار اس کے لیے استعمال کیا جا سکتا ہے:
  • سٹریم پروسیسنگ کے دوران حسابات کے لیے درکار ڈیٹا کا طویل مدتی ذخیرہ
  • ڈیٹا کا طویل المدت ذخیرہ جو اگلی بار اسٹریمنگ مثال فراہم کرنے پر مفید ہو سکتا ہے۔
  • بہت زیادہ...

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

ماخذ: www.habr.com

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