یہ کیسے کام کرتا ہے

لاک کا حصول اور واپسی

جب کلائنٹ کوئی کلید حاصل (A) کرتا ہے تو سرور درج ذیل تین میں سے کسی ایک طریقے سے جواب دیتا ہے۔

کلید کی حالت	سرور کا عمل	جواب
رجسٹرڈ نہیں	فوری رجسٹریشن (میعاد = now + lease)، ٹوکن جاری	`A` + token + key
رجسٹرڈ + میعاد گزر چکی	تجدید (now + lease)، نیا ٹوکن جاری	`A` + token + key
رجسٹرڈ + فعال (زیرِ استعمال)	قطار میں شامل، جواب موقوف	واپسی/میعاد ختم ہونے پر `A`، `wait` سے تجاوز پر `T`

واپسی FIFO کے مطابق منصفانہ طریقے سے پروسیس کی جاتی ہے۔ جب حامل (holder) واپس (R) کرتا ہے تو قطار کے سب سے آگے والے کو براہِ راست منتقل کیا جاتا ہے — دوبارہ مقابلے کے بغیر نیا ٹوکن فوراً منتقل ہو جاتا ہے۔
lease ایک حفاظتی جال ہے۔ اگر کلائنٹ ختم ہو جائے یا واپسی بھول جائے، تب بھی lease کا وقت گزرنے کے بعد سرور خودکار طور پر کلید واپس لے کر اگلے منتظر کو دے سکتا ہے۔ اس لیے عام واپسی کے بہاؤ سے الگ، lease کو ہمیشہ کافی مقدار میں، مگر کلائنٹ کے ختم ہونے کی صورت میں زیادہ دیر تک نہ اٹکنے والی قدر پر مقرر کرنا بہتر ہے۔
wait حصول کے انتظار کی حد ہے۔ 0 کی صورت میں لامحدود انتظار، اور اس کے علاوہ اگر اس وقت (سیکنڈز) میں حصول نہ ہو تو سرور ترک کر کے T (ٹائم آؤٹ) کے ساتھ جواب دیتا ہے — چونکہ گرانٹ کے بغیر ختم ہوتا ہے، اس لیے لاک کہیں لیک نہیں ہوتا۔

فینسنگ ٹوکن

A جواب میں شامل token اس گرانٹ کا یکسانی سے بڑھنے والا u64 ہے۔ ہر حصول پر پچھلے کسی بھی ٹوکن سے بڑی قدر جاری کی جاتی ہے۔ فیل اوور ہونے پر بھی نیا ایکٹو بننے والا نوڈ ریپلیکیٹ شدہ سب سے بڑے ٹوکن سے بڑی قدر سے آگے بڑھتا ہے (وراثت) — اس لیے پورے کلسٹر میں بھی ٹوکن مسلسل بڑھتا رہتا ہے۔

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

کلائنٹ کا رویہ

سرکاری کلائنٹس مشترکہ طور پر درج ذیل انداز میں کام کرتے ہیں (زبان کے مطابق تفصیلی API کے لیے لائبریریاں ملاحظہ کریں)۔

ہر پتے کے لیے ایک مستقل کنکشن قائم رکھا جاتا ہے اور بیک گراؤنڈ میں اسے منظم کیا جاتا ہے۔ اگر صرف ایک پتہ دیا جائے تو اندرونی طور پر اسی نوڈ سے دو کنکشن برقرار رکھے جاتے ہیں، تاکہ ان میں سے کوئی ایک عارضی طور پر منقطع ہو جانے پر بھی سروس نہ رکے۔
کنکشن راؤنڈ رابن انداز میں چنا جاتا ہے۔ منقطع ہو جانے والا نوڈ خودکار طور پر خارج کر دیا جاتا ہے، اور ہر 3 سیکنڈ کے وقفے سے بیک گراؤنڈ میں دوبارہ جڑنے کی کوشش کی جاتی ہے۔
درخواستیں پائپ لائن کی جاتی ہیں۔ جواب کا انتظار کیے بغیر اگلی درخواست بھیجی جا سکتی ہے، اور جواب کی ترتیب درخواست کی ترتیب سے مختلف ہو سکتی ہے — کلائنٹ ایکو شدہ (op, key) جوڑے سے پہچانتا ہے کہ جواب کس درخواست کا ہے۔ اگر ایک ہی (op, key) جوڑے کی متعدد درخواستیں ہوں تو وہ بھیجی گئی ترتیب کے مطابق ملائی جاتی ہیں۔
حصول کی کوشش کے دوران کنکشن منقطع ہو جائے تو خودکار طور پر اگلے کنکشن پر منتقل ہو جاتا ہے۔ رجسٹرڈ کنکشنز کی تعداد کے برابر کوششوں کے بعد بھی کوئی کارآمد کنکشن نہ ملے تو تب ہی خرابی کی اطلاع دی جاتی ہے۔
واپسی کی کوشش 5 سیکنڈ تک 200ms کے وقفے سے دہرائی جاتی ہے — تاکہ واپسی کے لمحے اگر کنکشن منقطع ہو تو بھی لاک سرور پر مسلسل باقی نہ رہے (بالآخر lease اسے واپس لے لیتا ہے، مگر اس سے پہلے دوسرے منتظر کو جلد منتقل کرنے کے لیے)۔

کلسٹر — ترجیح پر مبنی بلا تعطل نظام

peers فہرست کی ترتیب ترقی (promotion) کی ترجیح ہے (سب سے آگے سب سے زیادہ ترجیح والا)۔ زندہ نوڈز میں سے سب سے زیادہ ترجیح والا نوڈ ایکٹو بنتا ہے، باقی اس کی حالت حقیقی وقت میں ریپلیکیٹ کرنے والے اسٹینڈ بائی بن جاتے ہیں۔
کلائنٹ کی درخواستیں صرف ایکٹو پروسیس کرتا ہے۔ اسٹینڈ بائی سے جڑنے والے کلائنٹ کو ایکٹو کے پتے کی طرف رہنمائی (M) دی جاتی ہے اور وہ اس طرف منتقل ہو جاتا ہے۔
ایکٹو کی خرابی/ری اسٹارٹ → اسٹینڈ بائی ترقی پا کر اس کی جگہ سنبھالتا ہے۔
مہذب بندش (Ctrl+C) کی صورت میں ایکٹو پہلے جانشین کو ترقی سونپ (ہینڈ آف) کر کے پھر کلائنٹ کو ری ڈائریکٹ کرتا ہے، تاکہ ایکٹو کی غیر موجودگی کم سے کم رہے۔
خودکار ڈیموشن: نیٹ ورک پارٹیشن وغیرہ کی وجہ سے اگر دو نوڈز بیک وقت ایکٹو بن جائیں تو کم ترجیح والا نوڈ دوسرے کو محسوس کر کے خود ہی اسٹینڈ بائی کی حالت میں پیچھے ہٹ جاتا ہے (مستقل اسپلٹ برین سے بچاؤ)۔

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

سرورز کی تعداد	بلا تعطل	بیک وقت خرابی کی برداشت	نوٹ
1	✗	—	سب سے تیز۔ ری اسٹارٹ پر مختصر تعطل واقع ہوتا ہے
2	✓	1	بلا تعطل کی کم از کم ترتیب۔ زیادہ تر صورتوں کے لیے کافی
3	✓	2	ایک نوڈ کی مینٹیننس کے دوران بھی ریڈنڈنسی برقرار رہتی ہے
4+	✓	N−1	صرف پروپیگیشن کی لاگت بڑھتی ہے — تجویز نہیں کیا جاتا

ہم آہنگی (consistency) کے بارے میں جاننے کی باتیں

ترجیح پر مبنی ترقی اتفاقِ رائے نہیں، اس لیے نیٹ ورک پارٹیشن کے لمحے دونوں طرف مختصر وقت کے لیے بیک وقت ایکٹو بن سکتے ہیں، اور غیر ہم وقت ریپلیکیشن کی نوعیت کے باعث فیل اوور کے لمحے کچھ گرانٹس ضائع ہو سکتی ہیں۔ یعنی فیل اوور/پارٹیشن کے دوران باہمی اخراج کی 100% ضمانت نہیں دی جاتی۔ اگر مضبوط ضمانت درکار ہو تو اوپر بیان کردہ فینسنگ ٹوکن کو محفوظ رکھے جانے والے وسیلے سے تصدیق کروائیں — پرانے (چھوٹے) ٹوکن کو مسترد کرنے سے لاک سرور مکمل طور پر یکساں نہ ہونے کے باوجود بھی محفوظ رہتا ہے۔

یہ کیسے کام کرتا ہے ​

لاک کا حصول اور واپسی ​

فینسنگ ٹوکن ​

کلائنٹ کا رویہ ​

کلسٹر — ترجیح پر مبنی بلا تعطل نظام ​