🥇वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक। दूसरा सन्निकटन

घोषणा

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

यह एर्लांग/एलिक्सिर में वितरित प्रतिक्रियाशील अनुप्रयोगों पर श्रृंखला का अंतिम लेख है। में पहला लेख आप प्रतिक्रियाशील वास्तुकला की सैद्धांतिक नींव पा सकते हैं। दूसरा लेख ऐसी प्रणालियों के निर्माण के लिए बुनियादी पैटर्न और तंत्र का वर्णन करता है।

आज हम सामान्य रूप से कोड आधार और परियोजनाओं के विकास के मुद्दे उठाएंगे।

सेवाओं का संगठन

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

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

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

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

उपयोगकर्ता सेवा का औपचारिक विवरण अधिक जटिल हो गया है। एक प्रोग्रामर के दृष्टिकोण से, मैसेजिंग के उपयोग के कारण परिवर्तन न्यूनतम होते हैं। पहली आवश्यकता को पूरा करने के लिए, हमें req-resp विनिमय बिंदु पर संतुलन को कॉन्फ़िगर करने की आवश्यकता है।

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

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

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

नेता की पसंद

वितरित प्रणालियों में, नेता का चुनाव कुछ भार के वितरित प्रसंस्करण को शेड्यूल करने के लिए जिम्मेदार एकल प्रक्रिया को नियुक्त करने की प्रक्रिया है।

ऐसी प्रणालियों में, जिनमें केंद्रीकरण की संभावना नहीं होती, सार्वभौमिक और सर्वसम्मति-आधारित एल्गोरिदम, जैसे पैक्सो या राफ्ट, का उपयोग किया जाता है।
चूंकि मैसेजिंग एक दलाल और एक केंद्रीय तत्व है, यह सभी सेवा नियंत्रकों - उम्मीदवार नेताओं के बारे में जानता है। मैसेजिंग बिना वोटिंग के किसी नेता की नियुक्ति कर सकती है.

एक्सचेंज प्वाइंट शुरू करने और कनेक्ट करने के बाद, सभी सेवाओं को एक सिस्टम संदेश प्राप्त होता है #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. अगर LeaderPid के साथ मेल खाता है pid वर्तमान प्रक्रिया में, इसे नेता और सूची के रूप में नियुक्त किया जाता है Servers इसमें सभी नोड्स और उनके पैरामीटर शामिल हैं।
जिस समय एक नया प्रकट होता है और एक कार्यशील क्लस्टर नोड डिस्कनेक्ट हो जाता है, सभी सेवा नियंत्रक प्राप्त होते हैं #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} क्रमशः.

इस तरह, सभी घटकों को सभी परिवर्तनों के बारे में पता होता है, और क्लस्टर को किसी भी समय एक लीडर होने की गारंटी होती है।

बिचौलियों

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

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

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

आइए कल्पना करें कि हमारे पास "समाचार" विषय पर 50000 ग्राहक हैं। सब्सक्राइबर्स को 5 सर्वरों पर समान रूप से वितरित किया जाता है। परिणामस्वरूप, एक्सचेंज बिंदु पर पहुंचने वाले प्रत्येक अपडेट को 50000 बार दोहराया जाएगा: प्रत्येक सर्वर पर 10000 बार, उस पर ग्राहकों की संख्या के अनुसार। बहुत प्रभावी योजना नहीं है, है ना?
स्थिति को सुधारने के लिए, आइए एक प्रॉक्सी का परिचय दें जिसका नाम विनिमय बिंदु के समान है। वैश्विक नाम रजिस्ट्रार को निकटतम प्रक्रिया को नाम से लौटाने में सक्षम होना चाहिए, यह महत्वपूर्ण है।

आइए इस प्रॉक्सी को एक्सेस लेयर सर्वर पर लॉन्च करें, और वेबसॉकेट एपीआई की सेवा करने वाली हमारी सभी प्रक्रियाएं इसकी सदस्यता लेंगी, न कि कर्नेल में मूल पब-सब एक्सचेंज पॉइंट की। प्रॉक्सी केवल एक अद्वितीय सदस्यता के मामले में कोर की सदस्यता लेता है और अपने सभी ग्राहकों के लिए आने वाले संदेश को दोहराता है।
परिणामस्वरूप, कर्नेल और एक्सेस सर्वर के बीच 5 के बजाय 50000 संदेश भेजे जाएंगे।

रूटिंग और संतुलन

अनुरोध-सम्मान

वर्तमान मैसेजिंग कार्यान्वयन में, 7 अनुरोध वितरण रणनीतियाँ हैं:

default. अनुरोध सभी नियंत्रकों को भेजा गया है।
round-robin. अनुरोधों की गणना की जाती है और नियंत्रकों के बीच चक्रीय रूप से वितरित किया जाता है।
consensus. सेवा प्रदान करने वाले नियंत्रकों को नेताओं और दासों में विभाजित किया गया है। अनुरोध केवल नेता को भेजे जाते हैं।
consensus & round-robin. समूह में एक नेता होता है, लेकिन अनुरोध सभी सदस्यों के बीच वितरित किए जाते हैं।
sticky. हैश फ़ंक्शन की गणना की जाती है और उसे एक विशिष्ट हैंडलर को सौंपा जाता है। इस हस्ताक्षर के साथ बाद के अनुरोध उसी हैंडलर के पास जाते हैं।
sticky-fun. विनिमय बिंदु प्रारंभ करते समय, हैश गणना फ़ंक्शन के लिए sticky संतुलन.
fun. स्टिकी-फन के समान, केवल आप ही इसे अतिरिक्त रूप से रीडायरेक्ट, अस्वीकार या प्री-प्रोसेस कर सकते हैं।

वितरण रणनीति तब निर्धारित की जाती है जब विनिमय बिंदु आरंभ किया जाता है।

संतुलन के अलावा, मैसेजिंग आपको संस्थाओं को टैग करने की अनुमति देता है। आइए सिस्टम में टैग के प्रकारों पर नजर डालें:

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

पब-उप

पब-सब के लिए सब कुछ थोड़ा सरल है। हमारे पास एक विनिमय बिंदु है जिस पर संदेश प्रकाशित होते हैं। एक्सचेंज प्वाइंट उन ग्राहकों के बीच संदेश वितरित करता है जिन्होंने उन रूटिंग कुंजियों की सदस्यता ली है जिनकी उन्हें आवश्यकता है (हम कह सकते हैं कि यह विषयों के अनुरूप है)।

स्केलेबिलिटी और दोष सहनशीलता

संपूर्ण सिस्टम की स्केलेबिलिटी सिस्टम की परतों और घटकों की स्केलेबिलिटी की डिग्री पर निर्भर करती है:

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

किसी प्रोजेक्ट की सफलता अक्सर स्केलिंग की सरलता और गति पर निर्भर करती है। इसके वर्तमान संस्करण में मैसेजिंग एप्लिकेशन के साथ-साथ बढ़ती है। भले ही हमारे पास 50-60 मशीनों के क्लस्टर की कमी हो, हम फेडरेशन का सहारा ले सकते हैं। दुर्भाग्य से, महासंघ का विषय इस लेख के दायरे से बाहर है।

आरक्षण

लोड संतुलन का विश्लेषण करते समय, हमने पहले ही सेवा नियंत्रकों की अतिरेक पर चर्चा की थी। हालाँकि, मैसेजिंग भी आरक्षित होनी चाहिए। नोड या मशीन क्रैश होने की स्थिति में, मैसेजिंग स्वचालित रूप से और कम से कम संभव समय में ठीक हो जानी चाहिए।

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

निष्पादन

आइए कम से कम मोटे तौर पर RabbitMQ और हमारे कस्टम मैसेजिंग के प्रदर्शन की तुलना करने का प्रयास करें।
मुझे मिला आधिकारिक परिणाम ओपनस्टैक टीम से RabbitMQ परीक्षण।

अनुच्छेद 6.14.1.2.1.2.2 में। मूल दस्तावेज़ RPC CAST का परिणाम दिखाता है:

हम पहले से OS कर्नेल या erlang VM में कोई अतिरिक्त सेटिंग नहीं करेंगे। परीक्षण के लिए शर्तें:

erl विकल्प: +A1 +sbtu.
एकल एरलांग नोड के भीतर परीक्षण मोबाइल संस्करण में पुराने i7 वाले लैपटॉप पर चलाया जाता है।
क्लस्टर परीक्षण 10G नेटवर्क वाले सर्वर पर किए जाते हैं।
कोड डॉकटर कंटेनरों में चलता है। NAT मोड में नेटवर्क.

परीक्षण कोड:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

1 स्क्रिप्ट: परीक्षण पुराने i7 मोबाइल संस्करण वाले लैपटॉप पर चलाया जाता है। परीक्षण, संदेश और सेवा को एक डॉकर कंटेनर में एक नोड पर निष्पादित किया जाता है:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

2 स्क्रिप्ट: डॉकर (NAT) के तहत विभिन्न मशीनों पर 3 नोड चल रहे हैं।

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

सभी मामलों में, CPU उपयोग 250% से अधिक नहीं था

परिणाम

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

फ़ोटो @chuttersnap

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

वीट्रेड प्रयोग श्रृंखला के भाग के रूप में मुझे किन विषयों को अधिक विस्तार से शामिल करना चाहिए?

सिद्धांत: बाज़ार, ऑर्डर और उनका समय: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
ऑर्डर की किताब. समूहों के साथ किसी पुस्तक को लागू करने का सिद्धांत और अभ्यास
ट्रेडिंग का विज़ुअलाइज़ेशन: टिक, बार, रिज़ॉल्यूशन। कैसे स्टोर करें और कैसे चिपकाएं
बैक कार्यालय। योजना एवं विकास. कर्मचारी निगरानी और घटना की जांच
एपीआई. आइए जानें कि किन इंटरफेस की आवश्यकता है और उन्हें कैसे लागू किया जाए
सूचना भंडारण: ट्रेडिंग सिस्टम में PostgreSQL, Timescale, टारनटूल
ट्रेडिंग सिस्टम में प्रतिक्रियाशीलता
अन्य। मैं टिप्पणियों में लिखूंगा

6 उपयोगकर्ताओं ने मतदान किया। 4 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

वितरित अनुप्रयोगों के बिल्डिंग ब्लॉक. दूसरा सन्निकटन