मॉस्को एक्सचेंज की व्यापार और समाशोधन प्रणाली की वास्तुकला का विकास। भाग ---- पहला

नमस्ते! मेरा नाम सर्गेई कोस्तानबायेव है, एक्सचेंज में मैं ट्रेडिंग सिस्टम का मूल विकसित कर रहा हूं।

जब हॉलीवुड फिल्में न्यूयॉर्क स्टॉक एक्सचेंज को दिखाती हैं, तो यह हमेशा ऐसा दिखता है: लोगों की भीड़, हर कोई कुछ न कुछ चिल्ला रहा है, कागजात लहरा रहा है, पूरी तरह से अराजकता हो रही है। मॉस्को एक्सचेंज में ऐसा कभी नहीं हुआ, क्योंकि कारोबार शुरू से ही इलेक्ट्रॉनिक रूप से किया जाता रहा है और यह दो मुख्य प्लेटफार्मों - स्पेक्ट्रा (विदेशी मुद्रा बाजार) और एएसटीएस (विदेशी मुद्रा, स्टॉक और मुद्रा बाजार) पर आधारित है। और आज मैं एएसटीएस व्यापार और समाशोधन प्रणाली की वास्तुकला के विकास, विभिन्न समाधानों और निष्कर्षों के बारे में बात करना चाहता हूं। कहानी लंबी होगी इसलिए मुझे इसे दो हिस्सों में तोड़ना पड़ा.

हम दुनिया के कुछ एक्सचेंजों में से एक हैं जो सभी वर्गों की संपत्तियों का व्यापार करते हैं और एक्सचेंज सेवाओं की पूरी श्रृंखला प्रदान करते हैं। उदाहरण के लिए, पिछले साल हम बांड ट्रेडिंग वॉल्यूम के मामले में दुनिया में दूसरे स्थान पर थे, सभी स्टॉक एक्सचेंजों में 25वें स्थान पर थे, सार्वजनिक एक्सचेंजों में पूंजीकरण में 13वें स्थान पर थे।

पेशेवर व्यापारिक प्रतिभागियों के लिए, प्रतिक्रिया समय, समय वितरण की स्थिरता (घबराना) और पूरे परिसर की विश्वसनीयता जैसे पैरामीटर महत्वपूर्ण हैं। वर्तमान में हम प्रतिदिन लाखों लेनदेन संसाधित करते हैं। सिस्टम कर्नेल द्वारा प्रत्येक लेनदेन की प्रोसेसिंग में दसियों माइक्रोसेकंड लगते हैं। बेशक, नए साल की पूर्व संध्या पर मोबाइल ऑपरेटरों या खोज इंजनों पर हमारे मुकाबले अधिक कार्यभार होता है, लेकिन कार्यभार के संदर्भ में, उपर्युक्त विशेषताओं के साथ, कुछ ही लोग हमारी तुलना कर सकते हैं, ऐसा मुझे लगता है। साथ ही, हमारे लिए यह महत्वपूर्ण है कि सिस्टम एक सेकंड के लिए भी धीमा न हो, बिल्कुल स्थिर रूप से काम करे और सभी उपयोगकर्ता समान स्तर पर हों।

थोड़ा इतिहास

1994 में, ऑस्ट्रेलियाई ASTS प्रणाली को मॉस्को इंटरबैंक करेंसी एक्सचेंज (MICEX) पर लॉन्च किया गया था, और उसी क्षण से इलेक्ट्रॉनिक ट्रेडिंग के रूसी इतिहास को गिना जा सकता है। 1998 में, इंटरनेट ट्रेडिंग शुरू करने के लिए एक्सचेंज आर्किटेक्चर का आधुनिकीकरण किया गया था। तब से, सभी प्रणालियों और उपप्रणालियों में नए समाधानों और वास्तुशिल्प परिवर्तनों के कार्यान्वयन की गति केवल गति पकड़ रही है।

उन वर्षों में, एक्सचेंज सिस्टम हाई-एंड हार्डवेयर - अल्ट्रा-विश्वसनीय एचपी सुपरडोम 9000 सर्वर (पर निर्मित) पर काम करता था पीए-रिस्क), जिसमें बिल्कुल सब कुछ डुप्लिकेट किया गया था: इनपुट/आउटपुट सबसिस्टम, नेटवर्क, रैम (वास्तव में, रैम की एक RAID सरणी थी), प्रोसेसर (हॉट-स्वैपेबल)। मशीन को रोके बिना किसी भी सर्वर घटक को बदलना संभव था। हमने इन उपकरणों पर भरोसा किया और उन्हें वस्तुतः असफल-सुरक्षित माना। ऑपरेटिंग सिस्टम यूनिक्स जैसा एचपी यूएक्स सिस्टम था।

लेकिन लगभग 2010 के बाद से, एक घटना सामने आई है जिसे हाई-फ़्रीक्वेंसी ट्रेडिंग (HFT), या हाई-फ़्रीक्वेंसी ट्रेडिंग - सीधे शब्दों में कहें तो स्टॉक एक्सचेंज रोबोट कहा जाता है। महज 2,5 साल में हमारे सर्वर पर लोड 140 गुना बढ़ गया है.

पुरानी वास्तुकला और उपकरणों के साथ इतना भार झेलना असंभव था। किसी तरह अनुकूलन करना आवश्यक था।

शुरू

विनिमय प्रणाली के अनुरोधों को दो प्रकारों में विभाजित किया जा सकता है:

• लेन-देन. यदि आप डॉलर, शेयर या कुछ और खरीदना चाहते हैं, तो आप ट्रेडिंग सिस्टम को लेनदेन भेजते हैं और सफलता के बारे में प्रतिक्रिया प्राप्त करते हैं।
• सूचना अनुरोध. यदि आप मौजूदा कीमत जानना चाहते हैं, तो ऑर्डर बुक या सूचकांक देखें, फिर सूचना अनुरोध भेजें।

योजनाबद्ध रूप से, सिस्टम के मूल को तीन स्तरों में विभाजित किया जा सकता है:

• ग्राहक स्तर, जिस पर दलाल और ग्राहक काम करते हैं। वे सभी एक्सेस सर्वर के साथ इंटरैक्ट करते हैं।
• गेटवे सर्वर कैशिंग सर्वर हैं जो स्थानीय रूप से सभी सूचना अनुरोधों को संसाधित करते हैं। क्या आप जानना चाहते हैं कि Sberbank के शेयर वर्तमान में किस कीमत पर कारोबार कर रहे हैं? अनुरोध एक्सेस सर्वर पर जाता है।
• लेकिन अगर आप शेयर खरीदना चाहते हैं तो रिक्वेस्ट सेंट्रल सर्वर (ट्रेड इंजन) के पास जाती है। प्रत्येक प्रकार के बाज़ार के लिए एक ऐसा सर्वर है, वे एक महत्वपूर्ण भूमिका निभाते हैं, उन्हीं के लिए हमने यह प्रणाली बनाई है।

ट्रेडिंग सिस्टम का मूल एक चतुर इन-मेमोरी डेटाबेस है जिसमें सभी लेनदेन विनिमय लेनदेन होते हैं। आधार C में लिखा गया था, केवल बाहरी निर्भरताएँ libc लाइब्रेरी थीं और कोई गतिशील मेमोरी आवंटन नहीं था। प्रसंस्करण समय को कम करने के लिए, सिस्टम सरणियों के एक स्थिर सेट और स्थिर डेटा स्थानांतरण के साथ शुरू होता है: सबसे पहले, वर्तमान दिन के सभी डेटा को मेमोरी में लोड किया जाता है, और आगे कोई डिस्क एक्सेस नहीं किया जाता है, सभी काम केवल मेमोरी में किए जाते हैं। जब सिस्टम प्रारंभ होता है, तो सभी संदर्भ डेटा पहले से ही सॉर्ट किया जाता है, इसलिए खोज बहुत कुशलता से काम करती है और रनटाइम में बहुत कम समय लेती है। सभी तालिकाएँ गतिशील डेटा संरचनाओं के लिए दखल देने वाली सूचियों और पेड़ों के साथ बनाई गई हैं ताकि उन्हें रनटाइम पर मेमोरी आवंटन की आवश्यकता न हो।

आइए संक्षेप में हमारे व्यापार और समाशोधन प्रणाली के विकास के इतिहास पर नज़र डालें।
ट्रेडिंग और क्लियरिंग सिस्टम आर्किटेक्चर का पहला संस्करण तथाकथित यूनिक्स इंटरैक्शन पर बनाया गया था: साझा मेमोरी, सेमाफोर और कतारों का उपयोग किया गया था, और प्रत्येक प्रक्रिया में एक ही थ्रेड शामिल था। यह दृष्टिकोण 1990 के दशक की शुरुआत में व्यापक था।

सिस्टम के पहले संस्करण में गेटवे के दो स्तर और ट्रेडिंग सिस्टम का एक केंद्रीय सर्वर शामिल था। कार्य प्रवाह इस प्रकार था:

• क्लाइंट एक अनुरोध भेजता है, जो गेटवे तक पहुंचता है। यह प्रारूप की वैधता की जाँच करता है (लेकिन डेटा की नहीं) और गलत लेनदेन को अस्वीकार करता है।
• यदि कोई सूचना अनुरोध भेजा गया है, तो इसे स्थानीय रूप से निष्पादित किया जाता है; यदि हम किसी लेनदेन के बारे में बात कर रहे हैं, तो इसे केंद्रीय सर्वर पर पुनर्निर्देशित किया जाता है।
• ट्रेडिंग इंजन तब लेनदेन को संसाधित करता है, स्थानीय मेमोरी को संशोधित करता है, और एक अलग प्रतिकृति इंजन का उपयोग करके प्रतिकृति के लिए लेनदेन और लेनदेन पर प्रतिक्रिया भेजता है।
• गेटवे केंद्रीय नोड से प्रतिक्रिया प्राप्त करता है और इसे क्लाइंट को अग्रेषित करता है।
• कुछ समय बाद, गेटवे प्रतिकृति तंत्र के माध्यम से लेनदेन प्राप्त करता है, और इस बार यह इसे स्थानीय रूप से निष्पादित करता है, अपनी डेटा संरचनाओं को बदलता है ताकि अगले सूचना अनुरोध नवीनतम डेटा प्रदर्शित करें।

वास्तव में, यह एक प्रतिकृति मॉडल का वर्णन करता है जिसमें गेटवे ने ट्रेडिंग सिस्टम में किए गए कार्यों को पूरी तरह से दोहराया है। एक अलग प्रतिकृति चैनल ने सुनिश्चित किया कि लेनदेन कई एक्सेस नोड्स में एक ही क्रम में निष्पादित किए गए थे।

चूंकि कोड एकल-थ्रेडेड था, इसलिए कई ग्राहकों की सेवा के लिए प्रोसेस फोर्क्स वाली एक क्लासिक योजना का उपयोग किया गया था। हालाँकि, पूरे डेटाबेस को फोर्क करना बहुत महंगा था, इसलिए हल्के सेवा प्रक्रियाओं का उपयोग किया गया था जो टीसीपी सत्रों से पैकेट एकत्र करते थे और उन्हें एक कतार (सिस्टम वी संदेश कतार) में स्थानांतरित करते थे। गेटवे और ट्रेड इंजन केवल इस कतार के साथ काम करते थे, निष्पादन के लिए वहां से लेनदेन लेते थे। इसका उत्तर भेजना अब संभव नहीं था, क्योंकि यह स्पष्ट नहीं था कि किस सेवा प्रक्रिया को इसे पढ़ना चाहिए। इसलिए हमने एक तरकीब का सहारा लिया: प्रत्येक फोर्कड प्रक्रिया ने अपने लिए एक प्रतिक्रिया कतार बनाई, और जब कोई अनुरोध आने वाली कतार में आया, तो प्रतिक्रिया कतार के लिए एक टैग तुरंत इसमें जोड़ा गया।

लगातार बड़ी मात्रा में डेटा को एक कतार से दूसरी कतार में कॉपी करने से समस्याएँ पैदा हुईं, विशेष रूप से सूचना अनुरोधों के लिए। इसलिए, हमने एक और तरकीब का उपयोग किया: प्रतिक्रिया कतार के अलावा, प्रत्येक प्रक्रिया ने साझा मेमोरी (SystemV Shared Memory) भी बनाई। पैकेज स्वयं इसमें रखे गए थे, और कतार में केवल एक टैग संग्रहीत किया गया था, जिससे कोई मूल पैकेज ढूंढ सके। इससे प्रोसेसर कैश में डेटा संग्रहीत करने में मदद मिली।

SystemV IPC में कतार, मेमोरी और सेमाफोर ऑब्जेक्ट की स्थिति देखने के लिए उपयोगिताएँ शामिल हैं। हमने सक्रिय रूप से इसका उपयोग यह समझने के लिए किया कि किसी विशेष क्षण में सिस्टम में क्या हो रहा था, पैकेट कहाँ जमा हुए, क्या अवरुद्ध किया गया था, आदि।

पहला उन्नयन

सबसे पहले, हमने सिंगल-प्रोसेस गेटवे से छुटकारा पा लिया। इसका महत्वपूर्ण दोष यह था कि यह एक ग्राहक से एक प्रतिकृति लेनदेन या एक सूचना अनुरोध को संभाल सकता था। और जैसे-जैसे लोड बढ़ता है, गेटवे अनुरोधों को संसाधित करने में अधिक समय लेगा और प्रतिकृति प्रवाह को संसाधित करने में सक्षम नहीं होगा। इसके अलावा, यदि क्लाइंट ने कोई ट्रांजैक्शन भेजा है, तो आपको केवल उसकी वैधता जांचनी होगी और उसे आगे फॉरवर्ड करना होगा। इसलिए, हमने एकल गेटवे प्रक्रिया को कई घटकों के साथ बदल दिया जो समानांतर में चल सकते हैं: आरडब्ल्यू लॉकिंग का उपयोग करके साझा मेमोरी क्षेत्र पर एक दूसरे से स्वतंत्र रूप से चलने वाली बहु-थ्रेडेड जानकारी और लेनदेन प्रक्रियाएं। और साथ ही हमने प्रेषण और प्रतिकृति प्रक्रियाएं भी शुरू कीं।

उच्च आवृत्ति व्यापार का प्रभाव

वास्तुकला का उपरोक्त संस्करण 2010 तक अस्तित्व में था। इस बीच, हम एचपी सुपरडोम सर्वर के प्रदर्शन से संतुष्ट नहीं थे। इसके अलावा, पीए-आरआईएससी आर्किटेक्चर वस्तुतः मृत था; विक्रेता ने कोई महत्वपूर्ण अपडेट नहीं दिया। परिणामस्वरूप, हम HP UX/PA RISC से Linux/x86 की ओर बढ़ने लगे। परिवर्तन एक्सेस सर्वर के अनुकूलन के साथ शुरू हुआ।

हमें वास्तुकला को फिर से क्यों बदलना पड़ा? तथ्य यह है कि उच्च-आवृत्ति ट्रेडिंग ने सिस्टम कोर पर लोड प्रोफ़ाइल को महत्वपूर्ण रूप से बदल दिया है।

मान लीजिए कि हमारे पास एक छोटा सा लेन-देन है जिसके कारण कीमत में महत्वपूर्ण परिवर्तन हुआ - किसी ने आधा बिलियन डॉलर खरीदा। कुछ मिलीसेकंड के बाद, सभी बाज़ार सहभागियों ने इसे नोटिस किया और सुधार करना शुरू कर दिया। स्वाभाविक रूप से, अनुरोध एक बड़ी कतार में खड़े होते हैं, जिन्हें साफ़ करने में सिस्टम को लंबा समय लगेगा।

इस 50 एमएस अंतराल पर औसत गति लगभग 16 हजार लेनदेन प्रति सेकंड है। यदि हम विंडो को 20 एमएस तक कम कर देते हैं, तो हमें प्रति सेकंड 90 हजार लेनदेन की औसत गति मिलती है, जिसमें 200 हजार लेनदेन चरम पर होते हैं। दूसरे शब्दों में, भार स्थिर नहीं है, अचानक विस्फोट के साथ। और अनुरोधों की कतार को हमेशा शीघ्रता से संसाधित किया जाना चाहिए।

लेकिन आख़िर कतार क्यों है? इसलिए, हमारे उदाहरण में, कई उपयोगकर्ताओं ने मूल्य परिवर्तन देखा और तदनुसार लेनदेन भेजा। वे गेटवे पर आते हैं, यह उन्हें क्रमबद्ध करता है, एक निश्चित क्रम निर्धारित करता है और उन्हें नेटवर्क पर भेजता है। राउटर पैकेटों को फेरबदल करते हैं और उन्हें आगे भेजते हैं। जिसका पैकेज पहले आया, वह लेनदेन "जीत गया"। परिणामस्वरूप, एक्सचेंज ग्राहकों ने यह नोटिस करना शुरू कर दिया कि यदि एक ही लेनदेन कई गेटवे से भेजा गया था, तो इसके तेजी से प्रसंस्करण की संभावना बढ़ गई। जल्द ही, एक्सचेंज रोबोटों ने गेटवे पर अनुरोधों की बौछार शुरू कर दी, और लेनदेन का एक तूफान खड़ा हो गया।

विकास का एक नया दौर

व्यापक परीक्षण और शोध के बाद, हमने रीयल-टाइम ऑपरेटिंग सिस्टम कर्नेल पर स्विच किया। इसके लिए हमने रेडहैट एंटरप्राइज एमआरजी लिनक्स को चुना, जहां एमआरजी का मतलब मैसेजिंग रियल-टाइम ग्रिड है। वास्तविक समय पैच का लाभ यह है कि वे सबसे तेज़ संभव निष्पादन के लिए सिस्टम को अनुकूलित करते हैं: सभी प्रक्रियाएं फीफो कतार में पंक्तिबद्ध होती हैं, कोर को अलग किया जा सकता है, कोई इजेक्शन नहीं होता है, सभी लेनदेन सख्त अनुक्रम में संसाधित होते हैं।

लाल - नियमित कर्नेल में कतार के साथ काम करना, हरा - वास्तविक समय कर्नेल में काम करना।

लेकिन नियमित सर्वर पर कम विलंबता प्राप्त करना इतना आसान नहीं है:

• एसएमआई मोड, जो x86 आर्किटेक्चर में महत्वपूर्ण बाह्य उपकरणों के साथ काम करने का आधार है, बहुत हस्तक्षेप करता है। सभी प्रकार की हार्डवेयर घटनाओं का प्रसंस्करण और घटकों और उपकरणों का प्रबंधन फर्मवेयर द्वारा तथाकथित पारदर्शी एसएमआई मोड में किया जाता है, जिसमें ऑपरेटिंग सिस्टम यह नहीं देखता है कि फर्मवेयर क्या कर रहा है। एक नियम के रूप में, सभी प्रमुख विक्रेता फर्मवेयर सर्वर के लिए विशेष एक्सटेंशन प्रदान करते हैं जो एसएमआई प्रसंस्करण की मात्रा को कम करने की अनुमति देते हैं।
• प्रोसेसर आवृत्ति का कोई गतिशील नियंत्रण नहीं होना चाहिए, इससे अतिरिक्त डाउनटाइम होता है।
• जब फ़ाइल सिस्टम लॉग फ्लश किया जाता है, तो कर्नेल में कुछ प्रक्रियाएं होती हैं जो अप्रत्याशित देरी का कारण बनती हैं।
• आपको सीपीयू एफिनिटी, इंटरप्ट एफिनिटी, एनयूएमए जैसी चीजों पर ध्यान देने की जरूरत है।

मुझे कहना होगा कि रीयलटाइम प्रोसेसिंग के लिए लिनक्स हार्डवेयर और कर्नेल की स्थापना का विषय एक अलग लेख का हकदार है। अच्छा परिणाम प्राप्त करने से पहले हमने प्रयोग और शोध में बहुत समय बिताया।

पीए-आरआईएससी सर्वर से x86 पर जाने पर, हमें व्यावहारिक रूप से सिस्टम कोड को ज्यादा बदलना नहीं पड़ा, हमने बस इसे अनुकूलित और पुन: कॉन्फ़िगर किया। साथ ही, हमने कई बग भी ठीक किए। उदाहरण के लिए, इस तथ्य के परिणाम कि पीए आरआईएससी एक बिग एंडियन सिस्टम था, और x86 एक लिटिल एंडियन सिस्टम था, जल्दी ही सामने आ गए: उदाहरण के लिए, डेटा गलत तरीके से पढ़ा गया था। पेचीदा बग वह था जिसका उपयोग पीए आरआईएससी करता है लगातार सुसंगत (क्रमिक रूप से सुसंगत) मेमोरी एक्सेस, जबकि x86 रीड ऑपरेशंस को फिर से व्यवस्थित कर सकता है, इसलिए जो कोड एक प्लेटफॉर्म पर बिल्कुल मान्य था वह दूसरे प्लेटफॉर्म पर टूट गया।

x86 पर स्विच करने के बाद, प्रदर्शन लगभग तीन गुना बढ़ गया, औसत लेनदेन प्रसंस्करण समय घटकर 60 μs हो गया।

आइए अब इस पर करीब से नज़र डालें कि सिस्टम आर्किटेक्चर में क्या महत्वपूर्ण बदलाव किए गए हैं।

हॉट रिजर्व महाकाव्य

कमोडिटी सर्वर पर स्विच करते समय, हमें पता था कि वे कम विश्वसनीय थे। इसलिए, एक नया आर्किटेक्चर बनाते समय, हमने प्राथमिकता से एक या अधिक नोड्स की विफलता की संभावना मान ली। इसलिए, एक हॉट स्टैंडबाय सिस्टम की आवश्यकता थी जो बहुत जल्दी बैकअप मशीनों पर स्विच कर सके।

इसके अतिरिक्त, अन्य आवश्यकताएँ भी थीं:

• किसी भी परिस्थिति में आपको संसाधित लेनदेन नहीं खोना चाहिए।
• सिस्टम हमारे बुनियादी ढांचे के लिए बिल्कुल पारदर्शी होना चाहिए।
• ग्राहकों को गिरा हुआ कनेक्शन नहीं दिखना चाहिए।
• आरक्षण में महत्वपूर्ण देरी नहीं होनी चाहिए क्योंकि यह विनिमय के लिए एक महत्वपूर्ण कारक है।

हॉट स्टैंडबाय सिस्टम बनाते समय, हमने ऐसे परिदृश्यों को दोहरी विफलताओं के रूप में नहीं माना (उदाहरण के लिए, एक सर्वर पर नेटवर्क ने काम करना बंद कर दिया और मुख्य सर्वर फ़्रीज़ हो गया); सॉफ़्टवेयर में त्रुटियों की संभावना पर विचार नहीं किया गया क्योंकि परीक्षण के दौरान उनकी पहचान की जाती है; और हार्डवेयर के गलत संचालन पर विचार नहीं किया।

परिणामस्वरूप, हम निम्नलिखित योजना पर आये:

• मुख्य सर्वर ने गेटवे सर्वर के साथ सीधे इंटरैक्ट किया।
• मुख्य सर्वर पर प्राप्त सभी लेनदेन को तुरंत एक अलग चैनल के माध्यम से बैकअप सर्वर पर दोहराया गया। यदि कोई समस्या उत्पन्न होती है तो मध्यस्थ (गवर्नर) ने स्विचिंग का समन्वय किया।

  

• मुख्य सर्वर ने प्रत्येक लेनदेन को संसाधित किया और बैकअप सर्वर से पुष्टि की प्रतीक्षा की। विलंबता को न्यूनतम रखने के लिए, हमने बैकअप सर्वर पर लेनदेन पूरा होने की प्रतीक्षा करने से परहेज किया। चूँकि लेन-देन को पूरे नेटवर्क में यात्रा करने में लगने वाला समय निष्पादन समय के बराबर था, इसलिए कोई अतिरिक्त विलंबता नहीं जोड़ी गई थी।
• हम केवल पिछले लेनदेन के लिए मुख्य और बैकअप सर्वर की प्रसंस्करण स्थिति की जांच कर सकते थे, और वर्तमान लेनदेन की प्रसंस्करण स्थिति अज्ञात थी। चूँकि हम अभी भी एकल-थ्रेडेड प्रक्रियाओं का उपयोग कर रहे थे, बैकअप से प्रतिक्रिया की प्रतीक्षा करने से संपूर्ण प्रसंस्करण प्रवाह धीमा हो जाता, इसलिए हमने एक उचित समझौता किया: हमने पिछले लेनदेन के परिणाम की जाँच की।

योजना ने निम्नानुसार काम किया।

मान लीजिए कि मुख्य सर्वर प्रत्युत्तर देना बंद कर देता है, लेकिन गेटवे संचार जारी रखता है। बैकअप सर्वर पर एक टाइमआउट होता है, यह गवर्नर से संपर्क करता है, जो इसे मुख्य सर्वर की भूमिका सौंपता है, और सभी गेटवे नए मुख्य सर्वर पर स्विच हो जाते हैं।

यदि मुख्य सर्वर ऑनलाइन वापस आता है, तो यह एक आंतरिक टाइमआउट भी ट्रिगर करता है, क्योंकि एक निश्चित समय के लिए गेटवे से सर्वर पर कोई कॉल नहीं हुई है। फिर वह गवर्नर के पास भी जाता है और वह उसे इस योजना से बाहर कर देता है। परिणामस्वरूप, ट्रेडिंग अवधि के अंत तक एक्सचेंज एक सर्वर के साथ काम करता है। चूँकि सर्वर विफलता की संभावना काफी कम है, इस योजना को काफी स्वीकार्य माना गया; इसमें जटिल तर्क नहीं थे और परीक्षण करना आसान था।

को जारी रखा जाएगा.

स्रोत: www.habr.com