میرا مشورہ ہے کہ آپ سیریز "ہڈوپ میں ڈیٹا کی بڑی مقدار کی تقسیم شدہ پروسیسنگ کے طریقے" سے لیکچر "Hadoop. ZooKeeper" کا ٹرانسکرپٹ پڑھیں۔
زو کیپر کیا ہے، ہڈوپ ماحولیاتی نظام میں اس کی جگہ۔ تقسیم شدہ کمپیوٹنگ کے بارے میں جھوٹ۔ معیاری تقسیم شدہ نظام کا خاکہ۔ تقسیم شدہ نظام کو مربوط کرنے میں دشواری۔ عام کوآرڈینیشن کے مسائل۔ زو کیپر کے ڈیزائن کے پیچھے اصول۔ زو کیپر ڈیٹا ماڈل۔ znode پرچم. سیشنز۔ کلائنٹ API۔ پرائمیٹوز (کنفیگریشن، گروپ ممبرشپ، سادہ تالے، لیڈر الیکشن، ریوڑ کے اثر کے بغیر تالا لگانا)۔ زو کیپر فن تعمیر۔ زو کیپر ڈی بی۔ ZAB ہینڈلر کی درخواست کریں۔
آج ہم ZooKeeper کے بارے میں بات کریں گے۔ یہ چیز بہت مفید ہے۔ یہ، کسی بھی اپاچی ہڈوپ پروڈکٹ کی طرح، ایک لوگو رکھتا ہے۔ یہ ایک آدمی کی تصویر کشی کرتا ہے۔
اس سے پہلے، ہم نے بنیادی طور پر اس بارے میں بات کی تھی کہ وہاں ڈیٹا کو کیسے پروسیس کیا جا سکتا ہے، اسے کیسے اسٹور کیا جائے، یعنی اسے کسی نہ کسی طریقے سے کیسے استعمال کیا جائے اور کسی نہ کسی طرح اس کے ساتھ کام کیا جائے۔ اور آج میں تقسیم شدہ ایپلی کیشنز کی تعمیر کے بارے میں تھوڑی بات کرنا چاہوں گا۔ اور ZooKeeper ان چیزوں میں سے ایک ہے جو آپ کو اس معاملے کو آسان بنانے کی اجازت دیتی ہے۔ یہ ایک قسم کی خدمت ہے جس کا مقصد تقسیم شدہ ایپلی کیشنز میں تقسیم شدہ نظاموں میں عمل کے تعامل کے کسی قسم کے ہم آہنگی کے لیے ہے۔
اس طرح کی ایپلی کیشنز کی ضرورت روز بروز بڑھتی جا رہی ہے، یہی ہمارا کورس ہے۔ ایک طرف، MapReduce اور یہ ریڈی میڈ فریم ورک آپ کو اس پیچیدگی کو برابر کرنے اور پروگرامر کو ابتدائی تحریروں جیسے کہ عمل کے تعامل اور کوآرڈینیشن سے آزاد کرنے کی اجازت دیتا ہے۔ لیکن دوسری طرف، کوئی بھی اس بات کی گارنٹی نہیں دیتا کہ اسے بہرحال نہیں کرنا پڑے گا۔ MapReduce یا دیگر ریڈی میڈ فریم ورک ہمیشہ کچھ معاملات کو مکمل طور پر تبدیل نہیں کرتے ہیں جو اس کے استعمال سے نافذ نہیں ہوسکتے ہیں۔ بشمول MapReduce اور دیگر اپاچی پروجیکٹس کا ایک گروپ؛ وہ درحقیقت تقسیم شدہ ایپلیکیشنز بھی ہیں۔ اور لکھنے کو آسان بنانے کے لیے انہوں نے ZooKeeper لکھا۔
ہڈوپ سے متعلقہ تمام ایپلی کیشنز کی طرح، اسے Yahoo! اب یہ ایک آفیشل اپاچی ایپلی کیشن بھی ہے۔ یہ HBase کی طرح فعال طور پر تیار نہیں ہے۔ اگر آپ JIRA HBase پر جائیں، تو وہاں ہر روز بگ رپورٹس کا ایک گروپ، کسی چیز کو بہتر بنانے کے لیے تجاویز کا ایک گروپ، یعنی پروجیکٹ میں زندگی مسلسل چل رہی ہے۔ اور ZooKeeper، ایک طرف، نسبتاً سادہ پروڈکٹ ہے، اور دوسری طرف، یہ اس کی وشوسنییتا کو یقینی بناتا ہے۔ اور یہ استعمال کرنا کافی آسان ہے، یہی وجہ ہے کہ یہ Hadoop ماحولیاتی نظام کے اندر ایپلی کیشنز میں ایک معیاری بن گیا ہے۔ اس لیے میں نے سوچا کہ اس کا جائزہ لینا مفید ہو گا تاکہ یہ سمجھ سکیں کہ یہ کیسے کام کرتا ہے اور اسے کیسے استعمال کیا جائے۔
یہ ہمارے کچھ لیکچر کی تصویر ہے۔ ہم کہہ سکتے ہیں کہ یہ ہر اس چیز کے لیے آرتھوگونل ہے جس پر ہم نے اب تک غور کیا ہے۔ اور ہر وہ چیز جو یہاں بتائی گئی ہے، کسی نہ کسی حد تک، ZooKeeper کے ساتھ کام کرتی ہے، یعنی یہ ایک ایسی خدمت ہے جو ان تمام مصنوعات کو استعمال کرتی ہے۔ نہ ہی HDFS اور نہ ہی MapReduce اپنی اسی طرح کی خدمات لکھتے ہیں جو خاص طور پر ان کے لیے کام کرتی ہیں۔ اسی مناسبت سے زو کیپر استعمال کیا جاتا ہے۔ اور یہ ترقی اور غلطیوں سے متعلق کچھ چیزوں کو آسان بناتا ہے۔
یہ سب کہاں سے آتا ہے؟ ایسا لگتا ہے کہ ہم نے مختلف کمپیوٹرز پر متوازی طور پر دو ایپلیکیشنز لانچ کیں، انہیں تار یا میش سے جوڑ دیا، اور سب کچھ کام کرتا ہے۔ لیکن مسئلہ یہ ہے کہ نیٹ ورک ناقابل بھروسہ ہے، اور اگر آپ ٹریفک کو سونگھتے ہیں یا کم سطح پر وہاں کیا ہو رہا ہے، کلائنٹ نیٹ ورک پر کس طرح بات چیت کرتے ہیں، آپ اکثر دیکھ سکتے ہیں کہ کچھ پیکٹ گم ہو گئے ہیں یا دوبارہ بھیجے گئے ہیں۔ یہ کچھ بھی نہیں ہے کہ TCP پروٹوکول ایجاد ہوئے تھے، جو آپ کو ایک مخصوص سیشن قائم کرنے اور پیغامات کی ترسیل کی ضمانت دیتے ہیں۔ لیکن کسی بھی صورت میں، یہاں تک کہ TCP ہمیشہ آپ کو نہیں بچا سکتا۔ ہر چیز کا ایک ٹائم آؤٹ ہوتا ہے۔ نیٹ ورک تھوڑی دیر کے لیے بند ہو سکتا ہے۔ یہ صرف پلک جھپک سکتا ہے۔ اور یہ سب اس حقیقت کی طرف جاتا ہے کہ آپ نیٹ ورک کے قابل اعتماد ہونے پر بھروسہ نہیں کر سکتے۔ یہ متوازی ایپلی کیشنز لکھنے سے بنیادی فرق ہے جو ایک کمپیوٹر یا ایک سپر کمپیوٹر پر چلتی ہیں، جہاں کوئی نیٹ ورک نہیں ہے، جہاں میموری میں ڈیٹا ایکسچینج کی زیادہ قابل اعتماد بس موجود ہے۔ اور یہ ایک بنیادی فرق ہے۔
دوسری چیزوں کے علاوہ، نیٹ ورک استعمال کرتے وقت، ہمیشہ ایک خاص تاخیر ہوتی ہے۔ ڈسک میں بھی یہ ہے، لیکن نیٹ ورک کے پاس اس سے زیادہ ہے۔ لیٹنسی کچھ تاخیر کا وقت ہے، جو یا تو چھوٹا یا کافی اہم ہو سکتا ہے۔
نیٹ ورک ٹوپولوجی بدل رہی ہے۔ ٹوپولوجی کیا ہے - یہ ہمارے نیٹ ورک کے سامان کی جگہ کا تعین ہے۔ ڈیٹا سینٹرز ہیں، ریک ہیں جو وہاں کھڑے ہیں، موم بتیاں ہیں. یہ سب کچھ دوبارہ منسلک کیا جا سکتا ہے، منتقل کیا جا سکتا ہے، وغیرہ۔ اس سب کو بھی مدنظر رکھنے کی ضرورت ہے۔ IP نام تبدیل ہوتے ہیں، وہ روٹنگ جس کے ذریعے ہمارا ٹریفک سفر کرتا ہے۔ اس بات کو بھی مدنظر رکھنے کی ضرورت ہے۔
نیٹ ورک سامان کے لحاظ سے بھی بدل سکتا ہے۔ پریکٹس سے، میں کہہ سکتا ہوں کہ ہمارے نیٹ ورک انجینئرز موم بتیوں پر وقتاً فوقتاً کچھ اپ ڈیٹ کرنا پسند کرتے ہیں۔ اچانک ایک نیا فرم ویئر سامنے آیا اور وہ کچھ ہڈوپ کلسٹر میں خاص طور پر دلچسپی نہیں رکھتے تھے۔ ان کا اپنا کام ہے۔ ان کے لیے اہم بات یہ ہے کہ نیٹ ورک کام کرتا ہے۔ اس کے مطابق، وہ وہاں کسی چیز کو دوبارہ اپ لوڈ کرنا چاہتے ہیں، اپنے ہارڈ ویئر پر فلیشنگ کرنا چاہتے ہیں، اور ہارڈ ویئر بھی وقتاً فوقتاً تبدیل ہوتا رہتا ہے۔ یہ سب کچھ کسی نہ کسی طرح اکاؤنٹ میں لینے کی ضرورت ہے. یہ سب ہماری تقسیم شدہ درخواست کو متاثر کرتا ہے۔
عام طور پر جو لوگ کسی وجہ سے بڑی مقدار میں ڈیٹا کے ساتھ کام کرنا شروع کرتے ہیں وہ سمجھتے ہیں کہ انٹرنیٹ لامحدود ہے۔ اگر وہاں کئی ٹیرا بائٹس کی فائل موجود ہے تو آپ اسے اپنے سرور یا کمپیوٹر پر لے جا کر اسے کھول سکتے ہیں۔ بلی اور دیکھو. ایک اور غلطی اس میں ہے۔ طاقت نوشتہ جات کو دیکھو. ایسا کبھی نہ کریں کیونکہ یہ برا ہے۔ چونکہ Vim ہر چیز کو بفر کرنے کی کوشش کرتا ہے، ہر چیز کو میموری میں لوڈ کرتا ہے، خاص طور پر جب ہم اس لاگ سے گزرنا شروع کرتے ہیں اور کچھ تلاش کرتے ہیں۔ یہ وہ چیزیں ہیں جو بھولی ہوئی ہیں، لیکن قابل غور ہیں۔
ایک پروگرام لکھنا آسان ہے جو ایک کمپیوٹر پر ایک پروسیسر کے ساتھ چلتا ہے۔
جب ہمارا نظام بڑھتا ہے، تو ہم ان سب کو متوازی بنانا چاہتے ہیں، اور اسے نہ صرف کمپیوٹر پر بلکہ ایک کلسٹر پر بھی متوازی بنانا چاہتے ہیں۔ سوال یہ پیدا ہوتا ہے کہ اس معاملے کو کیسے مربوط کیا جائے؟ ہماری ایپلی کیشنز ایک دوسرے کے ساتھ تعامل بھی نہیں کر سکتیں، لیکن ہم نے متعدد سرورز پر متوازی طور پر کئی عمل چلائے۔ اور یہ کیسے مانیٹر کیا جائے کہ ان کے لیے سب کچھ ٹھیک چل رہا ہے؟ مثال کے طور پر، وہ انٹرنیٹ پر کچھ بھیجتے ہیں۔ وہ اپنی حالت کے بارے میں کہیں لکھیں، مثال کے طور پر، کسی قسم کے ڈیٹا بیس یا لاگ میں، پھر اس لاگ کو جمع کریں اور پھر کہیں اس کا تجزیہ کریں۔ اس کے علاوہ، ہمیں اس بات کو مدنظر رکھنا ہوگا کہ یہ عمل کام کر رہا تھا اور کام کر رہا تھا، اچانک اس میں کوئی خرابی نمودار ہو گئی یا وہ کریش ہو گیا، پھر ہمیں اس کا پتہ کتنی جلدی ہو گا؟
یہ واضح ہے کہ اس سب پر تیزی سے نگرانی کی جا سکتی ہے۔ یہ بھی اچھی بات ہے، لیکن نگرانی ایک محدود چیز ہے جو آپ کو اعلیٰ سطح پر کچھ چیزوں کی نگرانی کرنے کی اجازت دیتی ہے۔
جب ہم چاہتے ہیں کہ ہمارے عمل ایک دوسرے کے ساتھ تعامل شروع کریں، مثال کے طور پر، ایک دوسرے کو کچھ ڈیٹا بھیجنا، تو سوال یہ بھی پیدا ہوتا ہے کہ یہ کیسے ہوگا؟ کیا وہاں کسی قسم کی نسل کی حالت ہوگی، کیا وہ ایک دوسرے کو اوور رائٹ کریں گے، کیا ڈیٹا صحیح طریقے سے پہنچے گا، کیا راستے میں کچھ ضائع ہو جائے گا؟ ہمیں کسی قسم کا پروٹوکول وغیرہ تیار کرنے کی ضرورت ہے۔
ان تمام عملوں کا ربط کوئی معمولی بات نہیں۔ اور یہ ڈویلپر کو اس سے بھی نچلی سطح پر جانے پر مجبور کرتا ہے، اور سسٹم کو یا تو شروع سے لکھتا ہے، یا بالکل شروع سے نہیں، لیکن یہ اتنا آسان نہیں ہے۔
اگر آپ ایک کرپٹوگرافک الگورتھم لے کر آتے ہیں یا اسے لاگو بھی کرتے ہیں، تو اسے فوراً پھینک دیں، کیونکہ غالب امکان ہے کہ یہ آپ کے لیے کام نہیں کرے گا۔ اس میں غالباً غلطیوں کا ایک گروپ ہوگا جو آپ فراہم کرنا بھول گئے تھے۔ اسے کبھی بھی کسی سنگین چیز کے لیے استعمال نہ کریں کیونکہ یہ زیادہ تر ممکنہ طور پر غیر مستحکم ہوگا۔ کیونکہ تمام الگورتھم جو موجود ہیں ان کا تجربہ وقت نے بہت طویل عرصے سے کیا ہے۔ یہ کمیونٹی کی طرف سے bugged ہے. یہ ایک الگ موضوع ہے۔ اور یہاں بھی ایسا ہی ہے۔ اگر یہ ممکن ہے کہ کسی قسم کے عمل کی مطابقت پذیری کو خود نافذ نہ کیا جائے، تو بہتر ہے کہ ایسا نہ کیا جائے، کیونکہ یہ کافی پیچیدہ ہے اور آپ کو مسلسل غلطیوں کی تلاش کے متزلزل راستے پر لے جاتا ہے۔
آج ہم ZooKeeper کے بارے میں بات کر رہے ہیں۔ ایک طرف، یہ ایک فریم ورک ہے، دوسری طرف، یہ ایک ایسی خدمت ہے جو ڈویلپر کے لیے زندگی کو آسان بناتی ہے اور منطق کے نفاذ کو آسان بناتی ہے اور ہمارے عمل کے ہم آہنگی کو ہر ممکن حد تک آسان بناتی ہے۔
آئیے یاد رکھیں کہ معیاری تقسیم شدہ نظام کیسا نظر آتا ہے۔ یہ وہی ہے جس کے بارے میں ہم نے بات کی تھی - HDFS، HBase۔ ایک ماسٹر عمل ہے جو کارکنوں اور غلاموں کے عمل کو منظم کرتا ہے۔ وہ کاموں کو مربوط کرنے اور تقسیم کرنے، کارکنوں کو دوبارہ شروع کرنے، نئے شروع کرنے، اور بوجھ کی تقسیم کا ذمہ دار ہے۔
ایک زیادہ جدید چیز کوآرڈینیشن سروس ہے، یعنی کوآرڈینیشن ٹاسک کو خود ایک الگ عمل میں منتقل کریں، نیز کسی قسم کا بیک اپ یا سٹینبی ماسٹر کو متوازی طور پر چلائیں، کیونکہ ماسٹر ناکام ہو سکتا ہے۔ اور اگر ماسٹر گر جائے گا تو ہمارا سسٹم نہیں چلے گا۔ ہم بیک اپ چلا رہے ہیں۔ کچھ بیانات ہیں کہ ماسٹر کو بیک اپ میں نقل کرنے کی ضرورت ہے۔ یہ کوآرڈینیشن سروس کو بھی سونپا جا سکتا ہے۔ لیکن اس خاکہ میں، ماسٹر خود کارکنوں کو مربوط کرنے کا ذمہ دار ہے؛ یہاں سروس ڈیٹا کی نقل کی سرگرمیوں کو مربوط کر رہی ہے۔
ایک زیادہ جدید آپشن وہ ہوتا ہے جب تمام کوآرڈینیشن ہماری سروس کے ذریعے سنبھالا جاتا ہے، جیسا کہ عام طور پر کیا جاتا ہے۔ وہ اس بات کو یقینی بنانے کی ذمہ داری لیتا ہے کہ ہر چیز کام کرتی ہے۔ اور اگر کچھ کام نہیں کرتا ہے، تو ہم اس کے بارے میں تلاش کرتے ہیں اور اس صورت حال کو حل کرنے کی کوشش کرتے ہیں. بہر حال، ہمارے پاس ایک آقا رہ گیا ہے جو کسی نہ کسی طرح غلاموں کے ساتھ بات چیت کرتا ہے اور کسی سروس کے ذریعے ڈیٹا، معلومات، پیغامات وغیرہ بھیج سکتا ہے۔
اس سے بھی زیادہ جدید اسکیم ہے، جب ہمارے پاس ماسٹر نہیں ہے، تمام نوڈس ماسٹر غلام ہیں، ان کے رویے میں مختلف ہیں۔ لیکن انہیں اب بھی ایک دوسرے کے ساتھ بات چیت کرنے کی ضرورت ہے، لہذا ان کارروائیوں کو مربوط کرنے کے لیے ابھی بھی کچھ خدمت باقی ہے۔ شاید، کیسینڈرا، جو اس اصول پر کام کرتی ہے، اس اسکیم میں فٹ بیٹھتی ہے۔
یہ کہنا مشکل ہے کہ ان میں سے کون سی اسکیم بہتر کام کرتی ہے۔ ہر ایک کے اپنے فوائد اور نقصانات ہیں۔
اور ماسٹر کے ساتھ کچھ چیزوں سے ڈرنے کی ضرورت نہیں ہے، کیونکہ جیسا کہ پریکٹس سے پتہ چلتا ہے، وہ مسلسل خدمت کرنے کے لیے اتنا حساس نہیں ہے۔ یہاں سب سے اہم بات یہ ہے کہ اس سروس کو ایک علیحدہ طاقتور نوڈ پر ہوسٹ کرنے کے لیے صحیح حل کا انتخاب کیا جائے، تاکہ اس کے پاس کافی وسائل ہوں، تاکہ اگر ممکن ہو تو صارفین کو وہاں تک رسائی حاصل نہ ہو، تاکہ وہ غلطی سے اس عمل کو ختم نہ کر دیں۔ لیکن ساتھ ہی، ایسی اسکیم میں ماسٹر پروسیس سے ورکرز کا انتظام کرنا بہت آسان ہے، یعنی یہ اسکیم نفاذ کے نقطہ نظر سے آسان ہے۔
اور یہ سکیم (اوپر) شاید زیادہ پیچیدہ، لیکن زیادہ قابل اعتماد ہے۔
بنیادی مسئلہ جزوی ناکامی ہے۔ مثال کے طور پر، جب ہم نیٹ ورک پر کوئی پیغام بھیجتے ہیں، تو کسی قسم کا حادثہ پیش آتا ہے، اور جس نے پیغام بھیجا تھا، اسے یہ نہیں معلوم ہو گا کہ آیا اس کا پیغام موصول ہوا تھا اور وصول کنندہ کی طرف کیا ہوا تھا، یہ نہیں معلوم ہو گا کہ آیا پیغام پر صحیح طریقے سے کارروائی ہوئی تھی یا نہیں۔ ، یعنی اسے کوئی تصدیق نہیں ملے گی۔
اس کے مطابق، ہمیں اس صورت حال پر عملدرآمد کرنا ہوگا. اور سب سے آسان بات یہ ہے کہ اس پیغام کو دوبارہ بھیجیں اور ہمیں جواب موصول ہونے تک انتظار کریں۔ اس معاملے میں، اس بات کو مدنظر نہیں رکھا جاتا ہے کہ آیا وصول کنندہ کی حالت بدل گئی ہے۔ ہم ایک پیغام بھیج سکتے ہیں اور ایک ہی ڈیٹا کو دو بار شامل کر سکتے ہیں۔
ZooKeeper ایسے انکار سے نمٹنے کے طریقے پیش کرتا ہے، جو ہماری زندگی کو بھی آسان بناتا ہے۔
جیسا کہ تھوڑا پہلے ذکر کیا گیا ہے، یہ ملٹی تھریڈڈ پروگرام لکھنے کے مترادف ہے، لیکن بنیادی فرق یہ ہے کہ تقسیم شدہ ایپلی کیشنز میں جو ہم مختلف مشینوں پر بناتے ہیں، بات چیت کا واحد طریقہ نیٹ ورک ہے۔ بنیادی طور پر، یہ ایک مشترکہ فن تعمیر ہے۔ ایک مشین پر چلنے والے ہر عمل یا سروس کی اپنی میموری، اپنی ڈسک، اپنا پروسیسر ہوتا ہے، جسے وہ کسی کے ساتھ شیئر نہیں کرتا۔
اگر ہم ایک کمپیوٹر پر ملٹی تھریڈڈ پروگرام لکھتے ہیں، تو ہم ڈیٹا کے تبادلے کے لیے مشترکہ میموری استعمال کر سکتے ہیں۔ ہمارے پاس وہاں ایک سیاق و سباق کا سوئچ ہے، عمل بدل سکتے ہیں۔ اس سے کارکردگی متاثر ہوتی ہے۔ ایک طرف، کلسٹر پر پروگرام میں ایسی کوئی چیز نہیں ہے، لیکن نیٹ ورک کے ساتھ مسائل ہیں.
اس کے مطابق، تقسیم شدہ نظام لکھتے وقت پیدا ہونے والے اہم مسائل کنفیگریشن ہیں۔ ہم کسی قسم کی درخواست لکھ رہے ہیں۔ اگر یہ آسان ہے، تو ہم کوڈ میں ہر طرح کے نمبروں کو ہارڈ کوڈ کرتے ہیں، لیکن یہ تکلیف دہ ہے، کیونکہ اگر ہم یہ فیصلہ کرتے ہیں کہ آدھے سیکنڈ کے ٹائم آؤٹ کے بجائے ہمیں ایک سیکنڈ کا ٹائم آؤٹ چاہیے، تو ہمیں ایپلی کیشن کو دوبارہ کمپائل کرنے کی ضرورت ہے اور ہر چیز کو دوبارہ رول کریں. یہ ایک چیز ہے جب یہ ایک مشین پر ہوتی ہے، جب آپ اسے دوبارہ شروع کر سکتے ہیں، لیکن جب ہمارے پاس بہت سی مشینیں ہوتی ہیں، تو ہمیں ہر چیز کو مسلسل کاپی کرنا پڑتا ہے۔ ہمیں درخواست کو قابل ترتیب بنانے کی کوشش کرنی چاہیے۔
یہاں ہم نظام کے عمل کے لیے جامد ترتیب کے بارے میں بات کر رہے ہیں۔ یہ مکمل طور پر نہیں ہے، ہو سکتا ہے کہ آپریٹنگ سسٹم کے نقطہ نظر سے، یہ ہمارے عمل کے لیے ایک جامد ترتیب ہو، یعنی یہ ایک ایسی ترتیب ہے جسے آسانی سے لیا اور اپ ڈیٹ نہیں کیا جا سکتا۔
ایک متحرک ترتیب بھی ہے۔ یہ وہ پیرامیٹرز ہیں جنہیں ہم فلائی پر تبدیل کرنا چاہتے ہیں تاکہ انہیں وہاں اٹھایا جائے۔
یہاں کیا مسئلہ ہے؟ ہم نے تشکیل کو اپ ڈیٹ کیا، اسے رول آؤٹ کیا، تو کیا؟ مسئلہ یہ ہو سکتا ہے کہ ایک طرف ہم نے کنفیگریشن کو رول آؤٹ کیا، لیکن نئی چیز کو بھول گئے، کنفگ وہیں رہ گئی۔ دوم، جب ہم رول آؤٹ کر رہے تھے، کچھ جگہوں پر کنفیگریشن کو اپ ڈیٹ کیا گیا تھا، لیکن دوسروں میں نہیں۔ اور ہماری ایپلی کیشن کے کچھ پراسیس جو ایک مشین پر چلتے ہیں ایک نئی کنفیگریشن کے ساتھ دوبارہ شروع کیے گئے اور کہیں پرانی کے ساتھ۔ اس کے نتیجے میں ہماری تقسیم شدہ درخواست کنفیگریشن کے نقطہ نظر سے متضاد ہو سکتی ہے۔ یہ مسئلہ عام ہے۔ متحرک کنفیگریشن کے لیے، یہ زیادہ متعلقہ ہے کیونکہ اس کا مطلب ہے کہ اسے فلائی پر تبدیل کیا جا سکتا ہے۔
ایک اور مسئلہ گروپ کی رکنیت ہے۔ ہمارے پاس ہمیشہ کچھ کارکن ہوتے ہیں، ہم ہمیشہ یہ جاننا چاہتے ہیں کہ ان میں سے کون زندہ ہے، کون مر چکا ہے۔ اگر کوئی ماسٹر ہے، تو اسے یہ سمجھنا چاہیے کہ کن ورکرز کو کلائنٹس کی طرف ری ڈائریکٹ کیا جا سکتا ہے تاکہ وہ حسابات چلائیں یا ڈیٹا کے ساتھ کام کریں، اور کون سے نہیں۔ ایک مسئلہ جو مسلسل پیدا ہوتا ہے وہ یہ ہے کہ ہمیں یہ جاننے کی ضرورت ہے کہ ہمارے کلسٹر میں کون کام کر رہا ہے۔
ایک اور عام مسئلہ لیڈر الیکشن ہے، جب ہم جاننا چاہتے ہیں کہ انچارج کون ہے۔ ایک مثال نقل ہے، جب ہمارے پاس کچھ ایسا عمل ہوتا ہے جو تحریری کارروائیوں کو حاصل کرتا ہے اور پھر انہیں دوسرے عمل کے درمیان نقل کرتا ہے۔ وہ رہنما ہوگا، باقی سب اس کی اطاعت کریں گے، اس کی پیروی کریں گے۔ ایک عمل کا انتخاب کرنا ضروری ہے تاکہ یہ سب کے لیے غیر مبہم ہو، تاکہ یہ نہ نکلے کہ دو رہنما منتخب کیے گئے ہیں۔
باہمی خصوصی رسائی بھی ہے۔ یہاں مسئلہ زیادہ پیچیدہ ہے۔ ایک mutex کے طور پر ایک ایسی چیز ہے، جب آپ ملٹی تھریڈڈ پروگرام لکھتے ہیں اور کسی وسائل تک رسائی چاہتے ہیں، مثال کے طور پر، ایک میموری سیل، محدود اور صرف ایک دھاگے سے چلایا جائے۔ یہاں وسیلہ کچھ اور خلاصہ ہوسکتا ہے۔ اور ہمارے نیٹ ورک کے مختلف نوڈس سے مختلف ایپلی کیشنز کو صرف ایک دیئے گئے وسائل تک خصوصی رسائی حاصل ہونی چاہیے، اور ایسا نہیں کہ ہر کوئی اسے تبدیل کر سکے یا وہاں کچھ لکھ سکے۔ یہ نام نہاد تالے ہیں۔
زو کیپر آپ کو ان تمام مسائل کو کسی نہ کسی حد تک حل کرنے کی اجازت دیتا ہے۔ اور میں مثالوں کے ساتھ دکھاؤں گا کہ یہ آپ کو ایسا کرنے کی اجازت کیسے دیتا ہے۔
کوئی مسدود کرنے والی قدیم چیزیں نہیں ہیں۔ جب ہم کسی چیز کو استعمال کرنا شروع کرتے ہیں تو یہ قدیم کسی بھی واقعے کے رونما ہونے کا انتظار نہیں کرے گا۔ زیادہ تر امکان ہے کہ، یہ چیز متضاد طور پر کام کرے گی، اس طرح عمل کو کسی چیز کا انتظار کرتے وقت لٹکنے کی اجازت نہیں ملے گی۔ یہ بہت مفید چیز ہے۔
کلائنٹ کی تمام درخواستوں پر عام قطار کی ترتیب میں کارروائی کی جاتی ہے۔
اور کلائنٹ کو موقع ملتا ہے کہ وہ کسی حالت میں ہونے والی تبدیلیوں کے بارے میں، ڈیٹا میں ہونے والی تبدیلیوں کے بارے میں، اس سے پہلے کہ کلائنٹ خود تبدیل شدہ ڈیٹا کو دیکھے۔
زو کیپر دو طریقوں میں کام کر سکتا ہے۔ پہلا ایک نوڈ پر اسٹینڈ اسٹون ہے۔ یہ جانچ کے لیے آسان ہے۔ یہ کسی بھی سرورز پر کلسٹر موڈ میں بھی کام کر سکتا ہے۔ اگر ہمارے پاس 100 مشینوں کا کلسٹر ہے تو اس کے لیے 100 مشینوں پر کام کرنا ضروری نہیں ہے۔ کئی مشینوں کو منتخب کرنا کافی ہے جہاں آپ ZooKeeper چلا سکتے ہیں۔ اور یہ اعلی دستیابی کے اصول کا دعویٰ کرتا ہے۔ ہر چلنے والی مثال پر، ZooKeeper ڈیٹا کی ایک پوری کاپی اسٹور کرتا ہے۔ بعد میں میں آپ کو بتاؤں گا کہ وہ یہ کیسے کرتا ہے۔ یہ ڈیٹا کو شارڈ یا تقسیم نہیں کرتا ہے۔ ایک طرف، یہ مائنس ہے کہ ہم زیادہ ذخیرہ نہیں کر سکتے، دوسری طرف، ایسا کرنے کی ضرورت نہیں ہے۔ یہ اس کے لیے ڈیزائن نہیں کیا گیا ہے، یہ ڈیٹا بیس نہیں ہے۔
ڈیٹا کلائنٹ کی طرف سے محفوظ کیا جا سکتا ہے. یہ ایک معیاری اصول ہے تاکہ ہم سروس میں خلل نہ ڈالیں اور اسے ایک جیسی درخواستوں کے ساتھ لوڈ نہ کریں۔ ایک ہوشیار کلائنٹ عام طور پر اس کے بارے میں جانتا ہے اور اسے کیش کرتا ہے۔
مثال کے طور پر، یہاں کچھ بدل گیا ہے۔ ایک قسم کی درخواست ہے۔ ایک نیا رہنما منتخب کیا گیا، جو ذمہ دار ہے، مثال کے طور پر، تحریری کارروائیوں کی کارروائی کے لیے۔ اور ہم ڈیٹا کو نقل کرنا چاہتے ہیں۔ ایک حل یہ ہے کہ اسے لوپ میں ڈال دیا جائے۔ اور ہم اپنی سروس سے مسلسل سوال کرتے ہیں - کیا کچھ بدلا ہے؟ دوسرا آپشن زیادہ بہترین ہے۔ یہ گھڑی کا ایک طریقہ کار ہے جو آپ کو کلائنٹس کو مطلع کرنے کی اجازت دیتا ہے کہ کچھ بدل گیا ہے۔ وسائل کے لحاظ سے یہ ایک کم مہنگا طریقہ ہے اور گاہکوں کے لیے زیادہ آسان ہے۔
کلائنٹ وہ صارف ہے جو زو کیپر استعمال کرتا ہے۔
سرور خود ZooKeeper عمل ہے۔
Znode ZooKeeper میں کلیدی چیز ہے۔ تمام زنوڈز کو زو کیپر کے ذریعہ میموری میں محفوظ کیا جاتا ہے اور ایک درخت کی شکل میں درجہ بندی کے خاکے کی شکل میں ترتیب دیا جاتا ہے۔
آپریشن کی دو قسمیں ہیں۔ پہلا اپ ڈیٹ/لکھنا ہے، جب کچھ آپریشن ہمارے درخت کی حالت کو بدل دیتا ہے۔ درخت عام ہے۔
اور یہ ممکن ہے کہ کلائنٹ ایک درخواست مکمل نہ کرے اور منقطع ہو جائے، لیکن وہ ایک سیشن قائم کر سکتا ہے جس کے ذریعے وہ ZooKeeper کے ساتھ بات چیت کرتا ہے۔
زو کیپر کا ڈیٹا ماڈل فائل سسٹم سے ملتا جلتا ہے۔ ایک معیاری جڑ ہے اور پھر ہم اس طرح گئے جیسے ڈائریکٹریز کے ذریعے جو جڑ سے جاتی ہیں۔ اور پھر پہلی سطح، دوسری سطح کا کیٹلاگ۔ یہ سب znodes ہے.
ہر znode کچھ ڈیٹا محفوظ کر سکتا ہے، عام طور پر بہت بڑا نہیں ہوتا، مثال کے طور پر، 10 کلو بائٹس۔ اور ہر znode میں بچوں کی ایک مخصوص تعداد ہو سکتی ہے۔
Znodes کئی اقسام میں آتے ہیں. وہ بنائے جا سکتے ہیں۔ اور زنوڈ بناتے وقت، ہم اس قسم کی وضاحت کرتے ہیں جس سے اس کا تعلق ہونا چاہیے۔
دو قسمیں ہیں۔ پہلا عارضی پرچم ہے۔ Znode ایک سیشن کے اندر رہتا ہے۔ مثال کے طور پر، کلائنٹ نے ایک سیشن قائم کیا ہے۔ اور جب تک یہ سیشن زندہ ہے، یہ موجود رہے گا۔ یہ ضروری ہے تاکہ کوئی غیر ضروری چیز پیدا نہ ہو۔ یہ ان لمحات کے لیے بھی موزوں ہے جب ہمارے لیے ایک سیشن کے اندر ڈیٹا پرائمیٹو کو اسٹور کرنا ضروری ہوتا ہے۔
دوسری قسم ترتیب وار جھنڈا ہے۔ یہ زنوڈ کے راستے میں کاؤنٹر کو بڑھاتا ہے۔ مثال کے طور پر، ہمارے پاس ایپلیکیشن 1_5 والی ڈائرکٹری تھی۔ اور جب ہم نے پہلا نوڈ بنایا تو اسے p_1 موصول ہوا، دوسرا - p_2۔ اور جب ہم ہر بار اس طریقہ کو کال کرتے ہیں، تو ہم پورے راستے سے گزرتے ہیں، راستے کے صرف ایک حصے کی نشاندہی کرتے ہوئے، اور یہ نمبر خود بخود بڑھ جاتا ہے کیونکہ ہم نوڈ کی قسم - ترتیب وار کی نشاندہی کرتے ہیں۔
باقاعدہ znode. وہ ہمیشہ زندہ رہے گی اور وہی نام رکھے گا جو ہم اسے بتاتے ہیں۔
ایک اور مفید چیز گھڑی کا جھنڈا ہے۔ اگر ہم اسے انسٹال کرتے ہیں، تو کلائنٹ ایک مخصوص نوڈ کے لیے کچھ ایونٹس کو سبسکرائب کر سکتا ہے۔ میں آپ کو بعد میں ایک مثال کے ساتھ دکھاؤں گا کہ یہ کیسے ہوتا ہے۔ زو کیپر خود کلائنٹ کو مطلع کرتا ہے کہ نوڈ پر ڈیٹا تبدیل ہو گیا ہے۔ تاہم، اطلاعات اس بات کی ضمانت نہیں دیتی ہیں کہ کچھ نیا ڈیٹا آیا ہے۔ وہ صرف یہ کہتے ہیں کہ کچھ بدل گیا ہے، لہذا آپ کو اب بھی بعد میں ڈیٹا کا الگ الگ کالوں سے موازنہ کرنا ہوگا۔
اور جیسا کہ میں پہلے ہی کہہ چکا ہوں، ڈیٹا کی ترتیب کلو بائٹس سے طے ہوتی ہے۔ وہاں بڑے ٹیکسٹ ڈیٹا کو ذخیرہ کرنے کی ضرورت نہیں ہے، کیونکہ یہ ڈیٹا بیس نہیں ہے، یہ ایک ایکشن کوآرڈینیشن سرور ہے۔
میں آپ کو سیشن کے بارے میں تھوڑا سا بتاؤں گا۔ اگر ہمارے پاس ایک سے زیادہ سرور ہیں، تو ہم سیشن شناخت کنندہ کا استعمال کرتے ہوئے شفاف طریقے سے سرور سے سرور تک جا سکتے ہیں۔ یہ کافی آسان ہے۔
ہر سیشن کا کوئی نہ کوئی ٹائم آؤٹ ہوتا ہے۔ ایک سیشن کی تعریف اس سے ہوتی ہے کہ آیا کلائنٹ اس سیشن کے دوران سرور کو کچھ بھیجتا ہے۔ اگر اس نے ٹائم آؤٹ کے دوران کچھ بھی منتقل نہیں کیا، تو سیشن بند ہو جائے گا، یا کلائنٹ خود اسے بند کر سکتا ہے۔
اس میں اتنی زیادہ خصوصیات نہیں ہیں، لیکن آپ اس API کے ساتھ مختلف چیزیں کر سکتے ہیں۔ جو کال ہم نے تخلیق کو دیکھا وہ ایک زنوڈ بناتی ہے اور تین پیرامیٹرز لیتی ہے۔ یہ زنوڈ کا راستہ ہے، اور اسے جڑ سے مکمل طور پر بیان کیا جانا چاہیے۔ اور یہ بھی کچھ ڈیٹا ہے جسے ہم وہاں منتقل کرنا چاہتے ہیں۔ اور جھنڈے کی قسم۔ اور تخلیق کے بعد یہ znode کا راستہ لوٹاتا ہے۔
دوسرا، آپ اسے حذف کر سکتے ہیں۔ یہاں چال یہ ہے کہ دوسرا پیرامیٹر، znode کے راستے کے علاوہ، ورژن کی وضاحت کرسکتا ہے۔ اس کے مطابق، اس znode کو حذف کر دیا جائے گا اگر اس کا جو ورژن ہم نے منتقل کیا ہے وہ اصل میں موجود کے برابر ہے۔
اگر ہم اس ورژن کی جانچ نہیں کرنا چاہتے ہیں، تو ہم صرف "-1" دلیل کو پاس کرتے ہیں۔
تیسرا، یہ زنوڈ کے وجود کی جانچ کرتا ہے۔ اگر نوڈ موجود ہے تو صحیح لوٹاتا ہے، ورنہ غلط۔
اور پھر پرچم گھڑی ظاہر ہوتی ہے، جو آپ کو اس نوڈ کی نگرانی کرنے کی اجازت دیتی ہے۔
آپ اس جھنڈے کو غیر موجود نوڈ پر بھی سیٹ کر سکتے ہیں اور اس کے ظاہر ہونے پر ایک اطلاع موصول کر سکتے ہیں۔ یہ بھی مفید ہو سکتا ہے۔
ایک دو اور چیلنجز ہیں۔ ڈیٹا حاصل کریں۔. یہ واضح ہے کہ ہم znode کے ذریعے ڈیٹا حاصل کر سکتے ہیں۔ آپ پرچم گھڑی بھی استعمال کرسکتے ہیں۔ اس صورت میں، اگر کوئی نوڈ نہیں ہے تو یہ انسٹال نہیں ہوگا۔ لہذا، آپ کو یہ سمجھنے کی ضرورت ہے کہ یہ موجود ہے، اور پھر ڈیٹا حاصل کریں۔
وہاں بھی ہے ڈیٹا سیٹ کریں۔. یہاں ہم ورژن پاس کرتے ہیں۔ اور اگر ہم اسے آگے بڑھاتے ہیں، تو ایک مخصوص ورژن کے زنوڈ پر ڈیٹا اپ ڈیٹ ہو جائے گا۔
اس چیک کو خارج کرنے کے لیے آپ "-1" کی بھی وضاحت کر سکتے ہیں۔
ایک اور مفید طریقہ ہے۔ بچے حاصل کریں. ہم ان تمام znodes کی فہرست بھی حاصل کر سکتے ہیں جو اس سے تعلق رکھتے ہیں۔ ہم پرچم گھڑی ترتیب دے کر اس کی نگرانی کر سکتے ہیں۔
اور طریقہ مطابقت پذیر تمام تبدیلیوں کو ایک ساتھ بھیجنے کی اجازت دیتا ہے، اس طرح یہ یقینی بناتا ہے کہ وہ محفوظ ہیں اور تمام ڈیٹا کو مکمل طور پر تبدیل کر دیا گیا ہے۔
اگر ہم باقاعدہ پروگرامنگ کے ساتھ مشابہتیں کھینچتے ہیں، تو جب آپ لکھنے جیسے طریقے استعمال کرتے ہیں، جو ڈسک پر کچھ لکھتے ہیں، اور اس کے بعد آپ کو جواب آتا ہے، تو اس بات کی کوئی ضمانت نہیں ہے کہ آپ نے ڈیٹا کو ڈسک پر لکھا ہے۔ اور یہاں تک کہ جب آپریٹنگ سسٹم کو یقین ہو کہ سب کچھ لکھا جا چکا ہے، خود ڈسک میں ایسے میکانزم موجود ہیں جہاں یہ عمل بفر کی تہوں سے گزرتا ہے، اور اس کے بعد ہی ڈیٹا کو ڈسک پر رکھا جاتا ہے۔
زیادہ تر غیر مطابقت پذیر کالیں استعمال ہوتی ہیں۔ یہ کلائنٹ کو مختلف درخواستوں کے ساتھ متوازی طور پر کام کرنے کی اجازت دیتا ہے۔ آپ ہم وقت ساز طریقہ استعمال کر سکتے ہیں، لیکن یہ کم نتیجہ خیز ہے۔
ہم نے جن دو آپریشنز کے بارے میں بات کی ہے وہ ہیں اپ ڈیٹ/لکھنا، جو ڈیٹا کو تبدیل کرتے ہیں۔ یہ تخلیق، سیٹ ڈیٹا، مطابقت پذیری، حذف ہیں. اور پڑھنا موجود ہے، getData، getChildren۔
اب چند مثالیں کہ آپ تقسیم شدہ نظام میں کام کرنے کے لیے پرائمیٹو کیسے بنا سکتے ہیں۔ مثال کے طور پر، کسی چیز کی ترتیب سے متعلق۔ ایک نیا کارکن سامنے آیا ہے۔ ہم نے مشین کو شامل کیا اور عمل شروع کیا۔ اور مندرجہ ذیل تین سوالات ہیں۔ یہ کنفیگریشن کے لیے ZooKeeper سے کیسے استفسار کرتا ہے؟ اور اگر ہم کنفیگریشن کو تبدیل کرنا چاہتے ہیں تو ہم اسے کیسے تبدیل کریں گے؟ اور ہم نے اسے تبدیل کرنے کے بعد، وہ کارکنوں کو کیسے ملے گا جو ہم نے اسے حاصل کیا تھا؟
زو کیپر اسے نسبتاً آسان بنا دیتا ہے۔ مثال کے طور پر، ہمارے znode درخت ہے. یہاں ہماری ایپلی کیشن کے لیے ایک نوڈ ہے، ہم اس میں ایک اضافی نوڈ بناتے ہیں، جس میں کنفیگریشن کا ڈیٹا ہوتا ہے۔ یہ الگ الگ پیرامیٹرز ہو سکتے ہیں یا نہیں۔ چونکہ سائز چھوٹا ہے، ترتیب کا سائز عام طور پر چھوٹا ہوتا ہے، لہذا اسے یہاں ذخیرہ کرنا کافی ممکن ہے۔
آپ طریقہ استعمال کر رہے ہیں۔ ڈیٹا حاصل کریں۔ نوڈ سے کارکن کے لیے کنفیگریشن حاصل کرنے کے لیے۔ سچ پر سیٹ کریں۔ اگر کسی وجہ سے یہ نوڈ موجود نہیں ہے، تو ہمیں اس کے ظاہر ہونے پر، یا اس میں تبدیلی آنے پر اس کے بارے میں مطلع کیا جائے گا۔ اگر ہم یہ جاننا چاہتے ہیں کہ کچھ بدل گیا ہے، تو ہم اسے درست کر دیتے ہیں۔ اور اگر اس نوڈ میں ڈیٹا تبدیل ہوتا ہے تو ہم اس کے بارے میں جان لیں گے۔
ڈیٹا سیٹ کریں۔. ہم ڈیٹا سیٹ کرتے ہیں، "-1" سیٹ کرتے ہیں، یعنی ہم ورژن کو چیک نہیں کرتے، ہم فرض کرتے ہیں کہ ہمارے پاس ہمیشہ ایک کنفیگریشن ہے، ہمیں بہت سی کنفیگریشنز کو ذخیرہ کرنے کی ضرورت نہیں ہے۔ اگر آپ کو بہت زیادہ ذخیرہ کرنے کی ضرورت ہے، تو آپ کو ایک اور سطح شامل کرنے کی ضرورت ہوگی۔ یہاں ہمیں یقین ہے کہ صرف ایک ہے، لہذا ہم صرف تازہ ترین کو اپ ڈیٹ کرتے ہیں، لہذا ہم ورژن کو چیک نہیں کرتے ہیں۔ اس وقت، تمام کلائنٹس جنہوں نے پہلے سبسکرائب کیا ہے ایک اطلاع موصول ہوتی ہے کہ اس نوڈ میں کچھ بدل گیا ہے۔ اور اسے موصول ہونے کے بعد، انہیں دوبارہ ڈیٹا کی درخواست بھی کرنی ہوگی۔ نوٹیفکیشن یہ ہے کہ وہ خود ڈیٹا وصول نہیں کرتے ہیں، لیکن صرف تبدیلیوں کی اطلاع ہے۔ اس کے بعد انہیں نیا ڈیٹا طلب کرنا ہوگا۔
قدیم استعمال کرنے کا دوسرا آپشن ہے۔ گروپ کی رکنیت. ہمارے پاس ایک تقسیم شدہ درخواست ہے، کارکنوں کا ایک گروپ ہے اور ہم یہ سمجھنا چاہتے ہیں کہ وہ سب اپنی جگہ پر ہیں۔ لہذا، انہیں خود کو رجسٹر کرنا ہوگا کہ وہ ہماری درخواست میں کام کرتے ہیں۔ اور ہم یہ بھی جاننا چاہتے ہیں، یا تو ماسٹر پروسیس سے یا کہیں اور، ان تمام فعال کارکنوں کے بارے میں جو ہمارے پاس موجود ہیں۔
ہم یہ کیسے کرتے ہیں؟ ایپلیکیشن کے لیے، ہم ورکرز نوڈ بناتے ہیں اور تخلیق کا طریقہ استعمال کرتے ہوئے وہاں ایک ذیلی سطح شامل کرتے ہیں۔ مجھے سلائیڈ پر ایک خرابی ہے۔ یہاں آپ کی ضرورت ہے ترتیب وضاحت کریں، پھر تمام کارکن ایک ایک کر کے بنائے جائیں گے۔ اور ایپلیکیشن، اس نوڈ کے بچوں کے بارے میں تمام ڈیٹا کی درخواست کرتی ہے، موجود تمام فعال کارکنوں کو موصول کرتی ہے۔
یہ جاوا کوڈ میں کیسے کیا جا سکتا ہے اس کا اتنا خوفناک نفاذ ہے۔ آئیے آخر سے شروع کرتے ہیں، مرکزی طریقہ کے ساتھ۔ یہ ہماری کلاس ہے، آئیے اس کا طریقہ بنائیں۔ پہلی دلیل کے طور پر ہم میزبان کا استعمال کرتے ہیں، جہاں ہم جڑ رہے ہیں، یعنی ہم اسے ایک دلیل کے طور پر سیٹ کرتے ہیں۔ اور دوسری دلیل گروہ کا نام ہے۔
کنکشن کیسے ہوتا ہے؟ یہ API کی ایک سادہ سی مثال ہے جسے استعمال کیا جاتا ہے۔ یہاں سب کچھ نسبتاً آسان ہے۔ ایک معیاری کلاس زو کیپر ہے۔ ہم میزبانوں کو اس میں منتقل کرتے ہیں۔ اور ٹائم آؤٹ، مثال کے طور پر، 5 سیکنڈ پر سیٹ کریں۔ اور ہمارے پاس ایک ممبر ہے جسے کنیکٹڈ سگنل کہتے ہیں۔ بنیادی طور پر، ہم منتقلی کے راستے پر ایک گروپ بناتے ہیں۔ ہم وہاں ڈیٹا نہیں لکھتے، حالانکہ کچھ لکھا جا سکتا تھا۔ اور یہاں نوڈ مستقل قسم کا ہے۔ بنیادی طور پر، یہ ایک عام باقاعدہ نوڈ ہے جو ہر وقت موجود رہے گا۔ یہ وہ جگہ ہے جہاں سیشن بنتا ہے۔ یہ خود کلائنٹ کا نفاذ ہے۔ ہمارا کلائنٹ وقتاً فوقتاً پیغامات بھیجے گا کہ سیشن زندہ ہے۔ اور جب ہم سیشن ختم کرتے ہیں، ہم بند کو کہتے ہیں اور بس، سیشن ختم ہو جاتا ہے۔ ایسا اس صورت میں ہوتا ہے جب ہمارے لیے کوئی چیز گر جائے، تاکہ زو کیپر کو اس کے بارے میں پتہ چل جائے اور سیشن منقطع کر دیا جائے۔
وسائل کو کیسے بند کیا جائے؟ یہاں سب کچھ تھوڑا زیادہ پیچیدہ ہے. ہمارے پاس کارکنوں کا ایک سیٹ ہے، کچھ وسیلہ ہے جسے ہم بند کرنا چاہتے ہیں۔ ایسا کرنے کے لیے، ہم ایک علیحدہ نوڈ بناتے ہیں، مثال کے طور پر، جسے lock1 کہتے ہیں۔ اگر ہم اسے بنانے کے قابل تھے، تو ہمیں یہاں ایک تالا ملا۔ اور اگر ہم اسے بنانے سے قاصر تھے، تو کارکن یہاں سے ڈیٹا حاصل کرنے کی کوشش کرتا ہے، اور چونکہ نوڈ پہلے ہی بن چکا ہے، تو ہم یہاں ایک واچر لگاتے ہیں اور جس لمحے اس نوڈ کی حالت بدل جاتی ہے، ہمیں اس کے بارے میں پتہ چل جائے گا۔ اور ہم اسے دوبارہ بنانے کے لیے وقت حاصل کرنے کی کوشش کر سکتے ہیں۔ اگر ہم نے یہ نوڈ لیا، یہ لاک لیا، پھر جب ہمیں اس تالے کی ضرورت نہیں رہے گی، تو ہم اسے چھوڑ دیں گے، کیونکہ نوڈ صرف سیشن کے اندر موجود ہے۔ اس کے مطابق، یہ غائب ہو جائے گا. اور ایک اور کلائنٹ، دوسرے سیشن کے فریم ورک کے اندر، اس نوڈ پر لاک لینے کے قابل ہو جائے گا، یا اس کے بجائے، اسے ایک اطلاع ملے گی کہ کچھ بدل گیا ہے اور وہ اسے وقت پر کرنے کی کوشش کر سکتا ہے۔
آپ مرکزی رہنما کا انتخاب کیسے کر سکتے ہیں اس کی ایک اور مثال۔ یہ تھوڑا زیادہ پیچیدہ ہے، لیکن نسبتا آسان بھی ہے. یہاں کیا ہو رہا ہے؟ ایک اہم نوڈ ہے جو تمام کارکنوں کو جمع کرتا ہے۔ ہم لیڈر کے بارے میں ڈیٹا حاصل کرنے کی کوشش کر رہے ہیں۔ اگر یہ کامیابی سے ہوا، یعنی ہمیں کچھ ڈیٹا موصول ہوا، تو ہمارا کارکن اس لیڈر کی پیروی کرنا شروع کر دیتا ہے۔ اس کا خیال ہے کہ پہلے ہی ایک لیڈر موجود ہے۔
اگر لیڈر کسی وجہ سے مر گیا، مثلاً گر گیا، تو ہم ایک نیا لیڈر بنانے کی کوشش کرتے ہیں۔ اور اگر ہم کامیاب ہوتے ہیں تو ہمارا کارکن لیڈر بن جاتا ہے۔ اور اگر اس وقت کوئی نیا لیڈر بنانے میں کامیاب ہو گیا تو ہم یہ سمجھنے کی کوشش کرتے ہیں کہ یہ کون ہے اور پھر اس کی پیروی کریں۔
یہاں نام نہاد ہرڈ ایفیکٹ پیدا ہوتا ہے، یعنی ہرڈ ایفیکٹ، کیونکہ جب کوئی لیڈر مرتا ہے تو وہی لیڈر بن جاتا ہے جو وقت پر سب سے پہلے ہوتا ہے۔
کسی وسائل پر قبضہ کرتے وقت، آپ تھوڑا سا مختلف طریقہ استعمال کرنے کی کوشش کر سکتے ہیں، جو کہ درج ذیل ہے۔ مثال کے طور پر، ہم ایک تالا حاصل کرنا چاہتے ہیں، لیکن ہرٹ اثر کے بغیر. یہ اس حقیقت پر مشتمل ہوگا کہ ہماری ایپلیکیشن لاک کے ساتھ پہلے سے موجود نوڈ کے لیے تمام نوڈ آئی ڈیز کی فہرست کی درخواست کرتی ہے۔ اور اگر اس سے پہلے جس نوڈ کے لیے ہم نے تالا بنایا تھا وہ اس سیٹ میں سے سب سے چھوٹا ہے جو ہمیں موصول ہوا ہے، تو اس کا مطلب ہے کہ ہم نے لاک کو پکڑ لیا ہے۔ ہم چیک کرتے ہیں کہ ہمیں ایک تالا ملا ہے۔ چیک کے طور پر، یہ شرط ہوگی کہ نیا لاک بناتے وقت ہمیں جو آئی ڈی موصول ہوئی وہ کم سے کم ہو۔ اور اگر ہمیں مل گیا تو ہم مزید کام کرتے ہیں۔
اگر کوئی مخصوص آئی ڈی ہے جو ہمارے لاک سے چھوٹی ہے، تو ہم اس ایونٹ پر ایک واچر لگاتے ہیں اور کچھ تبدیل ہونے تک اطلاع کا انتظار کرتے ہیں۔ یعنی ہمیں یہ تالا ملا۔ اور جب تک یہ گر نہیں جاتا، ہم کم از کم آئی ڈی نہیں بنیں گے اور کم از کم لاک وصول نہیں کریں گے، اور اس طرح ہم لاگ ان کر سکیں گے۔ اور اگر یہ شرط پوری نہ ہوئی تو ہم فوراً یہاں جاتے ہیں اور اس تالے کو دوبارہ حاصل کرنے کی کوشش کرتے ہیں، کیونکہ اس دوران کچھ بدل گیا ہو گا۔
زو کیپر کس چیز پر مشتمل ہے؟ 4 اہم چیزیں ہیں۔ یہ پروسیسنگ عمل ہے - درخواست۔ اور زو کیپر اٹامک براڈکاسٹ بھی۔ ایک کمٹ لاگ ہے جہاں تمام کارروائیوں کو ریکارڈ کیا جاتا ہے۔ اور ان میموری کی نقل شدہ ڈی بی خود، یعنی خود ڈیٹا بیس جہاں یہ پورا درخت محفوظ ہے۔
یہ بات قابل غور ہے کہ تمام تحریری کارروائیاں درخواست پروسیسر کے ذریعے ہوتی ہیں۔ اور پڑھنے کی کارروائیاں براہ راست ان میموری ڈیٹا بیس پر جاتی ہیں۔
ڈیٹا بیس خود مکمل طور پر نقل کیا گیا ہے۔ ZooKeeper کی تمام مثالیں ڈیٹا کی مکمل کاپی محفوظ کرتی ہیں۔
کریش کے بعد ڈیٹا بیس کو بحال کرنے کے لیے، ایک کمٹ لاگ ہے۔ معیاری پریکٹس یہ ہے کہ ڈیٹا کے میموری میں آنے سے پہلے اسے وہاں لکھا جاتا ہے تاکہ اگر یہ کریش ہو جائے تو اس لاگ کو دوبارہ چلایا جا سکتا ہے اور سسٹم کی حالت کو بحال کیا جا سکتا ہے۔ اور ڈیٹا بیس کے متواتر سنیپ شاٹس بھی استعمال کیے جاتے ہیں۔
ZooKeeper Atomic Broadcast ایک ایسی چیز ہے جو نقل شدہ ڈیٹا کو برقرار رکھنے کے لیے استعمال ہوتی ہے۔
ZAB اندرونی طور پر ZooKeeper نوڈ کے نقطہ نظر سے لیڈر کا انتخاب کرتا ہے۔ دوسرے نوڈس اس کے پیروکار بن جاتے ہیں اور اس سے کچھ اقدامات کی توقع کرتے ہیں۔ اگر وہ اندراجات وصول کرتے ہیں، تو وہ ان سب کو لیڈر کے پاس بھیج دیتے ہیں۔ وہ پہلے تحریری آپریشن کرتا ہے اور پھر اس کے پیروکاروں کو کیا تبدیلی آئی ہے اس کے بارے میں پیغام بھیجتا ہے۔ یہ، درحقیقت، جوہری طور پر انجام دیا جانا چاہیے، یعنی پوری چیز کی ریکارڈنگ اور نشریات کو جوہری طور پر انجام دیا جانا چاہیے، اس طرح ڈیٹا کی مستقل مزاجی کی ضمانت ہوتی ہے۔
یہ صرف تحریری درخواستوں پر کارروائی کرتا ہے۔ اس کا بنیادی کام یہ ہے کہ یہ آپریشن کو ٹرانزیکشنل اپ ڈیٹ میں تبدیل کرتا ہے۔ یہ خصوصی طور پر تیار کردہ درخواست ہے۔
اور یہاں یہ بات قابل غور ہے کہ اسی آپریشن کے لیے اپ ڈیٹس کی idempotency کی ضمانت دی جاتی ہے۔ یہ کیا ہے؟ یہ چیز، اگر دو بار پھانسی دی جائے تو، ایک ہی حالت ہوگی، یعنی درخواست خود نہیں بدلے گی۔ اور ایسا کرنے کی ضرورت ہے تاکہ حادثے کی صورت میں، آپ آپریشن کو دوبارہ شروع کر سکیں، اس طرح اس وقت گرنے والی تبدیلیوں کو واپس لے سکیں۔ اس صورت میں، نظام کی حالت ایک جیسی ہو جائے گی، یعنی ایسا نہیں ہونا چاہیے کہ ایک ہی سلسلہ، مثال کے طور پر، اپ ڈیٹ کے عمل، نظام کی مختلف حتمی حالتوں کا باعث بنے۔
ماخذ: www.habr.com