Binance لیجر آپ کے Binance کے تجربے کو کس طرح تقویت فراہم کرتا ہے

اہم نکات

• Binance کا لیجر اکاؤنٹ بیلنسز اور ٹرانزیکشنز کو اسٹور کرتا ہے، نیز ٹرانزیکشنز سرانجام دینے کی سروسز کو بھی فعال کرتا ہے۔

• یہ ایسی صورتحال پیدا ہونے کا باعث بنتا ہے جو بہترین تھروپٹ، 24/7 دستیابی، اور بٹ کی سطح کے ڈیٹا کی درستگی کے لیے درکار ہوتی ہے۔

Binance لیجر کا کردار اسے پسِ پردہ Binance کی بہت ساری اہم ٹیکنالوجیز میں سے ایک بناتا ہے۔ یہ جانیں کہ دراصل یہ کس طرح کام کرتا ہے اور یہاں موجود دنیا بھر کے سب سے بڑے کرپٹو ایکسچینج کی کارروائی میں درپیش مسائل کو کس طرح حل کرتا ہے۔

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

Binance کی تکنیکی کارروائیوں کو تقویت فراہم کرنا اس کا لیجر ہے۔ Binance کا لیجر اکاؤنٹ بیلنسز اور ٹرانزیکشنز کو اسٹور کرتا ہے، نیز ٹرانزیکشنز انجام دینے کے لیے سروسز کو بھی فعال کرتا ہے۔

Binance کے لیجر سے کافی بڑے تقاضے وابستہ ہیں

جیسا کہ آپ یہ سوچ سکتے ہیں کہ کثیر تعداد میں صارفی مانگ کو پورا کرنے کے لیے لیجر سے وابستہ تقاضے کافی زیادہ ہیں۔ اس لیے، یہاں تین اہم نکات موجود ہیں جن پر غور کرنا ضروری ہے:

• مصروف ترین اوقات میں بڑی تعداد میں TPS (ٹرانزیکشنز فی سیکنڈ) سرانجام دینے کی قابلیت رکھنے والا بہترین تھروپٹ۔

• بند ہوئے بغیر 24/7 دستیابی۔

• کسی فنڈ کو کھوئے یا ٹرانزیکشن میں نقائص کے بغیر بٹ کی سطح کے ڈیٹا کی درستگی۔

لیجر پر ایک بنیادی داخلے کی مثال ملاحظہ کریں۔ یہ ایک عام ٹرانزیکشن کی مثال ہے جس میں اکاؤنٹ 1 اکاؤنٹ 2 میں 1 BTC ٹرانسفر کرتا ہے۔

ٹرانزیکشن انجام دینے سے قبل بیلنس:

ٹیبل-1

ٹرانزیکشن انجام دینے کے بعد بیلنس:

ٹیبل-2

اس ٹرانزیکشن میں، دو کمانڈز موجود ہیں:

1. اکاؤنٹ 1    -1 BTC

2. اکاؤنٹ 2   +1 BTC

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

ٹیبل-3

معیاری انڈسٹری کا حل

معیاری انڈسٹری کا لیجر حل متعلقہ ڈیٹا بیس پر مبنی ہے۔ پچھلی مثال کو دہراتے ہوئے، ٹرانزیکشن کی دو کمانڈز کو دو SQL بیانات سے تعبیر کیا جا سکتا ہے اور ڈیٹا بیس کی ٹرانزیکشن کی صورت میں ان پر عمل درآمد کیا جا سکتا ہے (ٹیبل-4)۔

ٹیبل-4

حل کے فوائد

1. اس کا نفاذ خاصا آسان ہے۔

2. ڈیٹا بیس ٹیوننگ کی عام تکانیک کو لاگو کرنا آسان ہے، جیسے مطالعہ کرنے/تحریر کرنے کی تقسیم اور شارڈنگ، تاکہ کارکردگی کو بہتر بنایا جا سکے۔

3. Devops کے لیے فیل اوور سے بازیافتگی، نیز کمرشل ڈیٹا بیس کی نگرانی کرنا اور برقرار رکھنا مشکل کام نہیں ہے۔

حل کے نقصانات

1. قطار کے لاک ہونے کے سبب کارکردگی میں تیزی آںے پر TPS کے عمل میں تیزی سے کمی واقع ہو گی۔

2. کارکردگی کو بہتر بنانے کے لیے افقی طور پر توسیع کرنا مشکل ہے۔

ہاٹ اکاؤںٹ کا مسئلہ

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

جبکہ اس وقت دیگر ٹرانزیکشنز لاک کے ریلیز ہو جانے کا انتظار کرنے کے علاوہ اور کچھ نہیں کر سکتیں۔ ہم اس صورتحال کو ہاٹ اکاؤنٹ کا مسئلہ کہتے ہیں، اور اندرونی ٹیسٹ سے یہ ثابت ہوا کہ اس صورت میں TPS کم از کم 10 گنا کم ہو جائے گا۔ آپ اس مسئلے کو ذیل میں دیے گئے ٹیبل 5 میں ملاحظہ کر سکتے ہیں۔

ہاٹ اکاؤنٹ کی مثال:

ٹیبل-5

Binance کا لیجر حل 

ہم ہاٹ اکاؤنٹ کے مسئلے کو کس طرح سے حل کریں؟

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

نیا تھریڈ ماڈل

پیغام پر مبنی مواصلت

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

پزل میں اگلہ مرحلہ ڈسرپٹر [1] پر مشتمل ہے۔ یہ رِنگ بفر ڈیزائن پر مبنی لاک کے بغیر، اعلٰی کارکردگی کی قطار تشکیل دیتا ہے۔

بہترین دستیابی

اب تک، ہم نے اِن میموری ماڈل اور RocksDB [2] کے مقامی اسٹوریج کا استعمال کرتے ہوئے بہترین کارکردگی حاصل کی ہے۔ لیکن، ایک مرتبہ پھر، ایک نیا چیلنج سامنے آ جاتا ہے۔ اب ہمیں بہترین ڈیٹا کی دستیابی کا خیال رکھنے کی ضرورت ہے۔

نوڈز کے مابین ڈیٹا کے تسلسل کو یقینی بنانے کے لیے، ہم رافت مفاہمتی الگورتھم [3] استعمال کرتے ہیں۔ اس کا مطلب ہے کہ ڈیٹا بیک اپس کی تعداد، اس میں موجود غیر لیڈر نوڈز کی تعداد کے برابر ہے۔ الگورتھم اس بات کو بھی یقینی بناتا ہے کہ سسٹم اب بھی تقریباً کم از کم آدھے تقویت یافتہ نوڈز کے ساتھ کام کرے گا، تاکہ دستیابی کی بہترین سروس فراہم کرنے میں مدد فراہم کر سکے۔

رافٹ ڈومین کے کردار:

• لیڈر۔ لیڈر تمام کلائنٹس کی درخواستوں پر عمل کرتا ہے اور تمام فالوؤرز کے لیے کارروائی کی نقل کرتا ہے۔

• فالوؤر۔ فالوؤرز تمام کارروائیوں کے لیے لیڈر کو فالو کرتے ہیں۔ اگر لیڈر ناکام ہو جاتا ہے، تو فالوؤرز میں سے کوئی ایک شخص نئے لیڈر کی حیثیت سے منتخب کیا جائے گا۔ 

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

رافٹ ڈومین کے کردار

CQRS (کمانڈ اور استفسار کی ذمہ داری کی علیحدگی)

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

لیجر آرکیٹیکچر

مجموعی آرکیٹیکچر

رافٹ اور لیجر کے درمیان تعلقات:

ٹیبل-6

ڈومین کے کردار ملاحظہ کریں

• رافٹ لیجر سینٹر

سیکھنے والوں کی جانب سے جاری کردہ پیغام استعمال کریں اور استفسار کے مقاصد کی خاطر MySQL میں ٹرانزیکشن کو اسٹور کریں اور ڈیٹا کو بیلنس کریں۔

درخواست پر عمل کاری جاری ہے

پہلے ٹرانزیکشن کی درخواست نیٹ ورک لیئر، لیجر لیئر (درخواست ہینڈل کرنے والی)، اور رافٹ لیئر (رافٹ لاگ سنک) کے جائزے کے عمل سے گزرے گی۔ اس کے بعد یہ واپس لیجر لیئر (اسٹیٹ مشین)، نیٹ ورک لیئر (رسپانس ہینڈلر) میں جائے گی، اور بلآخر کلائنٹ کو جواب دے گی۔

ڈیٹا کو دونوں لیئرز کے مابین موجود قطار سے گزارا جاتا ہے۔ 

1. نیٹ ورک لیئر – rpc کی درخواست کو منقسم بناتی ہے اور اسے درخواست کی قطار میں شامل کرتی ہے۔

2. لیجر لیئر – قطار سے درخواست حاصل کرتی ہے اور سیاق و سباق فراہم کرتی ہے۔ جس کے بعد یہ درخواست کے میٹا ڈیٹا کو رافٹ قطار میں شامل کر دے گی۔ 

3. رافٹ لیئر – رافٹ، قطار سے درخواست کا میٹا ڈیٹا حاصل کرتی ہے اور اسے تمام فالوؤرز کے مابین سنک کرتی ہے۔ اس کے بعد یہ نتیجے کو لاگو کرنے والی قطار میں شامل کر دے گی۔

4. لیجر لیئر – لاگو کرنے والی قطار سے ڈیٹا حاصل کرتی ہے اور اسٹیٹ مشین کو اپڈیٹ کرتی ہے۔ اور اس کے بعد نتیجے کو جوابی قطار میں شامل کر دے گی۔

5. نیٹ ورک لیئر – جوابی قطار سے نتیجہ حاصل کرتی ہے اور اسے کلائنٹ کو واپس بھیجنے سے قبل جوابی ڈیٹا تیار کرتی ہے اور اس کو قسط وار انداز میں ترتیب دیتی ہے۔

درخواست پر عمل کاری جاری ہے

ڈیٹا کی بحالی

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

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

اسنیپ شاٹ اور بحالی

نقصان کی گنجائش

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

مکمل کلسٹر کی ناکامی کی صورت میں بھی، جس کا امکان نہایت قلیل ہے، ہم Amazon S3 میں مسلسل اسٹور شدہ اسنیپ شاٹ کے ذریعے کلسٹر کو بحال کریں گے اور تازہ ترین گمشدہ ڈیٹا کو ڈاؤن اسٹریم سسٹم کے ذریعے بازیافت بھی کر سکیں گے۔

نقص کی گنجائش

کارکردگی

درج ذیل ٹیبل کارکردگی کے ٹیسٹ کے لیے ہارڈ ویئر کی خصوصیات ظاہر کرتا ہے

اندرونی ٹیسٹ سے ثابت ہوا کہ (ایک لیڈر، دو فالوؤرز اور ایک سیکھنے والے پر مشتمل) 4-نوڈز کا کلسٹر 10,000 سے زائد TPS پر عمل کاری کر سکتا ہے۔ ڈیزائن کے اعتبار سے، کلسٹر یکے بعد دیگرے تمام ٹرانزیکشنز پر عمل درآمد کرے گا۔ یہاں لاک اور تیزی کی کوئی صورت درپیش نہیں ہے۔ لہٰذا ہاٹ اکاؤنٹ کے منظر نامے میں، TPS کی رفتار اتنی ہی زیادہ ہے جتنی کہ عام منظر ناموں میں ہوتی ہے۔

ہاٹ اکاؤنٹ TPS

درج ذیل تصویر میں ہر ٹرانزیکشن کی تاخیر کو ظاہر کیا گیا ہے۔ بہت سی ٹرانزیکشنز 10 ms کے اندر مکمل ہو سکتی ہیں۔ جبکہ سست رو ٹرانزیکشنز 25ms کے اندر مکمل ہو سکتی ہیں۔

تاخیر ms

Binance لیجر کے ساتھ انڈسٹری کی سربراہی

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

ہماری ٹیکنالوجی پر مبنی انفراسٹرکچر کے متعلق مزید معلومات کے لیے درج ذیل آرٹیکل کا مطالعہ کریں:

• (Binance بلاگ) اصل وقت میں اینڈ ٹو اینڈ مشین لرننگ پائپ لائن تشکیل کرنے کے لیے MLOps کا استعمال

• (Binance بلاگ) CTO سے ملاقات کریں: Rohit کرپٹو، بلاک چین، Web3 اور Binance پر اپنے پہلے مہینے کا جائزہ لیتا ہے 

حوالہ جات

[1] LMAX ڈسرپٹر

[2] RocksDB  

[3] رافٹ مفاہمتی الگورتھم