मस्को एक्सचेन्जको व्यापार र क्लियरिङ प्रणालीको वास्तुकलाको विकास। भाग 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 साझा मेमोरी) पनि सिर्जना गर्‍यो। प्याकेजहरू आफैं यसमा राखिएका थिए, र केवल एउटा ट्यागलाई लाममा भण्डार गरिएको थियो, जसले मूल प्याकेज फेला पार्न अनुमति दिन्छ। यसले प्रोसेसर क्यासमा डाटा भण्डारण गर्न मद्दत गर्यो।

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 लाममा लाइनमा छन्, कोरहरू अलग गर्न सकिन्छ, कुनै निष्कासन हुँदैन, सबै लेनदेनहरू कडा अनुक्रममा प्रशोधन गरिन्छ।

रातो - नियमित कर्नेलमा लामसँग काम गर्दै, हरियो - वास्तविक-समय कर्नेलमा काम गर्दै।

तर नियमित सर्भरहरूमा कम विलम्बता प्राप्त गर्न यति सजिलो छैन:

• SMI मोड, जुन x86 आर्किटेक्चरमा महत्त्वपूर्ण बाह्य उपकरणहरूसँग काम गर्ने आधार हो, धेरै हस्तक्षेप गर्दछ। सबै प्रकारका हार्डवेयर घटनाहरूको प्रशोधन र कम्पोनेन्टहरू र उपकरणहरूको व्यवस्थापन फर्मवेयरद्वारा तथाकथित पारदर्शी SMI मोडमा गरिन्छ, जसमा अपरेटिङ सिस्टमले फर्मवेयरले के गरिरहेको छ भनेर देख्दैन। नियमको रूपमा, सबै प्रमुख विक्रेताहरूले फर्मवेयर सर्भरहरूको लागि विशेष विस्तारहरू प्रस्ताव गर्छन् जसले SMI प्रशोधनको मात्रा घटाउन अनुमति दिन्छ।
• प्रोसेसर फ्रिक्वेन्सीको कुनै गतिशील नियन्त्रण हुनु हुँदैन, यसले अतिरिक्त डाउनटाइम निम्त्याउँछ।
• जब फाइल प्रणाली लग फ्लश हुन्छ, केहि प्रक्रियाहरू कर्नेलमा हुन्छन् जसले अप्रत्याशित ढिलाइ निम्त्याउँछ।
• तपाईंले CPU Affinity, Interrupt affinity, NUMA जस्ता कुराहरूमा ध्यान दिन आवश्यक छ।

मैले भन्नै पर्छ कि लिनक्स हार्डवेयर र कर्नेल रियलटाइम प्रोसेसिंगको लागि सेटअप गर्ने विषय छुट्टै लेखको योग्य छ। हामीले राम्रो नतिजा प्राप्त गर्नु अघि हामीले धेरै समय प्रयोग र अनुसन्धानमा बितायौं।

PA-RISC सर्भरबाट x86 मा सार्दा, हामीले व्यावहारिक रूपमा प्रणाली कोड धेरै परिवर्तन गर्नुपर्दैन, हामीले भर्खर यसलाई अनुकूलन र पुन: कन्फिगर गर्यौं। एकै समयमा, हामीले धेरै बगहरू फिक्स गर्यौं। उदाहरण को लागी, तथ्य को नतिजा कि PA RISC एक ठूलो एन्डियन प्रणाली थियो, र x86 एक सानो endian प्रणाली थियो, छिट्टै देखा पर्यो: उदाहरण को लागी, डाटा गलत पढिएको थियो। PA RISC ले प्रयोग गरेको ट्रिकियर बग थियो लगातार सुसंगत (क्रमशः सुसंगत) मेमोरी पहुँच, जहाँ x86 ले पढ्ने अपरेसनहरू पुन: क्रमबद्ध गर्न सक्छ, त्यसैले कोड जुन एक प्लेटफर्ममा बिल्कुल मान्य थियो अर्कोमा बिग्रियो।

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

अब प्रणाली वास्तुकलामा कुन प्रमुख परिवर्तनहरू गरिएका छन् भन्ने बारे नजिकबाट हेरौं।

तातो रिजर्व महाकाव्य

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

साथै, त्यहाँ अन्य आवश्यकताहरू थिए:

• कुनै पनि परिस्थितिमा तपाईंले प्रशोधित लेनदेनहरू गुमाउनु हुँदैन।
• हाम्रो पूर्वाधारमा प्रणाली पूर्ण रूपमा पारदर्शी हुनुपर्छ।
• ग्राहकहरूले छाडिएको जडानहरू देख्नु हुँदैन।
• रिजर्भेसनले महत्त्वपूर्ण ढिलाइ पेश गर्नु हुँदैन किनभने यो विनिमयको लागि महत्त्वपूर्ण कारक हो।

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

नतिजाको रूपमा, हामी निम्न योजनामा ​​आएका छौं:

• मुख्य सर्भरले गेटवे सर्भरहरूसँग सीधा अन्तरक्रिया गर्यो।
• मुख्य सर्भरमा प्राप्त भएका सबै लेनदेनहरू तुरुन्तै छुट्टै च्यानल मार्फत ब्याकअप सर्भरमा प्रतिलिपि गरियो। मध्यस्थ (राज्यपाल) ले कुनै समस्या उत्पन्न भएमा स्विचिङको समन्वय गर्यो।

  

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

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

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

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

फेरि जारी राखौंला।

स्रोत: www.habr.com