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

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

अनाकलनीय त्रुटी

असंख्य चाचण्यांनंतर, अद्ययावत व्यापार आणि क्लिअरिंग सिस्टम कार्यान्वित करण्यात आली आणि आम्हाला एक बग आला ज्याबद्दल आम्ही एक गुप्तचर-गूढ कथा लिहू शकतो.

मुख्य सर्व्हरवर लॉन्च झाल्यानंतर काही वेळातच, एका व्यवहारावर त्रुटी आढळून आली. तथापि, बॅकअप सर्व्हरवर सर्व काही ठीक होते. असे दिसून आले की मुख्य सर्व्हरवरील घातांकाची गणना करण्याच्या एका साध्या गणितीय ऑपरेशनने वास्तविक युक्तिवादाचा नकारात्मक परिणाम दिला! आम्ही आमचे संशोधन चालू ठेवले आणि SSE2 रजिस्टरमध्ये आम्हाला एका बिटमध्ये फरक आढळला, जो फ्लोटिंग पॉइंट नंबर्ससह कार्य करताना गोलाकार करण्यासाठी जबाबदार आहे.

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

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

मग त्यांनी हार्डवेअर तपासण्यास सुरुवात केली: त्यांनी प्रोसेसरची लोड चाचणी केली; RAM तपासली; आम्ही एका सेलमध्ये मल्टी-बिट त्रुटीच्या अत्यंत संभाव्य परिस्थितीसाठी चाचण्या देखील केल्या. काही उपयोग झाला नाही.

सरतेशेवटी, आम्ही उच्च-ऊर्जा भौतिकशास्त्राच्या जगाच्या सिद्धांतावर स्थिरावलो: काही उच्च-ऊर्जेचे कण आमच्या डेटा सेंटरमध्ये उडून गेले, केस भिंतीला छेदले, प्रोसेसरला आदळले आणि ट्रिगर लॅच अगदी थोडासा चिकटला. या हास्यास्पद सिद्धांताला "न्यूट्रिनो" असे म्हणतात. जर तुम्ही कण भौतिकशास्त्रापासून दूर असाल तर: न्यूट्रिनो जवळजवळ बाहेरील जगाशी संवाद साधत नाहीत आणि प्रोसेसरच्या ऑपरेशनवर नक्कीच परिणाम करू शकत नाहीत.

अयशस्वी होण्याचे कारण शोधणे शक्य नसल्यामुळे, "आक्षेपार्ह" सर्व्हर फक्त बाबतीत ऑपरेशनमधून काढला गेला.

काही काळानंतर, आम्ही हॉट बॅकअप सिस्टम सुधारण्यास सुरुवात केली: आम्ही तथाकथित "उबदार राखीव" (उबदार) - असिंक्रोनस प्रतिकृती सादर केल्या. त्यांना व्यवहारांचा एक प्रवाह प्राप्त झाला जो भिन्न डेटा केंद्रांमध्ये स्थित असू शकतो, परंतु वॉर्म्सने इतर सर्व्हरशी सक्रियपणे संवाद साधला नाही.

हे का केले गेले? बॅकअप सर्व्हर अयशस्वी झाल्यास, मुख्य सर्व्हरशी जोडलेले उबदार नवीन बॅकअप बनते. म्हणजेच, अयशस्वी झाल्यानंतर, ट्रेडिंग सत्र संपेपर्यंत सिस्टम एका मुख्य सर्व्हरवर राहत नाही.

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

परिस्थितीच्या पुढील विश्लेषणादरम्यान, एक सिद्धांत उद्भवला की समस्या OS शी संबंधित असू शकते. आम्ही एक साधा प्रोग्राम लिहिला जो अंतहीन लूपमध्ये फंक्शन कॉल करतो fesetround, वर्तमान स्थिती लक्षात ठेवते आणि झोपेद्वारे ते तपासते, आणि हे अनेक स्पर्धात्मक थ्रेड्समध्ये केले जाते. स्लीपसाठी पॅरामीटर्स आणि थ्रेड्सची संख्या निवडल्यानंतर, आम्ही युटिलिटी चालवल्यानंतर सुमारे 5 मिनिटांनंतर बिट अपयशाचे सातत्याने पुनरुत्पादन करण्यास सुरुवात केली. तथापि, Red Hat समर्थन त्याचे पुनरुत्पादन करू शकले नाही. आमच्या इतर सर्व्हरच्या चाचणीने दर्शविले आहे की केवळ विशिष्ट प्रोसेसर असलेल्यांनाच त्रुटीची शक्यता असते. त्याच वेळी, नवीन कर्नलवर स्विच केल्याने समस्येचे निराकरण झाले. शेवटी, आम्ही फक्त OS बदलले आणि बगचे खरे कारण अस्पष्ट राहिले.

आणि अचानक गेल्या वर्षी Habré वर एक लेख प्रकाशित झाला “मला इंटेल स्कायलेक प्रोसेसरमध्ये बग कसा सापडला" त्यात वर्णन केलेली परिस्थिती आमच्यासारखीच होती, परंतु लेखकाने तपास पुढे नेला आणि एक सिद्धांत मांडला की त्रुटी मायक्रोकोडमध्ये होती. आणि जेव्हा लिनक्स कर्नल अद्यतनित केले जातात, तेव्हा उत्पादक मायक्रोकोड देखील अद्यतनित करतात.

प्रणालीचा पुढील विकास

जरी आम्ही त्रुटीपासून मुक्त झालो, तरी या कथेने आम्हाला सिस्टम आर्किटेक्चरवर पुनर्विचार करण्यास भाग पाडले. शेवटी, अशा बगच्या पुनरावृत्तीपासून आमचे संरक्षण झाले नाही.

खालील तत्त्वांनी आरक्षण प्रणालीतील पुढील सुधारणांसाठी आधार तयार केला:

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

बाजारात उपलब्ध असलेले कोणतेही समाधान आमच्यासाठी अनुकूल नव्हते आणि राफ्ट प्रोटोकॉल अजूनही बाल्यावस्थेत होता, म्हणून आम्ही आमचे स्वतःचे समाधान तयार केले.

नेटवर्किंग

आरक्षण प्रणाली व्यतिरिक्त, आम्ही नेटवर्क संवादाचे आधुनिकीकरण करण्यास सुरुवात केली. I/O उपप्रणालीमध्ये अनेक प्रक्रियांचा समावेश होता, ज्याचा जिटर आणि लेटन्सीवर सर्वात वाईट परिणाम होतो. टीसीपी कनेक्शन हाताळणाऱ्या शेकडो प्रक्रियांसह, आम्हाला त्यांच्या दरम्यान सतत स्विच करणे भाग पडले आणि मायक्रोसेकंद स्केलवर हे एक वेळ घेणारे ऑपरेशन आहे. परंतु सर्वात वाईट गोष्ट अशी आहे की जेव्हा एखाद्या प्रक्रियेस प्रक्रियेसाठी एक पॅकेट प्राप्त होते, तेव्हा ते एका SystemV रांगेत पाठवले जाते आणि नंतर दुसर्या SystemV रांगेतील कार्यक्रमाची प्रतीक्षा केली जाते. तथापि, जेव्हा मोठ्या संख्येने नोड्स असतात, तेव्हा एका प्रक्रियेत नवीन TCP पॅकेटचे आगमन आणि दुसर्‍या रांगेत डेटाची पावती OS साठी दोन स्पर्धात्मक घटना दर्शवतात. या प्रकरणात, दोन्ही कार्यांसाठी कोणतेही भौतिक प्रोसेसर उपलब्ध नसल्यास, एकावर प्रक्रिया केली जाईल आणि दुसरा प्रतीक्षा रांगेत ठेवला जाईल. त्याचे परिणाम सांगणे अशक्य आहे.

अशा परिस्थितीत, डायनॅमिक प्रक्रिया प्राधान्य नियंत्रण वापरले जाऊ शकते, परंतु यासाठी संसाधन-केंद्रित सिस्टम कॉलचा वापर आवश्यक असेल. परिणामी, आम्ही क्लासिक इपोल वापरून एका थ्रेडवर स्विच केले, यामुळे वेग मोठ्या प्रमाणात वाढला आणि व्यवहार प्रक्रियेचा वेळ कमी झाला. आम्ही स्वतंत्र नेटवर्क संप्रेषण प्रक्रिया आणि SystemV द्वारे संप्रेषणापासून मुक्त झालो, सिस्टम कॉलची संख्या लक्षणीयरीत्या कमी केली आणि ऑपरेशन्सच्या प्राधान्यक्रमांवर नियंत्रण ठेवण्यास सुरुवात केली. केवळ I/O उपप्रणालीवर, परिस्थितीनुसार, सुमारे 8-17 मायक्रोसेकंद वाचवणे शक्य होते. तेव्हापासून ही सिंगल-थ्रेडेड स्कीम अपरिवर्तित वापरली जात आहे; सर्व कनेक्शन सेवा देण्यासाठी एक इपोल थ्रेड मार्जिनसह पुरेसा आहे.

व्यवहार प्रक्रिया

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

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

उदाहरणासह स्पष्ट करू. व्यापार्‍याला $30 विकत घ्यायचे आहे, आणि विनंती व्यवहार प्रमाणीकरणाकडे जाते: या ट्रेडरला या ट्रेडिंग मोडची परवानगी आहे की नाही आणि त्याला आवश्यक अधिकार आहेत का ते आम्ही तपासतो. सर्वकाही व्यवस्थित असल्यास, विनंती जोखीम सत्यापन प्रणालीकडे जाते, म्हणजे. व्यवहार पूर्ण करण्यासाठी निधीची पर्याप्तता तपासण्यासाठी. आवश्यक रक्कम सध्या अवरोधित असल्याची नोंद आहे. विनंती नंतर ट्रेडिंग सिस्टमकडे पाठविली जाते, जी व्यवहारास मान्यता देते किंवा नाकारते. समजा व्यवहार मंजूर झाला आहे - नंतर जोखीम सत्यापन प्रणाली चिन्हांकित करते की पैसे अनब्लॉक केले आहेत आणि रूबल डॉलरमध्ये बदलतात.

सर्वसाधारणपणे, जोखीम तपासणी प्रणालीमध्ये जटिल अल्गोरिदम असतात आणि ती मोठ्या प्रमाणात संसाधन-केंद्रित गणना करते आणि फक्त "खाते शिल्लक" तपासत नाही, कारण ती पहिल्या दृष्टीक्षेपात दिसते.

जेव्हा आम्ही इंजिन प्रक्रियेला स्तरांमध्ये विभाजित करणे सुरू केले, तेव्हा आम्हाला एक समस्या आली: त्या वेळी उपलब्ध असलेला कोड सत्यापन आणि पडताळणीच्या टप्प्यांवर डेटाच्या समान अॅरेचा सक्रियपणे वापर करतो, ज्यासाठी संपूर्ण कोड बेस पुन्हा लिहिणे आवश्यक होते. परिणामी, आम्ही आधुनिक प्रोसेसरकडून सूचनांवर प्रक्रिया करण्यासाठी एक तंत्र उधार घेतले आहे: त्यापैकी प्रत्येक लहान टप्प्यात विभागलेला आहे आणि एका चक्रात समांतरपणे अनेक क्रिया केल्या जातात.

कोडच्या छोट्या रुपांतरानंतर, आम्ही समांतर व्यवहार प्रक्रियेसाठी एक पाइपलाइन तयार केली, ज्यामध्ये व्यवहार पाइपलाइनच्या 4 टप्प्यांमध्ये विभागला गेला: नेटवर्क परस्परसंवाद, प्रमाणीकरण, अंमलबजावणी आणि निकालाचे प्रकाशन

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

अशाप्रकारे आम्ही ASTS+ प्रणाली घेऊन आलो.

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

मग आम्ही अंमलबजावणीचे तीन थ्रेड सिंक्रोनाइझ करण्याच्या समस्येचे निराकरण करण्यास सुरवात केली. परिणाम निश्चित आकाराच्या पेशींसह रिंग बफरवर आधारित एक प्रणाली होती. या प्रणालीमध्ये, सर्वकाही प्रक्रियेच्या गतीच्या अधीन आहे; डेटा कॉपी केला जात नाही.

• सर्व येणारे नेटवर्क पॅकेट वाटप टप्प्यात प्रवेश करतात.
• आम्ही त्यांना अॅरेमध्ये ठेवतो आणि स्टेज #1 साठी उपलब्ध म्हणून चिन्हांकित करतो.
• दुसरा व्यवहार आला आहे, तो स्टेज क्रमांक 1 साठी पुन्हा उपलब्ध आहे.
• पहिला प्रोसेसिंग थ्रेड उपलब्ध व्यवहार पाहतो, त्यावर प्रक्रिया करतो आणि दुसऱ्या प्रोसेसिंग थ्रेडच्या पुढच्या टप्प्यावर हलवतो.
• ते नंतर पहिल्या व्यवहारावर प्रक्रिया करते आणि संबंधित सेलला ध्वजांकित करते deleted — ते आता नवीन वापरासाठी उपलब्ध आहे.

संपूर्ण रांगेवर अशा प्रकारे प्रक्रिया केली जाते.

प्रत्येक टप्प्यावर प्रक्रिया करण्यासाठी युनिट्स किंवा दहापट मायक्रोसेकंद लागतात. आणि जर आम्ही मानक OS सिंक्रोनाइझेशन स्कीम वापरतो, तर आम्ही सिंक्रोनाइझेशनवरच अधिक वेळ गमावू. म्हणूनच आम्ही स्पिनलॉक वापरण्यास सुरुवात केली. तथापि, रिअल-टाइम सिस्टममध्ये हे अतिशय वाईट स्वरूप आहे, आणि RedHat कठोरपणे असे करण्याची शिफारस करत नाही, म्हणून आम्ही 100 ms साठी स्पिनलॉक लागू करतो आणि नंतर डेडलॉकची शक्यता दूर करण्यासाठी सेमफोर मोडवर स्विच करतो.

परिणामी, आम्ही प्रति सेकंद सुमारे 8 दशलक्ष व्यवहारांची कामगिरी साध्य केली. आणि अक्षरशः दोन महिन्यांनंतर लेख LMAX Disruptor बद्दल आम्ही समान कार्यक्षमतेसह सर्किटचे वर्णन पाहिले.

आता एका टप्प्यावर अंमलबजावणीचे अनेक धागे असू शकतात. प्राप्त झालेल्या क्रमाने सर्व व्यवहार एक एक करून प्रक्रिया करण्यात आले. परिणामी, सर्वोच्च कामगिरी प्रति सेकंद 18 हजारांवरून 50 हजार व्यवहारांपर्यंत वाढली.

एक्सचेंज जोखीम व्यवस्थापन प्रणाली

परिपूर्णतेला मर्यादा नाही, आणि लवकरच आम्ही पुन्हा आधुनिकीकरण सुरू केले: ASTS+ च्या चौकटीत, आम्ही जोखीम व्यवस्थापन आणि सेटलमेंट ऑपरेशन्स सिस्टमला स्वायत्त घटकांमध्ये हलवण्यास सुरुवात केली. आम्ही एक लवचिक आधुनिक आर्किटेक्चर आणि नवीन श्रेणीबद्ध जोखीम मॉडेल विकसित केले आणि शक्य असेल तेथे वर्ग वापरण्याचा प्रयत्न केला. fixed_point त्याऐवजी double.

परंतु लगेचच एक समस्या उद्भवली: बर्याच वर्षांपासून कार्यरत असलेले सर्व व्यवसाय तर्क कसे सिंक्रोनाइझ करावे आणि ते नवीन सिस्टममध्ये कसे हस्तांतरित करावे? परिणामी, नवीन सिस्टमच्या प्रोटोटाइपची पहिली आवृत्ती सोडून द्यावी लागली. दुसरी आवृत्ती, जी सध्या उत्पादनात कार्यरत आहे, त्याच कोडवर आधारित आहे, जी व्यापार आणि जोखीम दोन्ही भागांमध्ये कार्य करते. विकासादरम्यान, दोन आवृत्त्यांमध्ये git विलीन करणे ही सर्वात कठीण गोष्ट होती. आमचे सहकारी Evgeniy Mazurenok यांनी दर आठवड्याला हे ऑपरेशन केले आणि प्रत्येक वेळी त्याने खूप काळ शाप दिला.

नवीन प्रणाली निवडताना, आम्हाला त्वरित परस्परसंवादाची समस्या सोडवावी लागली. डेटा बस निवडताना, स्थिर गोंधळ आणि किमान विलंब सुनिश्चित करणे आवश्यक होते. InfiniBand RDMA नेटवर्क यासाठी सर्वात योग्य होते: सरासरी प्रक्रिया वेळ 4 G इथरनेट नेटवर्कपेक्षा 10 पट कमी आहे. पण 99 आणि 99,9 - पर्सेंटाइलमधील फरक म्हणजे आम्हाला खरोखर मोहित केले.

अर्थात, InfiniBand ची आव्हाने आहेत. प्रथम, एक भिन्न API - सॉकेट्सऐवजी ibverbs. दुसरे म्हणजे, ओपन सोर्स मेसेजिंग सोल्यूशन्स जवळजवळ उपलब्ध नाहीत. आम्ही आमचा स्वतःचा प्रोटोटाइप बनवण्याचा प्रयत्न केला, परंतु ते खूप कठीण झाले, म्हणून आम्ही एक व्यावसायिक उपाय निवडला - कॉन्फिनिटी लो लेटेंसी मेसेजिंग (पूर्वीचे IBM MQ LLM).

मग जोखीम प्रणाली योग्यरित्या विभाजित करण्याचे कार्य उद्भवले. जर तुम्ही रिस्क इंजिन फक्त काढून टाकले आणि इंटरमीडिएट नोड तयार न केल्यास, दोन स्त्रोतांकडून व्यवहार मिसळले जाऊ शकतात.

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

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

दुप्पट

आमच्‍या सिस्‍टममध्‍ये अपयशाचा एकच बिंदू नसावा, म्हणजेच संदेश ब्रोकरसह सर्व घटक डुप्लिकेट असले पाहिजेत. आम्ही सीएलएलएम प्रणाली वापरून ही समस्या सोडवली: त्यात एक आरसीएमएस क्लस्टर आहे ज्यामध्ये दोन डिस्पॅचर मास्टर-स्लेव्ह मोडमध्ये काम करू शकतात आणि जेव्हा एक अयशस्वी होतो, तेव्हा सिस्टम आपोआप दुसऱ्यावर स्विच करते.

बॅकअप डेटा सेंटरसह कार्य करणे

InfiniBand स्थानिक नेटवर्क म्हणून ऑपरेशनसाठी ऑप्टिमाइझ केले आहे, म्हणजे, रॅक-माउंट उपकरणे कनेक्ट करण्यासाठी, आणि दोन भौगोलिकदृष्ट्या वितरित डेटा केंद्रांमध्ये InfiniBand नेटवर्क ठेवता येत नाही. म्हणून, आम्ही एक ब्रिज/डिस्पॅचर कार्यान्वित केला, जो मेसेज स्टोरेजला नियमित इथरनेट नेटवर्कद्वारे जोडतो आणि सर्व व्यवहार दुसऱ्या IB नेटवर्कवर रिले करतो. जेव्हा आम्हाला डेटा सेंटरमधून स्थलांतर करण्याची आवश्यकता असते, तेव्हा आम्ही आता कोणत्या डेटा सेंटरसह कार्य करायचे ते निवडू शकतो.

परिणाम

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

प्रणाली जोरदारपणे अद्यतनित केली असल्याने, आम्ही दोन स्वतंत्र स्त्रोतांकडून डेटा पुनर्प्राप्ती लागू केली. जर संदेश स्टोअर काही कारणास्तव योग्यरित्या कार्य करत नसेल, तर तुम्ही व्यवहार लॉग दुसऱ्या स्त्रोताकडून - जोखीम इंजिनमधून घेऊ शकता. हे तत्त्व संपूर्ण प्रणालीमध्ये पाळले जाते.

इतर गोष्टींबरोबरच, आम्ही क्लायंट API जतन करण्यात सक्षम होतो जेणेकरून ब्रोकर किंवा इतर कोणालाही नवीन आर्किटेक्चरसाठी महत्त्वपूर्ण पुनर्रचना करण्याची आवश्यकता भासणार नाही. आम्हाला काही इंटरफेस बदलावे लागले, परंतु ऑपरेटिंग मॉडेलमध्ये महत्त्वपूर्ण बदल करण्याची आवश्यकता नव्हती.

आम्ही आमच्या प्लॅटफॉर्मच्या वर्तमान आवृत्तीला Rebus म्हटले - आर्किटेक्चरमधील दोन सर्वात लक्षणीय नवकल्पनांसाठी संक्षिप्त रूप म्हणून, रिस्क इंजिन आणि BUS.

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

आम्ही शेवटी काय साध्य केले:

विलंब पातळी कमी केली. थोड्या प्रमाणात व्यवहारांसह, सिस्टम मागील आवृत्तीप्रमाणेच कार्य करते, परंतु त्याच वेळी जास्त भार सहन करू शकते.

पीक कामगिरी प्रति सेकंद 50 हजार ते 180 हजार व्यवहार वाढली. ऑर्डर जुळण्याच्या एकमेव प्रवाहामुळे आणखी वाढ बाधित आहे.

पुढील सुधारणेसाठी दोन मार्ग आहेत: समांतर जुळणी करणे आणि गेटवे सह कार्य करण्याची पद्धत बदलणे. आता सर्व गेटवे प्रतिकृती योजनेनुसार कार्य करतात, जे अशा लोड अंतर्गत, सामान्यपणे कार्य करणे थांबवते.

शेवटी, जे एंटरप्राइझ सिस्टमला अंतिम स्वरूप देत आहेत त्यांना मी काही सल्ला देऊ शकतो:

• प्रत्येक वेळी सर्वात वाईटसाठी तयार रहा. समस्या नेहमीच अनपेक्षितपणे उद्भवतात.
• वास्तुकला त्वरीत रीमेक करणे सहसा अशक्य आहे. विशेषत: जर तुम्हाला एकाधिक निर्देशकांमध्ये जास्तीत जास्त विश्वासार्हता प्राप्त करण्याची आवश्यकता असेल. अधिक नोड्स, समर्थनासाठी अधिक संसाधने आवश्यक आहेत.
• सर्व सानुकूल आणि मालकी समाधानांना संशोधन, समर्थन आणि देखरेखीसाठी अतिरिक्त संसाधनांची आवश्यकता असेल.
• अयशस्वी झाल्यानंतर सिस्टम विश्वासार्हता आणि पुनर्प्राप्ती समस्यांचे निराकरण करणे टाळू नका; प्रारंभिक डिझाइन टप्प्यावर त्यांना विचारात घ्या.

स्त्रोत: www.habr.com