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

यह एक शक्तिशाली, उच्च-लोड प्रणाली बनाने के हमारे कांटेदार रास्ते के बारे में एक लंबी कहानी की निरंतरता है जो एक्सचेंज के संचालन को सुनिश्चित करता है। पहला भाग यहाँ है: habr.com/en/post/444300

रहस्यमय त्रुटि

कई परीक्षणों के बाद, अद्यतन व्यापार और समाशोधन प्रणाली को परिचालन में लाया गया, और हमें एक बग का सामना करना पड़ा जिसके बारे में हम एक जासूसी-रहस्यमय कहानी लिख सकते थे।

मुख्य सर्वर पर लॉन्च करने के तुरंत बाद, एक लेनदेन एक त्रुटि के साथ संसाधित किया गया था। हालाँकि, बैकअप सर्वर पर सब कुछ ठीक था। यह पता चला कि मुख्य सर्वर पर घातांक की गणना करने का एक सरल गणितीय ऑपरेशन वास्तविक तर्क से नकारात्मक परिणाम देता है! हमने अपना शोध जारी रखा, और SSE2 रजिस्टर में हमें एक बिट में अंतर मिला, जो फ्लोटिंग पॉइंट नंबरों के साथ काम करते समय राउंडिंग के लिए जिम्मेदार होता है।

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

त्रुटि का कारण पता नहीं चल सका.

फिर उन्होंने हार्डवेयर की जाँच शुरू की: उन्होंने प्रोसेसर का लोड परीक्षण किया; रैम की जाँच की; हमने एक सेल में मल्टी-बिट त्रुटि के बेहद असंभावित परिदृश्य के लिए परीक्षण भी चलाए। बिना परिणाम।

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

चूँकि विफलता का कारण पता लगाना संभव नहीं था, इसलिए "अपमानजनक" सर्वर को केवल मामले में संचालन से हटा दिया गया था।

कुछ समय बाद, हमने हॉट बैकअप सिस्टम में सुधार करना शुरू किया: हमने तथाकथित "वार्म रिजर्व" (गर्म) - अतुल्यकालिक प्रतिकृतियां पेश कीं। उन्हें लेन-देन की एक धारा प्राप्त हुई जो विभिन्न डेटा केंद्रों में स्थित हो सकती थी, लेकिन वॉर्म्स ने अन्य सर्वरों के साथ सक्रिय रूप से बातचीत नहीं की।

ऐसा क्यों किया गया? यदि बैकअप सर्वर विफल हो जाता है, तो मुख्य सर्वर से जुड़ा वार्म नया बैकअप बन जाता है। अर्थात्, विफलता के बाद, सिस्टम ट्रेडिंग सत्र के अंत तक एक मुख्य सर्वर के साथ नहीं रहता है।

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

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

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

प्रणाली का और विकास

हालाँकि हमें त्रुटि से छुटकारा मिल गया, लेकिन इस कहानी ने हमें सिस्टम आर्किटेक्चर पर पुनर्विचार करने के लिए मजबूर किया। आख़िरकार, हम ऐसे बगों की पुनरावृत्ति से सुरक्षित नहीं थे।

निम्नलिखित सिद्धांतों ने आरक्षण प्रणाली में अगले सुधारों का आधार बनाया:

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

बाज़ार में उपलब्ध कोई भी समाधान हमारे अनुकूल नहीं था, और राफ़्ट प्रोटोकॉल अभी भी अपनी प्रारंभिक अवस्था में था, इसलिए हमने अपना स्वयं का समाधान बनाया।

नेटवर्किंग

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

ऐसी स्थितियों में, गतिशील प्रक्रिया प्राथमिकता नियंत्रण का उपयोग किया जा सकता है, लेकिन इसके लिए संसाधन-गहन सिस्टम कॉल के उपयोग की आवश्यकता होगी। परिणामस्वरूप, हमने क्लासिक एपोल का उपयोग करके एक थ्रेड पर स्विच किया, इससे गति में काफी वृद्धि हुई और लेनदेन प्रसंस्करण समय कम हो गया। हमने अलग-अलग नेटवर्क संचार प्रक्रियाओं और SystemV के माध्यम से संचार से भी छुटकारा पा लिया, सिस्टम कॉल की संख्या को काफी कम कर दिया और संचालन की प्राथमिकताओं को नियंत्रित करना शुरू कर दिया। अकेले I/O सबसिस्टम पर, परिदृश्य के आधार पर, लगभग 8-17 माइक्रोसेकंड बचाना संभव था। इस एकल-थ्रेडेड योजना का उपयोग तब से अपरिवर्तित किया गया है; मार्जिन वाला एक एपोल थ्रेड सभी कनेक्शनों की सेवा के लिए पर्याप्त है।

लेनदेन प्रक्रिया

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

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

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

सामान्य तौर पर, जोखिम जाँच प्रणाली में जटिल एल्गोरिदम होते हैं और बड़ी मात्रा में बहुत ही संसाधन-गहन गणनाएँ करते हैं, और केवल "खाता शेष" की जाँच नहीं करते हैं, जैसा कि यह पहली नज़र में लग सकता है।

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

कोड के एक छोटे से अनुकूलन के बाद, हमने समानांतर लेनदेन प्रसंस्करण के लिए एक पाइपलाइन बनाई, जिसमें लेनदेन को पाइपलाइन के 4 चरणों में विभाजित किया गया था: नेटवर्क इंटरैक्शन, सत्यापन, निष्पादन और परिणाम का प्रकाशन

आइए एक उदाहरण देखें. हमारे पास दो प्रसंस्करण प्रणालियाँ हैं, क्रमिक और समानांतर। पहला लेनदेन आता है और दोनों प्रणालियों में सत्यापन के लिए भेजा जाता है। दूसरा लेनदेन तुरंत आता है: समानांतर प्रणाली में इसे तुरंत काम पर ले जाया जाता है, और अनुक्रमिक प्रणाली में इसे पहले लेनदेन के वर्तमान प्रसंस्करण चरण से गुजरने की प्रतीक्षा में कतार में रखा जाता है। यानी पाइपलाइन प्रोसेसिंग का मुख्य लाभ यह है कि हम लेनदेन कतार को तेजी से संसाधित करते हैं।

इस तरह हम एएसटीएस+ प्रणाली लेकर आए।

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

फिर हमने निष्पादन के तीन धागों को सिंक्रनाइज़ करने की समस्या को हल करना शुरू किया। परिणाम निश्चित आकार की कोशिकाओं के साथ रिंग बफर पर आधारित एक प्रणाली थी। इस प्रणाली में, सब कुछ प्रसंस्करण गति के अधीन है; डेटा की प्रतिलिपि नहीं बनाई जाती है।

• सभी आने वाले नेटवर्क पैकेट आवंटन चरण में प्रवेश करते हैं।
• हम उन्हें एक सरणी में रखते हैं और उन्हें चरण #1 के लिए उपलब्ध के रूप में चिह्नित करते हैं।
• दूसरा लेनदेन आ गया है, यह चरण संख्या 1 के लिए फिर से उपलब्ध है।
• पहला प्रोसेसिंग थ्रेड उपलब्ध लेनदेन को देखता है, उन्हें संसाधित करता है, और उन्हें दूसरे प्रोसेसिंग थ्रेड के अगले चरण में ले जाता है।
• इसके बाद यह पहले लेनदेन को संसाधित करता है और संबंधित सेल को चिह्नित करता है deleted - यह अब नए उपयोग के लिए उपलब्ध है।

पूरी कतार को इस तरह से संसाधित किया जाता है।

प्रत्येक चरण की प्रोसेसिंग में इकाई या दसियों माइक्रोसेकंड लगते हैं। और यदि हम मानक OS सिंक्रोनाइज़ेशन योजनाओं का उपयोग करते हैं, तो हम सिंक्रोनाइज़ेशन पर ही अधिक समय खो देंगे। इसीलिए हमने स्पिनलॉक का उपयोग शुरू किया। हालाँकि, यह वास्तविक समय प्रणाली में बहुत खराब रूप है, और RedHat सख्ती से ऐसा करने की अनुशंसा नहीं करता है, इसलिए हम 100 एमएस के लिए एक स्पिनलॉक लागू करते हैं, और फिर गतिरोध की संभावना को खत्म करने के लिए सेमाफोर मोड पर स्विच करते हैं।

परिणामस्वरूप, हमने प्रति सेकंड लगभग 8 मिलियन लेनदेन का प्रदर्शन हासिल किया। और वस्तुतः दो महीने बाद में लेख एलमैक्स डिसरप्टर के बारे में हमने समान कार्यक्षमता वाले एक सर्किट का विवरण देखा।

अब एक ही चरण में निष्पादन के कई सूत्र हो सकते हैं। सभी लेन-देन प्राप्त होने के क्रम में एक-एक करके संसाधित किए गए। परिणामस्वरूप, शिखर प्रदर्शन 18 हजार से बढ़कर 50 हजार लेनदेन प्रति सेकंड हो गया।

विनिमय जोखिम प्रबंधन प्रणाली

पूर्णता की कोई सीमा नहीं है, और जल्द ही हमने फिर से आधुनिकीकरण शुरू किया: एएसटीएस+ के ढांचे के भीतर, हमने जोखिम प्रबंधन और निपटान संचालन प्रणालियों को स्वायत्त घटकों में स्थानांतरित करना शुरू कर दिया। हमने एक लचीली आधुनिक वास्तुकला और एक नया पदानुक्रमित जोखिम मॉडल विकसित किया, और जहां भी संभव हो कक्षा का उपयोग करने का प्रयास किया fixed_point के बदले double.

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

एक नई प्रणाली का चयन करते समय, हमें तुरंत बातचीत की समस्या का समाधान करना था। डेटा बस चुनते समय, स्थिर घबराहट और न्यूनतम विलंबता सुनिश्चित करना आवश्यक था। InfiniBand RDMA नेटवर्क इसके लिए सबसे उपयुक्त था: औसत प्रसंस्करण समय 4 G ईथरनेट नेटवर्क की तुलना में 10 गुना कम है। लेकिन जिस चीज़ ने हमें वास्तव में आकर्षित किया वह था प्रतिशत में अंतर - 99 और 99,9।

बेशक, InfiniBand की अपनी चुनौतियाँ हैं। सबसे पहले, एक अलग एपीआई - सॉकेट के बजाय ibverbs। दूसरे, व्यापक रूप से उपलब्ध ओपन सोर्स मैसेजिंग समाधान लगभग कोई नहीं हैं। हमने अपना खुद का प्रोटोटाइप बनाने की कोशिश की, लेकिन यह बहुत मुश्किल साबित हुआ, इसलिए हमने एक व्यावसायिक समाधान चुना - कॉन्फिनिटी लो लेटेंसी मैसेजिंग (पूर्व में आईबीएम एमक्यू एलएलएम)।

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

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

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

प्रतिलिपि

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

बैकअप डेटा सेंटर के साथ कार्य करना

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

परिणाम

उपरोक्त सभी चीजें एक ही बार में नहीं की गईं; एक नई वास्तुकला विकसित करने में कई पुनरावृत्तियाँ हुईं। हमने प्रोटोटाइप एक महीने में बना लिया, लेकिन इसे काम करने की स्थिति में लाने में दो साल से अधिक का समय लग गया। हमने लेन-देन प्रसंस्करण समय बढ़ाने और सिस्टम विश्वसनीयता बढ़ाने के बीच सर्वोत्तम समझौता करने का प्रयास किया।

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

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

हमने अपने प्लेटफ़ॉर्म के वर्तमान संस्करण को रेबस कहा - वास्तुकला में दो सबसे उल्लेखनीय नवाचारों, रिस्क इंजन और बीयूएस के संक्षिप्त नाम के रूप में।

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

आख़िरकार हमने क्या हासिल किया:

विलंबता स्तर कम हो गया. लेन-देन की थोड़ी मात्रा के साथ, सिस्टम पिछले संस्करण की तरह ही काम करता है, लेकिन साथ ही बहुत अधिक भार का सामना कर सकता है।

शिखर प्रदर्शन 50 हजार से बढ़कर 180 हजार लेनदेन प्रति सेकंड हो गया। ऑर्डर मिलान की एकमात्र धारा से और वृद्धि बाधित होती है।

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

अंत में, मैं उन लोगों को कुछ सलाह दे सकता हूं जो एंटरप्राइज़ सिस्टम को अंतिम रूप दे रहे हैं:

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

स्रोत: www.habr.com