Ticketing Ticketing کیا ہے؟
Ticketing ایک مخصوص لاک سرور ہے جو صرف ایک کام کے لیے ڈیزائن کیا گیا ہے — تقسیم شدہ لاکنگ۔ یہ ایک ہی Rust سرور بائنری ہے جس کے ساتھ سرکاری فی زبان کلائنٹس شامل ہیں جو سب ایک ہی بائنری پروٹوکول کو بائٹ بہ بائٹ نافذ کرتے ہیں۔ صرف دو عملیات — حصول (acquire) اور اجراء (release) — فی کلید FIFO قطار، فینسنگ ٹوکنز، اور ایک اختیاری Raft کلسٹر جسے آپ ضرورت کے وقت آن کرتے ہیں۔ جو کچھ ایک تقسیم شدہ لاک کو درکار ہے وہ سب کچھ، اور اس کے علاوہ کچھ نہیں۔
یہ اسٹور پر بنے لاکس سے کیسے مختلف ہے؟
پروڈکشن میں زیادہ تر تقسیم شدہ لاکس کسی key-value اسٹور کا سہارا لیتے ہیں — Redis کے اوپر Lua اسکرپٹ یا Redlock، یا ZooKeeper یا etcd کے sessions اور leases پر بنا ہوا لاک۔ Redis ایک بہترین اسٹور ہے، لیکن یہ ایک key-value اسٹور ہے جسے تقسیم شدہ لاکنگ کے لیے دوبارہ استعمال کیا گیا ہے، نہ کہ خاص طور پر لاک کے لیے بنایا گیا نظام، اور یہ ساختی اوورہیڈ کی صورت میں سامنے آتا ہے: عمومی مقصد کے پروٹوکول کو پارس کرنے کی لاگت، اور عمومی مقصد کے ڈیٹا اسٹرکچرز کا اوورہیڈ — دونوں ساتھ چلتے ہیں۔
Ticketing کو پہلے دن سے صرف تقسیم شدہ لاکنگ کے لیے ڈیزائن کیا گیا ہے، اس لیے ہر تہہ لاکس کے گرد بنائی گئی ہے۔
- پروٹوکول — فکسڈ چوڑائی کے بائنری فیلڈز، نہ کہ متن اور نہ ہی کوئی عمومی مقصد کی سیریلائزیشن فارمیٹ۔ اقدار بغیر کسی پارسنگ کے براہ راست بائٹ آفسیٹس سے پڑھی جاتی ہیں، اور pipelining کی بدولت آپ پچھلے جواب کا انتظار کیے بغیر اگلی درخواست بھیج سکتے ہیں۔
- سرور کا اندرونی نظام — پوری حالت صرف فی کلید FIFO قطار اور ایک lease ٹائمر پر مشتمل ہے۔ درخواست کا راستہ ہیپ پر allocate تک نہیں کرتا۔
- آپریشنز — ایک سرور بائنری (یا کنٹینر) چلائیں، اسے چند ماحولیاتی متغیرات سے ترتیب دیں، اور کام ختم۔ نہ کسی اسکیما ڈیزائن کی ضرورت، نہ الگ اسٹور کی، نہ لاکنگ سے غیر متعلق کسی آپریشنل معلومات کی۔
کارکردگی
- 10 لاکھ سے زیادہ آپریشنز فی سیکنڈ سنبھالتا ہے جبکہ میموری کا استعمال 10MB سے کم رہتا ہے
Ticketing کیوں
🚦 ترتیب کی سالمیت — FIFO قطار اور براہ راست حوالگی
پہلے آئیں، پہلے پائیں۔ جب حاصل کنندہ لاک جاری کرتا ہے، تو یہ بغیر کسی دوبارہ مقابلے کے براہ راست قطار کے سب سے آگے والے کو منتقل ہو جاتا ہے۔ نہ پولنگ اور دوبارہ کوشش سے پیدا ہونے والی starvation، اور نہ ہی دوبارہ کوشش کے طوفان۔
🛟 مردہ کلائنٹ لاک کو پھنسا نہیں چھوڑتا — lease
اگر لاک رکھنے والا عمل ختم ہو جائے یا اس کا کنکشن ٹوٹ جائے، تو حصول کے وقت مقرر کردہ lease مدت گزرنے کے بعد سرور خودکار طور پر لاک واپس لے کر اگلے منتظر کو دے دیتا ہے۔ اجراء کرنا بھول جانے سے پورا نظام رک نہیں جاتا۔
🔑 ترتیب سے ہٹ کر ہونے والے کام کی روک تھام — فینسنگ ٹوکنز
ایک ناکامی ایسی ہے جسے صرف لاک نہیں روک سکتا: ایک حاصل کنندہ جو دیر سے بیدار ہوتا ہے — یہ جانے بغیر کہ اس کا lease پہلے ہی ختم ہو چکا ہے — اور پھر بھی اپنا کام مکمل کرنے کی درخواست کرتا ہے۔ Ticketing ہر حصول کے ساتھ ایک یکسر بڑھتا ہوا فینسنگ ٹوکن جاری کرتا ہے۔ جب تک محفوظ وسیلہ ایک اصول نافذ کرے — "پہلے دیکھے گئے سے کم کوئی بھی ٹوکن مسترد کریں" — یہ آخری خلا بھی بند ہو جاتا ہے۔ مکمل وضاحت کے لیے یہ کیسے کام کرتا ہے دیکھیں۔
🗳️ Raft پر بنا بلا تعطل کلسٹر
اکیلا سرور خود کافی ہے، لیکن جب آپ کو صفر ٹائم ڈاؤن چاہیے ہو، تو 3 (یا 5) نوڈز کا کلسٹر بنائیں۔ ہر لاک حالت کی تبدیلی صرف اس وقت حتمی ہوتی ہے جب اکثریت نوڈز Raft اتفاقِ رائے کے ذریعے متفق ہوں، اس لیے قائد کے مرنے یا نیٹ ورک کی تقسیم کے باوجود ایک ہی لاک کبھی بیک وقت دو بار جاری نہیں ہوتا۔ اگر قائد ناکام ہو جائے، تو تقریباً ایک سیکنڈ میں نیا قائد منتخب ہو جاتا ہے اور کلائنٹس خودکار طور پر منتقل ہو جاتے ہیں۔ نوڈز کے ایک ایک کر کے بند ہونے کے دوران بھی — مثلاً کلاؤڈ انسٹینس ری بوٹس یا مرحلہ وار دیکھ بھال کے دوران — سروس چلتی رہتی ہے۔
🔒 بلٹ اِن تصدیق اور TLS
ہر کنکشن جڑنے کے فوراً بعد challenge-response ٹوکن تصدیق سے گزرتا ہے، اور ٹوکن کبھی بھی سادہ متن میں وائر پر نہیں بھیجا جاتا۔ جب بھی ضرورت ہو، پورے کنکشن کو TLS سے خفیہ کریں۔
🌐 ہر بڑی زبان میں بائٹ بہ بائٹ ایک ہی پروٹوکول
Rust، Java/Kotlin، JavaScript/TypeScript، Python، C#، Go، Ruby، C/C++ — ہر سرکاری کلائنٹ ایک ہی بائنری پروٹوکول نافذ کرتا ہے، اس زبان کے ایکو سسٹم کے لیے فطری محسوس ہونے والے API (async یا blocking) کے ساتھ۔ کسی بھی زبان سے حاصل کیا گیا لاک کسی بھی دوسری زبان میں لکھے گئے کلائنٹس کے ساتھ منصفانہ طور پر قطار میں لگتا ہے۔ انسٹال کرنے کی ہدایات اور مثالوں کے لیے لائبریریز دیکھیں۔
صرف دو عملیات
ایک خالص لاک سرور کے مطابق، اس کی سطح بھی کم سے کم ہے۔
- جس وسیلے کی حفاظت کرنی ہے اس کے ساتھ ایک کلید منسلک کریں — مثلاً
order-1234,account-77,daily-batch۔ - کام شروع کرنے سے پہلے اس کلید کو حاصل (acquire) کریں — اگر کوئی اور اسے رکھے ہوئے ہے، تو آپ FIFO قطار میں اپنی باری کا انتظار کرتے ہیں۔
- کام مکمل ہونے پر اسے جاری (release) کریں — اگلا منتظر بغیر کسی دوبارہ مقابلے کے فوراً اسے سنبھال لیتا ہے۔
ان دو عملیات کے علاوہ صرف lease (خودکار واپسی) اور waitTimeout (انتظار ترک کرنا) کے اختیارات ہیں — یہی پورا API ہے۔
آگے کیا پڑھیں
- لاکس عملی طور پر کیسے تفویض ہوتے ہیں اور کلسٹر کیسے چلتا رہتا ہے — یہ کیسے کام کرتا ہے
- وائر پر آنے جانے والے بائٹس کی عین وضاحت — پروٹوکول (API)
- سرور رن کمانڈ بنائیں — Ticketing سرور تعیناتی