ماسکو ایکسچینج کے تجارتی اور کلیئرنگ سسٹم کے فن تعمیر کا ارتقاء۔ حصہ 1

سب کو سلام! میرا نام سرگئی کوستان بائیف ہے، ایکسچینج میں میں تجارتی نظام کا بنیادی ڈھانچہ بنا رہا ہوں۔

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

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

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

ایک چھوٹی سی تاریخ

1994 میں، آسٹریلوی ASTS سسٹم ماسکو انٹربینک کرنسی ایکسچینج (MICEX) پر شروع کیا گیا، اور اس لمحے سے الیکٹرانک ٹریڈنگ کی روسی تاریخ کو شمار کیا جا سکتا ہے۔ 1998 میں، انٹرنیٹ ٹریڈنگ کو متعارف کرانے کے لیے ایکسچینج فن تعمیر کو جدید بنایا گیا۔ تب سے، تمام نظاموں اور ذیلی نظاموں میں نئے حل اور تعمیراتی تبدیلیوں کے نفاذ کی رفتار صرف زور پکڑ رہی ہے۔

ان سالوں میں، ایکسچینج سسٹم نے ہائی اینڈ ہارڈ ویئر پر کام کیا - انتہائی قابل اعتماد HP سپرڈوم 9000 سرورز (اس پر بنایا گیا PA-RISC)، جس نے بالکل سب کچھ نقل کیا: ان پٹ/آؤٹ پٹ سب سسٹم، نیٹ ورک، RAM (درحقیقت، RAM کی ایک RAID صف تھی)، پروسیسرز (ہاٹ سویپ ایبل)۔ مشین کو روکے بغیر سرور کے کسی بھی جزو کو تبدیل کرنا ممکن تھا۔ ہم نے ان آلات پر انحصار کیا اور انہیں عملی طور پر ناکامی سے محفوظ سمجھا۔ آپریٹنگ سسٹم یونکس جیسا HP UX سسٹم تھا۔

لیکن تقریباً 2010 کے بعد سے، ایک ایسا رجحان ابھرا ہے جسے ہائی فریکوئنسی ٹریڈنگ (HFT) یا ہائی فریکونسی ٹریڈنگ کہا جاتا ہے - سادہ الفاظ میں اسٹاک ایکسچینج روبوٹ۔ صرف 2,5 سالوں میں، ہمارے سرورز پر بوجھ 140 گنا بڑھ گیا ہے۔

پرانے فن تعمیر اور آلات کے ساتھ اس طرح کے بوجھ کو برداشت کرنا ناممکن تھا۔ اسے کسی نہ کسی طرح اپنانا ضروری تھا۔

شروع

تبادلے کے نظام کی درخواستوں کو دو اقسام میں تقسیم کیا جا سکتا ہے:

• لین دین۔ اگر آپ ڈالر، حصص یا کچھ اور خریدنا چاہتے ہیں، تو آپ ٹریڈنگ سسٹم کو لین دین بھیجتے ہیں اور کامیابی کے بارے میں جواب وصول کرتے ہیں۔
• معلومات کی درخواستیں۔ اگر آپ موجودہ قیمت معلوم کرنا چاہتے ہیں، آرڈر بک یا انڈیکس دیکھیں، پھر معلومات کی درخواستیں بھیجیں۔

اسکیماتی طور پر، نظام کی بنیادی تین سطحوں میں تقسیم کیا جا سکتا ہے:

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

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

آئیے مختصراً اپنے ٹریڈنگ اور کلیئرنگ سسٹم کی ترقی کی تاریخ کو دیکھتے ہیں۔
ٹریڈنگ اور کلیئرنگ سسٹم آرکیٹیکچر کا پہلا ورژن نام نہاد یونکس تعامل پر بنایا گیا تھا: مشترکہ میموری، سیمفورس اور قطاروں کا استعمال کیا گیا تھا، اور ہر عمل ایک ہی دھاگے پر مشتمل تھا۔ یہ نقطہ نظر 1990 کی دہائی کے اوائل میں وسیع تھا۔

سسٹم کے پہلے ورژن میں گیٹ وے کے دو درجے اور تجارتی نظام کا ایک مرکزی سرور تھا۔ کام کا بہاؤ اس طرح تھا:

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

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

چونکہ کوڈ سنگل تھریڈڈ تھا، اس لیے پروسیس فورکس والی ایک کلاسک اسکیم بہت سے کلائنٹس کی خدمت کے لیے استعمال کی گئی۔ تاہم، پورے ڈیٹا بیس کو فورک کرنا بہت مہنگا تھا، اس لیے ہلکے وزن کے سروس پروسیس استعمال کیے گئے جو TCP سیشنز سے پیکٹ اکٹھے کرتے تھے اور انہیں ایک قطار (SystemV Message Queue) میں منتقل کرتے تھے۔ گیٹ وے اور ٹریڈ انجن صرف اس قطار کے ساتھ کام کرتے تھے، وہاں سے لین دین کو عمل میں لاتے تھے۔ اب اس کا جواب بھیجنا ممکن نہیں تھا، کیونکہ یہ واضح نہیں تھا کہ کس سروس کے عمل کو اسے پڑھنا چاہیے۔ اس لیے ہم نے ایک چال کا سہارا لیا: ہر کانٹے دار عمل نے اپنے لیے جوابی قطار بنائی، اور جب کوئی درخواست آنے والی قطار میں آتی ہے، تو جوابی قطار کے لیے ایک ٹیگ فوری طور پر اس میں شامل کر دیا جاتا ہے۔

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

SystemV IPC میں قطار، میموری، اور سیمفور اشیاء کی حالت دیکھنے کے لیے یوٹیلیٹیز شامل ہیں۔ ہم نے اسے فعال طور پر یہ سمجھنے کے لیے استعمال کیا کہ سسٹم میں ایک خاص لمحے میں کیا ہو رہا ہے، جہاں پیکٹ جمع ہوئے، کیا بلاک کیا گیا، وغیرہ۔

پہلی جدید کاری

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

ہائی فریکوئنسی ٹریڈنگ کا اثر

فن تعمیر کا مذکورہ بالا ورژن 2010 تک موجود تھا۔ دریں اثنا، ہم HP سپرڈوم سرورز کی کارکردگی سے مزید مطمئن نہیں تھے۔ اس کے علاوہ، PA-RISC فن تعمیر عملی طور پر مردہ تھا؛ وینڈر نے کوئی اہم اپ ڈیٹ پیش نہیں کیا۔ نتیجے کے طور پر، ہم نے HP UX/PA RISC سے Linux/x86 میں جانا شروع کیا۔ منتقلی کا آغاز رسائی سرورز کی موافقت کے ساتھ ہوا۔

ہمیں دوبارہ فن تعمیر کیوں بدلنا پڑا؟ حقیقت یہ ہے کہ ہائی فریکوئنسی ٹریڈنگ نے سسٹم کور پر لوڈ پروفائل کو نمایاں طور پر تبدیل کر دیا ہے۔

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

اس 50 ایم ایس کے وقفے پر، اوسط رفتار تقریباً 16 ہزار ٹرانزیکشنز فی سیکنڈ ہے۔ اگر ہم ونڈو کو 20 ایم ایس تک کم کرتے ہیں، تو ہمیں 90 ہزار ٹرانزیکشنز فی سیکنڈ کی اوسط رفتار ملتی ہے، جس میں 200 ہزار ٹرانزیکشنز عروج پر ہیں۔ دوسرے الفاظ میں، اچانک پھٹنے کے ساتھ بوجھ مستقل نہیں ہوتا ہے۔ اور درخواستوں کی قطار پر ہمیشہ تیزی سے کارروائی کی جانی چاہیے۔

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

ارتقاء کا ایک نیا دور

وسیع جانچ اور تحقیق کے بعد، ہم نے ریئل ٹائم آپریٹنگ سسٹم کرنل پر سوئچ کیا۔ اس کے لیے ہم نے RedHat Enterprise MRG Linux کا انتخاب کیا، جہاں MRG کا مطلب میسجنگ ریئل ٹائم گرڈ ہے۔ ریئل ٹائم پیچ کا فائدہ یہ ہے کہ وہ نظام کو تیز ترین ممکنہ عمل درآمد کے لیے بہتر بناتے ہیں: تمام عمل ایک FIFO قطار میں کھڑے ہیں، کور کو الگ تھلگ کیا جا سکتا ہے، کوئی اخراج نہیں، تمام لین دین سخت ترتیب میں ہوتے ہیں۔

سرخ - باقاعدہ دانا میں قطار کے ساتھ کام کرنا، سبز - ریئل ٹائم دانا میں کام کرنا۔

لیکن باقاعدہ سرورز پر کم تاخیر کا حصول اتنا آسان نہیں ہے:

• ایس ایم آئی موڈ، جو x86 فن تعمیر میں اہم پیری فیرلز کے ساتھ کام کرنے کی بنیاد ہے، بہت زیادہ مداخلت کرتا ہے۔ تمام قسم کے ہارڈویئر ایونٹس کی پروسیسنگ اور اجزاء اور آلات کا انتظام فرم ویئر کے ذریعے نام نہاد شفاف SMI موڈ میں کیا جاتا ہے، جس میں آپریٹنگ سسٹم یہ نہیں دیکھتا کہ فرم ویئر بالکل کیا کر رہا ہے۔ ایک اصول کے طور پر، تمام بڑے دکاندار فرم ویئر سرورز کے لیے خصوصی ایکسٹینشن پیش کرتے ہیں جو SMI پروسیسنگ کی مقدار کو کم کرنے کی اجازت دیتے ہیں۔
• پروسیسر کی فریکوئنسی کا کوئی متحرک کنٹرول نہیں ہونا چاہیے، اس سے اضافی ڈاؤن ٹائم ہوتا ہے۔
• جب فائل سسٹم لاگ کو فلش کیا جاتا ہے، تو دانا میں کچھ ایسے عمل ہوتے ہیں جو غیر متوقع تاخیر کا سبب بنتے ہیں۔
• آپ کو CPU Affinity، Interrupt affinity، NUMA جیسی چیزوں پر توجہ دینے کی ضرورت ہے۔

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

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

x86 پر سوئچ کرنے کے بعد، کارکردگی تقریباً تین گنا بڑھ گئی، لین دین کا اوسط وقت کم ہو کر 60 μs رہ گیا۔

آئیے اب اس پر گہری نظر ڈالتے ہیں کہ سسٹم کے فن تعمیر میں کیا اہم تبدیلیاں کی گئی ہیں۔

گرم، شہوت انگیز ریزرو مہاکاوی

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

اس کے علاوہ، دیگر ضروریات بھی تھیں:

• کسی بھی حالت میں آپ کو پروسیس شدہ لین دین سے محروم نہیں ہونا چاہئے۔
• نظام کو ہمارے بنیادی ڈھانچے کے لیے بالکل شفاف ہونا چاہیے۔
• گاہکوں کو گرا ہوا کنکشن نہیں دیکھنا چاہئے۔
• ریزرویشنز میں اہم تاخیر نہیں ہونی چاہیے کیونکہ یہ تبادلے کے لیے ایک اہم عنصر ہے۔

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

نتیجے کے طور پر، ہم مندرجہ ذیل اسکیم پر آئے:

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

  

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

اسکیم نے اس طرح کام کیا۔

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

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

جاری رکھنا

ماخذ: www.habr.com