🥇 वितरीत केलेल्या अनुप्रयोगांचे बिल्डिंग ब्लॉक्स. दुसरा अंदाजे

घोषणा

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

Erlang/Elixir मधील वितरित प्रतिक्रियात्मक अनुप्रयोगांवरील मालिकेतील हा अंतिम लेख आहे. IN पहिला लेख आपण प्रतिक्रियाशील आर्किटेक्चरचा सैद्धांतिक पाया शोधू शकता. दुसरा लेख अशा प्रणाली तयार करण्यासाठी मूलभूत नमुने आणि यंत्रणा स्पष्ट करते.

आज आम्ही कोड बेस आणि सर्वसाधारणपणे प्रकल्पांच्या विकासाचे मुद्दे मांडू.

सेवा संस्था

वास्तविक जीवनात, सेवा विकसित करताना, तुम्हाला अनेकदा एका कंट्रोलरमध्ये अनेक परस्परसंवाद नमुने एकत्र करावे लागतात. उदाहरणार्थ, वापरकर्ता सेवा, जी प्रकल्प वापरकर्ता प्रोफाइल व्यवस्थापित करण्याच्या समस्येचे निराकरण करते, त्यांनी req-resp विनंत्यांना प्रतिसाद दिला पाहिजे आणि pub-sub द्वारे प्रोफाइल अद्यतनांचा अहवाल दिला पाहिजे. हे प्रकरण अगदी सोपे आहे: मेसेजिंगच्या मागे एक नियंत्रक आहे जो सेवा तर्क लागू करतो आणि अद्यतने प्रकाशित करतो.

जेव्हा आम्हाला दोष-सहिष्णु वितरित सेवा लागू करण्याची आवश्यकता असते तेव्हा परिस्थिती अधिक गुंतागुंतीची होते. चला कल्पना करूया की वापरकर्त्यांसाठी आवश्यकता बदलल्या आहेत:

आता सेवेने 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} अनुक्रमे

अशा प्रकारे, सर्व घटकांना सर्व बदलांची जाणीव असते आणि क्लस्टरला कोणत्याही वेळी एक नेता असण्याची हमी दिली जाते.

मध्यस्थ

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

पब-सब ऑप्टिमायझेशनचे उत्कृष्ट उदाहरण म्हणजे बिझनेस कोअरसह वितरित केलेले अॅप्लिकेशन जे अपडेट इव्हेंट्स व्युत्पन्न करते, जसे की मार्केटमधील किंमतीतील बदल आणि ऍक्सेस लेयर - N सर्व्हर जे वेब क्लायंटसाठी वेबसॉकेट API प्रदान करतात.
आपण हेड-ऑन ठरवल्यास, ग्राहक सेवा यासारखी दिसते:

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

चला कल्पना करूया की आमच्याकडे “बातम्या” विषयाचे 50000 सदस्य आहेत. सदस्य 5 सर्व्हरवर समान रीतीने वितरीत केले जातात. परिणामी, एक्सचेंज पॉईंटवर येणारे प्रत्येक अपडेट 50000 वेळा प्रतिकृत केले जाईल: प्रत्येक सर्व्हरवर 10000 वेळा, त्यावरील सदस्यांच्या संख्येनुसार. फार प्रभावी योजना नाही, बरोबर?
परिस्थिती सुधारण्यासाठी, एक प्रॉक्सी सादर करूया ज्याचे नाव एक्सचेंज पॉइंटसारखेच आहे. जागतिक नाव निबंधक नावाने सर्वात जवळची प्रक्रिया परत करण्यास सक्षम असणे आवश्यक आहे, हे महत्वाचे आहे.

चला ही प्रॉक्सी ऍक्सेस लेयर सर्व्हरवर लाँच करूया, आणि वेबसॉकेट एपीआयला सेवा देणार्‍या आमच्या सर्व प्रक्रिया त्याचे सदस्यत्व घेतील, कर्नलमधील मूळ पब-सब एक्सचेंज पॉइंटवर नाही. प्रॉक्सी केवळ अनन्य सबस्क्रिप्शनच्या बाबतीत कोरचे सदस्यत्व घेते आणि येणार्‍या संदेशाची प्रतिकृती तिच्या सर्व सदस्यांना देते.
परिणामी, कर्नल आणि ऍक्सेस सर्व्हर दरम्यान 5 ऐवजी 50000 संदेश पाठवले जातील.

राउटिंग आणि बॅलन्सिंग

विनंती-प्रतिसाद

सध्याच्या मेसेजिंग अंमलबजावणीमध्ये, 7 विनंती वितरण धोरणे आहेत:

default. विनंती सर्व नियंत्रकांना पाठवली आहे.
round-robin. विनंत्या गणना केल्या जातात आणि नियंत्रकांमध्ये चक्रीयपणे वितरीत केल्या जातात.
consensus. सेवा देणारे नियंत्रक नेते आणि गुलामांमध्ये विभागले गेले आहेत. विनंत्या फक्त नेत्याला पाठवल्या जातात.
consensus & round-robin. गटामध्ये एक नेता आहे, परंतु विनंत्या सर्व सदस्यांमध्ये वितरीत केल्या जातात.
sticky. हॅश फंक्शनची गणना केली जाते आणि विशिष्ट हँडलरला नियुक्त केले जाते. या स्वाक्षरीसह त्यानंतरच्या विनंत्या त्याच हँडलरकडे जातात.
sticky-fun. एक्सचेंज पॉइंट सुरू करताना, साठी हॅश गणना कार्य sticky संतुलन
fun. स्टिकी-फन प्रमाणेच, केवळ तुम्ही अतिरिक्तपणे पुनर्निर्देशित करू शकता, नाकारू शकता किंवा पूर्व-प्रक्रिया करू शकता.

जेव्हा एक्सचेंज पॉइंट सुरू केला जातो तेव्हा वितरण धोरण सेट केले जाते.

बॅलन्सिंग व्यतिरिक्त, मेसेजिंग तुम्हाला संस्थांना टॅग करण्याची परवानगी देते. चला सिस्टममधील टॅगचे प्रकार पाहू:

कनेक्शन टॅग. इव्हेंट कोणत्या कनेक्शनद्वारे आले हे समजून घेण्यास अनुमती देते. जेव्हा कंट्रोलर प्रक्रिया समान एक्सचेंज पॉइंटशी कनेक्ट होते, परंतु भिन्न राउटिंग की सह वापरली जाते.
सेवा टॅग. तुम्हाला एका सेवेसाठी हँडलर्सना गटांमध्ये एकत्र करण्याची आणि राउटिंग आणि समतोल क्षमतांचा विस्तार करण्याची अनुमती देते. req-resp पॅटर्नसाठी, राउटिंग रेखीय आहे. आम्ही एक्सचेंज पॉइंटला विनंती पाठवतो, नंतर ती सेवेकडे पाठवते. परंतु जर आपल्याला हँडलर्सना तार्किक गटांमध्ये विभाजित करायचे असेल तर टॅग वापरून विभाजन केले जाते. टॅग निर्दिष्ट करताना, विनंती नियंत्रकांच्या विशिष्ट गटाकडे पाठविली जाईल.
टॅगची विनंती करा. तुम्हाला उत्तरांमध्ये फरक करण्याची अनुमती देते. आमची प्रणाली असिंक्रोनस असल्याने, सेवा प्रतिसादांवर प्रक्रिया करण्यासाठी आम्हाला विनंती पाठवताना एक RequestTag निर्दिष्ट करण्यात सक्षम असणे आवश्यक आहे. त्यावरून आम्हाला कोणत्या विनंतीचे उत्तर आले हे समजू शकेल.

पब-सब

पब-सबसाठी सर्व काही थोडे सोपे आहे. आमच्याकडे एक एक्सचेंज पॉइंट आहे ज्यावर संदेश प्रकाशित केले जातात. एक्सचेंज पॉईंट ग्राहकांमध्ये संदेश वितरीत करतो ज्यांनी त्यांना आवश्यक असलेल्या राउटिंग कीचे सदस्यत्व घेतले आहे (आम्ही असे म्हणू शकतो की हे विषयांशी एकरूप आहे).

स्केलेबिलिटी आणि दोष सहिष्णुता

संपूर्णपणे सिस्टमची स्केलेबिलिटी सिस्टमच्या स्तर आणि घटकांच्या स्केलेबिलिटीच्या डिग्रीवर अवलंबून असते:

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

प्रकल्पाचे यश अनेकदा स्केलिंगच्या साधेपणावर आणि गतीवर अवलंबून असते. त्याच्या वर्तमान आवृत्तीमधील संदेशन अनुप्रयोगासह वाढते. आमच्याकडे 50-60 मशिन्सचा क्लस्टर नसला तरी आम्ही फेडरेशनचा अवलंब करू शकतो. दुर्दैवाने, फेडरेशनचा विषय या लेखाच्या व्याप्तीच्या बाहेर आहे.

आरक्षण

लोड बॅलन्सिंगचे विश्लेषण करताना, आम्ही सेवा नियंत्रकांच्या रिडंडंसीबद्दल आधीच चर्चा केली आहे. तथापि, संदेशवहन देखील आरक्षित करणे आवश्यक आहे. नोड किंवा मशिन क्रॅश झाल्यास, मेसेजिंग आपोआप रिकव्हर व्हायला हवे आणि कमीत कमी वेळेत.

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

उत्पादकता

चला rabbitmq आणि आमच्या कस्टम मेसेजिंगच्या कामगिरीची किमान तुलना करण्याचा प्रयत्न करूया.
मला सापडले अधिकृत परिणाम ओपनस्टॅक संघाकडून rabbitmq चाचणी.

परिच्छेद 6.14.1.2.1.2.2 मध्ये. मूळ दस्तऐवज RPC CAST चा परिणाम दर्शवितो:

आम्ही OS कर्नल किंवा erlang VM वर कोणतीही अतिरिक्त सेटिंग्ज आगाऊ करणार नाही. चाचणीसाठी अटी:

erl opts: +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.

परिस्थिती २: चाचणी जुन्या 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)

परिस्थिती १: डॉकर (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

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

VTrade प्रयोग मालिकेचा भाग म्हणून मी कोणते विषय अधिक तपशीलवार कव्हर करावे?

सिद्धांत: बाजार, ऑर्डर आणि त्यांची वेळ: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC
ऑर्डरचे पुस्तक. समूहीकरणासह पुस्तकाची अंमलबजावणी करण्याचा सिद्धांत आणि सराव
ट्रेडिंगचे व्हिज्युअलायझेशन: टिक्स, बार, रिझोल्यूशन. कसे साठवायचे आणि गोंद कसे
बॅकऑफिस. नियोजन आणि विकास. कर्मचारी निरीक्षण आणि घटना तपास
API कोणते इंटरफेस आवश्यक आहेत आणि ते कसे अंमलात आणायचे ते शोधूया
माहिती स्टोरेज: ट्रेडिंग सिस्टममध्ये PostgreSQL, Timescale, Tarantool
व्यापार प्रणाली मध्ये प्रतिक्रियाशीलता
इतर. मी टिप्पण्यांमध्ये लिहीन

6 वापरकर्त्यांनी मतदान केले. 4 वापरकर्ते दूर राहिले.

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

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