मॉस्को एक्सचेंजच्या ट्रेडिंग आणि क्लिअरिंग सिस्टमच्या आर्किटेक्चरची उत्क्रांती. भाग 1

सर्वांना नमस्कार! माझे नाव सर्गेई कोस्टनबाएव आहे, एक्सचेंजमध्ये मी ट्रेडिंग सिस्टमचा मुख्य भाग विकसित करत आहे.

जेव्हा हॉलीवूडचे चित्रपट न्यूयॉर्क स्टॉक एक्सचेंज दाखवतात तेव्हा ते नेहमी असे दिसते: लोकांची गर्दी, प्रत्येकजण काहीतरी ओरडत आहे, कागद हलवत आहे, संपूर्ण अराजकता आहे. मॉस्को एक्सचेंजवर असे कधीही घडले नाही, कारण सुरुवातीपासूनच ट्रेडिंग इलेक्ट्रॉनिक पद्धतीने केले जात आहे आणि स्पेक्ट्रा (फॉरेक्स मार्केट) आणि एएसटीएस (परकीय चलन, स्टॉक आणि मनी मार्केट) या दोन मुख्य प्लॅटफॉर्मवर आधारित आहे. आणि आज मला ASTS ट्रेडिंग आणि क्लिअरिंग सिस्टमच्या आर्किटेक्चरच्या उत्क्रांतीबद्दल, विविध उपाय आणि निष्कर्षांबद्दल बोलायचे आहे. कथा लांबलचक असेल, म्हणून मला तिचे दोन भाग करावे लागले.

आम्ही जगातील अशा काही एक्सचेंजेसपैकी एक आहोत जे सर्व वर्गांच्या मालमत्तेचा व्यापार करतात आणि एक्सचेंज सेवांची संपूर्ण श्रेणी प्रदान करतात. उदाहरणार्थ, गेल्या वर्षी आम्ही बाँड ट्रेडिंग व्हॉल्यूमच्या बाबतीत जगात दुसऱ्या क्रमांकावर, सर्व स्टॉक एक्स्चेंजमध्ये 25 वे स्थान, सार्वजनिक एक्सचेंजमध्ये भांडवलीकरणामध्ये 13 वे स्थान मिळवले.

व्यावसायिक व्यापारातील सहभागींसाठी, प्रतिसाद वेळ, वेळेच्या वितरणाची स्थिरता (जिटर) आणि संपूर्ण कॉम्प्लेक्सची विश्वासार्हता यासारखे घटक महत्त्वाचे आहेत. आम्ही सध्या दररोज लाखो व्यवहारांवर प्रक्रिया करतो. सिस्टम कर्नलद्वारे प्रत्येक व्यवहाराच्या प्रक्रियेस दहापट मायक्रोसेकंद लागतात. अर्थात, नवीन वर्षाच्या पूर्वसंध्येला मोबाइल ऑपरेटर किंवा शोध इंजिनांवर स्वतःहून आपल्यापेक्षा जास्त वर्कलोड आहे, परंतु वर्कलोडच्या बाबतीत, वर नमूद केलेल्या वैशिष्ट्यांसह, काही लोक आपल्याशी तुलना करू शकतात, असे मला वाटते. त्याच वेळी, आमच्यासाठी हे महत्वाचे आहे की सिस्टम एका सेकंदासाठी धीमा होत नाही, पूर्णपणे स्थिरपणे कार्य करते आणि सर्व वापरकर्ते समान पातळीवर आहेत.

थोडा इतिहास

1994 मध्ये, ऑस्ट्रेलियन एएसटीएस प्रणाली मॉस्को इंटरबँक करन्सी एक्सचेंज (एमआयसीईएक्स) वर सुरू केली गेली आणि त्या क्षणापासून इलेक्ट्रॉनिक व्यापाराचा रशियन इतिहास मोजला जाऊ शकतो. 1998 मध्ये, इंटरनेट ट्रेडिंग सुरू करण्यासाठी एक्सचेंज आर्किटेक्चरचे आधुनिकीकरण करण्यात आले. तेव्हापासून, सर्व प्रणाली आणि उपप्रणालींमध्ये नवीन उपाय आणि वास्तुशास्त्रीय बदलांच्या अंमलबजावणीची गती केवळ गती प्राप्त करत आहे.

त्या वर्षांमध्ये, एक्सचेंज सिस्टमने हाय-एंड हार्डवेअरवर काम केले - अल्ट्रा-विश्वसनीय एचपी सुपरडोम 9000 सर्व्हर (यावर तयार केलेले PA-RISC), ज्यामध्ये पूर्णपणे सर्वकाही डुप्लिकेट केले होते: इनपुट/आउटपुट उपप्रणाली, नेटवर्क, RAM (खरं तर, RAM चा RAID अॅरे होता), प्रोसेसर (हॉट-स्वॅप करण्यायोग्य). मशीन न थांबवता कोणताही सर्व्हर घटक बदलणे शक्य होते. आम्ही या उपकरणांवर अवलंबून राहिलो आणि त्यांना अक्षरशः अयशस्वी-सुरक्षित मानले. ऑपरेटिंग सिस्टम ही युनिक्ससारखी HP UX प्रणाली होती.

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

जुन्या आर्किटेक्चर आणि उपकरणांसह इतका भार सहन करणे अशक्य होते. कसे तरी जुळवून घेणे आवश्यक होते.

Начало

एक्सचेंज सिस्टमला विनंत्या दोन प्रकारांमध्ये विभागल्या जाऊ शकतात:

• व्यवहार. तुम्हाला डॉलर्स, शेअर्स किंवा आणखी काही खरेदी करायचे असल्यास, तुम्ही ट्रेडिंग सिस्टीमला व्यवहार पाठवा आणि यशाबद्दल प्रतिसाद प्राप्त करा.
• माहिती विनंत्या. तुम्हाला सध्याची किंमत जाणून घ्यायची असल्यास, ऑर्डर बुक किंवा निर्देशांक पहा, नंतर माहिती विनंत्या पाठवा.

योजनाबद्धपणे, सिस्टमचा गाभा तीन स्तरांमध्ये विभागला जाऊ शकतो:

• क्लायंट स्तर, ज्यावर ब्रोकर आणि क्लायंट काम करतात. ते सर्व प्रवेश सर्व्हरशी संवाद साधतात.
• गेटवे सर्व्हर कॅशिंग सर्व्हर आहेत जे सर्व माहिती विनंत्यांवर स्थानिक पातळीवर प्रक्रिया करतात. तुम्हाला हे जाणून घ्यायचे आहे का की Sberbank चे शेअर्स सध्या कोणत्या किंमतीला ट्रेडिंग करत आहेत? विनंती ऍक्सेस सर्व्हरकडे जाते.
• पण जर तुम्हाला शेअर्स खरेदी करायचे असतील, तर रिक्वेस्ट सेंट्रल सर्व्हरकडे (ट्रेड इंजिन) जाते. प्रत्येक प्रकारच्या मार्केटसाठी असा एक सर्व्हर आहे, ते महत्त्वपूर्ण भूमिका बजावतात, त्यांच्यासाठीच आम्ही ही प्रणाली तयार केली आहे.

ट्रेडिंग सिस्टीमचा गाभा हा एक हुशार इन-मेमरी डेटाबेस आहे ज्यामध्ये सर्व व्यवहार एक्सचेंज व्यवहार असतात. बेस C मध्ये लिहिलेला होता, फक्त बाह्य अवलंबित्व libc लायब्ररी होती आणि तेथे कोणतेही डायनॅमिक मेमरी वाटप नव्हते. प्रक्रिया वेळ कमी करण्यासाठी, सिस्टम अॅरेच्या स्थिर संचासह आणि स्थिर डेटा पुनर्स्थापनेसह सुरू होते: प्रथम, वर्तमान दिवसाचा सर्व डेटा मेमरीमध्ये लोड केला जातो आणि पुढील डिस्क प्रवेश केला जात नाही, सर्व कार्य केवळ मेमरीमध्ये चालते. जेव्हा सिस्टम सुरू होते, तेव्हा सर्व संदर्भ डेटा आधीपासूनच क्रमवारी लावलेला असतो, त्यामुळे शोध अतिशय कार्यक्षमतेने कार्य करतो आणि रनटाइममध्ये थोडा वेळ लागतो. सर्व टेबल्स डायनॅमिक डेटा स्ट्रक्चर्ससाठी अनाहूत सूची आणि झाडांसह बनविल्या जातात जेणेकरून त्यांना रनटाइममध्ये मेमरी वाटपाची आवश्यकता नसते.

आपल्या ट्रेडिंग आणि क्लिअरिंग सिस्टमच्या विकासाचा इतिहास थोडक्यात पाहू.
ट्रेडिंग आणि क्लिअरिंग सिस्टम आर्किटेक्चरची पहिली आवृत्ती तथाकथित युनिक्स परस्परसंवादावर तयार केली गेली: सामायिक मेमरी, सेमाफोर्स आणि रांगा वापरल्या गेल्या आणि प्रत्येक प्रक्रियेमध्ये एकच धागा होता. 1990 च्या दशकाच्या सुरुवातीस हा दृष्टिकोन व्यापक होता.

प्रणालीच्या पहिल्या आवृत्तीमध्ये गेटवेचे दोन स्तर आणि व्यापार प्रणालीचे मध्यवर्ती सर्व्हर समाविष्ट होते. कामाचा प्रवाह असा होता:

• क्लायंट एक विनंती पाठवतो, जी गेटवेवर पोहोचते. ते फॉरमॅटची वैधता तपासते (परंतु डेटा स्वतःच नाही) आणि चुकीचे व्यवहार नाकारते.
• जर माहिती विनंती पाठवली गेली असेल, तर ती स्थानिक पातळीवर कार्यान्वित केली जाते; जर आपण एखाद्या व्यवहाराबद्दल बोलत आहोत, तर ते केंद्रीय सर्व्हरवर पुनर्निर्देशित केले जाते.
• ट्रेडिंग इंजिन नंतर व्यवहारावर प्रक्रिया करते, स्थानिक मेमरी सुधारते आणि स्वतंत्र प्रतिकृती इंजिन वापरून प्रतिकृतीसाठी व्यवहार आणि व्यवहाराला प्रतिसाद पाठवते.
• गेटवेला सेंट्रल नोडकडून प्रतिसाद मिळतो आणि तो क्लायंटकडे पाठवतो.
• काही काळानंतर, गेटवेला प्रतिकृती यंत्रणेद्वारे व्यवहार प्राप्त होतो, आणि यावेळी तो स्थानिक पातळीवर कार्यान्वित करतो, त्याची डेटा संरचना बदलतो जेणेकरून पुढील माहिती विनंत्या नवीनतम डेटा प्रदर्शित करतात.

खरेतर, ते प्रतिकृती मॉडेलचे वर्णन करते ज्यामध्ये गेटवेने ट्रेडिंग सिस्टीममध्ये केलेल्या क्रियांची पूर्णपणे प्रतिकृती केली आहे. एका वेगळ्या प्रतिकृती चॅनेलने हे सुनिश्चित केले की अनेक प्रवेश नोड्समध्ये व्यवहार एकाच क्रमाने कार्यान्वित केले गेले.

कोड सिंगल-थ्रेडेड असल्याने, अनेक क्लायंटना सेवा देण्यासाठी प्रोसेस फॉर्क्स असलेली क्लासिक योजना वापरली गेली. तथापि, संपूर्ण डेटाबेस फोर्क करणे खूप महाग होते, म्हणून कमी वजनाच्या सेवा प्रक्रिया वापरल्या गेल्या ज्याने TCP सत्रांमधून पॅकेट गोळा केले आणि त्यांना एका रांगेत (सिस्टमव्ही संदेश रांग) हस्तांतरित केले. गेटवे आणि ट्रेड इंजिन फक्त या रांगेतच काम करत होते, तेथून व्यवहार चालवायचे. त्यावर प्रतिसाद पाठवणे आता शक्य नव्हते, कारण कोणत्या सेवा प्रक्रियेने तो वाचावा हे स्पष्ट नव्हते. म्हणून आम्ही एका युक्तीचा अवलंब केला: प्रत्येक काटेरी प्रक्रियेने स्वतःसाठी एक प्रतिसाद रांग तयार केली आणि जेव्हा एखादी विनंती येणार्‍या रांगेत आली, तेव्हा प्रतिसादाच्या रांगेसाठी एक टॅग लगेच जोडला गेला.

रांगेतून रांगेत मोठ्या प्रमाणात डेटा कॉपी केल्याने समस्या निर्माण होतात, विशेषत: माहिती विनंत्यांसाठी वैशिष्ट्यपूर्ण. म्हणून, आम्ही दुसरी युक्ती वापरली: प्रतिसाद रांगेव्यतिरिक्त, प्रत्येक प्रक्रियेने सामायिक मेमरी (सिस्टमव्ही सामायिक मेमरी) देखील तयार केली. त्यात स्वतःच पॅकेजेस ठेवण्यात आली होती आणि रांगेत फक्त एक टॅग ठेवला होता, ज्यामुळे एखाद्याला मूळ पॅकेज शोधता येते. यामुळे प्रोसेसर कॅशेमध्ये डेटा साठवण्यास मदत झाली.

SystemV IPC मध्ये रांग, मेमरी आणि सेमाफोर ऑब्जेक्ट्सची स्थिती पाहण्यासाठी उपयुक्तता समाविष्ट आहे. एका विशिष्ट क्षणी सिस्टममध्ये काय घडत आहे, पॅकेट कुठे जमा झाले, काय अवरोधित केले गेले, इत्यादी समजून घेण्यासाठी आम्ही सक्रियपणे याचा वापर केला.

प्रथम आधुनिकीकरण

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

उच्च वारंवारता व्यापार प्रभाव

आर्किटेक्चरची वरील आवृत्ती 2010 पर्यंत अस्तित्वात होती. दरम्यान, HP सुपरडोम सर्व्हरच्या कार्यप्रदर्शनावर आम्ही यापुढे समाधानी नव्हतो. याव्यतिरिक्त, PA-RISC आर्किटेक्चर अक्षरशः मृत होते; विक्रेत्याने कोणतेही महत्त्वपूर्ण अद्यतने ऑफर केली नाहीत. परिणामी, आम्ही HP UX/PA RISC वरून Linux/x86 वर जाऊ लागलो. प्रवेश सर्व्हरच्या रुपांतराने संक्रमणाची सुरुवात झाली.

आम्हाला पुन्हा वास्तुकला का बदलावी लागली? वस्तुस्थिती अशी आहे की उच्च-वारंवारता व्यापाराने सिस्टम कोरवरील लोड प्रोफाइलमध्ये लक्षणीय बदल केला आहे.

समजा आमच्याकडे एक छोटासा व्यवहार आहे ज्यामुळे किमतीत लक्षणीय बदल झाला - कोणीतरी अर्धा अब्ज डॉलर्स विकत घेतले. काही मिलिसेकंदांनंतर, सर्व बाजारातील सहभागींना हे लक्षात येते आणि ते दुरुस्त करण्यास सुरवात करतात. साहजिकच, विनंत्या मोठ्या रांगेत असतात, ज्या साफ करण्यासाठी सिस्टमला बराच वेळ लागेल.

या 50 ms अंतराने, सरासरी वेग प्रति सेकंद सुमारे 16 हजार व्यवहार आहे. जर आम्ही विंडो 20 ms पर्यंत कमी केली, तर आम्हाला 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