पाच विद्यार्थी आणि तीन वितरित की-व्हॅल्यू स्टोअर

किंवा आम्ही ZooKeeper, etcd आणि Consul KV साठी क्लायंट C++ लायब्ररी कशी लिहिली

वितरित प्रणालींच्या जगात, अनेक वैशिष्ट्यपूर्ण कार्ये आहेत: क्लस्टरच्या रचनेबद्दल माहिती संग्रहित करणे, नोड्सचे कॉन्फिगरेशन व्यवस्थापित करणे, दोषपूर्ण नोड्स शोधणे, नेता निवडणे. आणि इतर. या समस्यांचे निराकरण करण्यासाठी, विशेष वितरित प्रणाली तयार केल्या गेल्या आहेत - समन्वय सेवा. आता आम्हाला त्यापैकी तीनमध्ये रस असेल: ZooKeeper, etcd आणि Consul. Consul च्या सर्व समृद्ध कार्यक्षमतेपैकी, आम्ही Consul KV वर लक्ष केंद्रित करू.

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

या समस्येचे निराकरण करण्याची कल्पना ऑस्ट्रेलियन सल्लागार एजन्सीमध्ये उद्भवली, आणि ती अमलात आणण्यासाठी आमच्याकडे, विद्यार्थ्यांची एक छोटी टीम आली, ज्याबद्दल मी बोलणार आहे.

ZooKeeper, etcd आणि Consul KV सोबत काम करण्यासाठी एक सामान्य इंटरफेस देणारी लायब्ररी आम्ही तयार करण्यात व्यवस्थापित केले. लायब्ररी C++ मध्ये लिहिलेली आहे, परंतु ती इतर भाषांमध्ये पोर्ट करण्याची योजना आहे.

डेटा मॉडेल्स

तीन भिन्न प्रणालींसाठी एक समान इंटरफेस विकसित करण्यासाठी, तुम्हाला त्यांच्यात काय साम्य आहे आणि ते कसे वेगळे आहेत हे समजून घेणे आवश्यक आहे. चला ते बाहेर काढूया.

झूकीपर

कळा एका झाडामध्ये व्यवस्थित केल्या जातात आणि त्यांना नोड्स म्हणतात. त्यानुसार, नोडसाठी आपण त्याच्या मुलांची यादी मिळवू शकता. znode तयार करणे (तयार करणे) आणि मूल्य (setData) बदलण्याचे ऑपरेशन वेगळे केले जातात: फक्त विद्यमान की वाचल्या आणि बदलल्या जाऊ शकतात. घड्याळे नोडचे अस्तित्व तपासणे, मूल्य वाचणे आणि मुले मिळवणे या ऑपरेशन्समध्ये जोडले जाऊ शकतात. वॉच हे एक-वेळचे ट्रिगर आहे जे सर्व्हरवरील संबंधित डेटाची आवृत्ती बदलते तेव्हा सक्रिय होते. तात्पुरते नोड्स अपयश शोधण्यासाठी वापरले जातात. ते तयार केलेल्या क्लायंटच्या सत्राशी जोडलेले आहेत. जेव्हा एखादा क्लायंट सत्र बंद करतो किंवा ZooKeeper ला त्याच्या अस्तित्वाची सूचना देणे थांबवतो तेव्हा हे नोड्स आपोआप हटवले जातात. साधे व्यवहार समर्थित आहेत - ऑपरेशन्सचा एक संच जो एकतर सर्व यशस्वी किंवा अपयशी ठरतो जर त्यापैकी किमान एकासाठी हे शक्य नसेल.

इ

या प्रणालीचे विकासक स्पष्टपणे ZooKeeper द्वारे प्रेरित होते आणि म्हणून सर्वकाही वेगळ्या पद्धतीने केले. कळांची कोणतीही पदानुक्रम नाही, परंतु ते शब्दकोषानुसार क्रमबद्ध संच तयार करतात. तुम्ही विशिष्ट श्रेणीशी संबंधित सर्व की मिळवू किंवा हटवू शकता. ही रचना विचित्र वाटू शकते, परंतु ती प्रत्यक्षात खूप अभिव्यक्त आहे आणि त्याद्वारे श्रेणीबद्ध दृश्य सहजपणे अनुकरण केले जाऊ शकते.

etcd मध्ये मानक तुलना-आणि-सेट ऑपरेशन नाही, परंतु त्यात काहीतरी चांगले आहे: व्यवहार. अर्थात, ते तिन्ही प्रणालींमध्ये अस्तित्वात आहेत, परंतु etcd व्यवहार विशेषतः चांगले आहेत. त्यात तीन ब्लॉक्स असतात: चेक, यश, अपयश. पहिल्या ब्लॉकमध्ये अटींचा संच आहे, दुसरा आणि तिसरा - ऑपरेशन्स. व्यवहार अणु पद्धतीने केला जातो. सर्व अटी सत्य असल्यास, यश ब्लॉक कार्यान्वित केला जातो, अन्यथा अपयश ब्लॉक कार्यान्वित केला जातो. API 3.3 मध्ये, यश आणि अपयश ब्लॉकमध्ये नेस्टेड व्यवहार असू शकतात. म्हणजेच, जवळजवळ अनियंत्रित नेस्टिंग पातळीच्या सशर्त रचना आण्विकपणे कार्यान्वित करणे शक्य आहे. चेक आणि ऑपरेशन्स कशापासून अस्तित्वात आहेत याबद्दल तुम्ही अधिक जाणून घेऊ शकता दस्तऐवजीकरण.

घड्याळे येथे देखील अस्तित्वात आहेत, जरी ते थोडे अधिक क्लिष्ट आहेत आणि पुन्हा वापरण्यायोग्य आहेत. म्हणजेच, की श्रेणीवर घड्याळ स्थापित केल्यानंतर, तुम्ही घड्याळ रद्द करेपर्यंत तुम्हाला या श्रेणीतील सर्व अद्यतने प्राप्त होतील, फक्त पहिलेच नाही. etcd मध्ये, ZooKeeper क्लायंट सत्रांचे analogue लीज आहेत.

कॉन्सुल के.व्ही.

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

घड्याळ्यांऐवजी, कॉन्सुलने HTTP विनंत्या अवरोधित केल्या आहेत. थोडक्यात, हे डेटा वाचन पद्धतीचे सामान्य कॉल आहेत, ज्यासाठी, इतर पॅरामीटर्ससह, डेटाची शेवटची ज्ञात आवृत्ती दर्शविली जाते. सर्व्हरवरील संबंधित डेटाची वर्तमान आवृत्ती निर्दिष्ट केलेल्यापेक्षा मोठी असल्यास, प्रतिसाद त्वरित परत केला जातो, अन्यथा - जेव्हा मूल्य बदलते. अशी सत्रे देखील आहेत जी कधीही की संलग्न केली जाऊ शकतात. हे लक्षात घेण्यासारखे आहे की etcd आणि ZooKeeper च्या विपरीत, जेथे सत्रे हटवण्यामुळे संबंधित की हटवल्या जातात, तेथे एक मोड आहे ज्यामध्ये सत्र त्यांच्यापासून फक्त अनलिंक केले जाते. उपलब्ध व्यवहार, शाखांशिवाय, परंतु सर्व प्रकारच्या धनादेशांसह.

हे सर्व एकत्र ठेवणे

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

• अनुक्रम, कंटेनर आणि TTL नोड्स समर्थित नाही
• ACL समर्थित नाहीत
• जर ती अस्तित्वात नसेल तर सेट पद्धत एक की तयार करते (ZK setData मध्ये या प्रकरणात त्रुटी परत करते)
• सेट आणि कॅस पद्धती विभक्त केल्या आहेत (ZK मध्ये ते मूलत: समान आहेत)
• मिटवण्याची पद्धत नोड त्याच्या सबट्रीसह हटवते (ZK डिलीटमध्ये नोडला मुले असल्यास त्रुटी दाखवते)
• प्रत्येक कीसाठी फक्त एक आवृत्ती आहे - मूल्य आवृत्ती (ZK मध्ये त्यापैकी तीन आहेत)

अनुक्रमिक नोड्स नाकारणे हे या वस्तुस्थितीमुळे आहे की etcd आणि Consul कडे त्यांच्यासाठी अंगभूत समर्थन नाही आणि ते वापरकर्त्याद्वारे परिणामी लायब्ररी इंटरफेसच्या शीर्षस्थानी सहजपणे लागू केले जाऊ शकतात.

व्हर्टेक्स हटवताना ZooKeeper प्रमाणे वागणूक लागू करण्यासाठी etcd आणि Consul मधील प्रत्येक कीसाठी स्वतंत्र चाइल्ड काउंटर राखणे आवश्यक आहे. आम्ही मेटा माहिती संचयित करणे टाळण्याचा प्रयत्न केल्यामुळे, संपूर्ण उपवृक्ष हटविण्याचा निर्णय घेण्यात आला.

अंमलबजावणीची सूक्ष्मता

विविध प्रणालींमध्ये लायब्ररी इंटरफेस लागू करण्याच्या काही पैलूंवर बारकाईने नजर टाकूया.

पदानुक्रम इ

etcd मध्ये श्रेणीबद्ध दृश्य राखणे हे सर्वात मनोरंजक कार्यांपैकी एक ठरले. श्रेणी क्वेरी निर्दिष्ट उपसर्गासह कीची सूची पुनर्प्राप्त करणे सोपे करते. उदाहरणार्थ, आपल्याला यापासून सुरू होणारी प्रत्येक गोष्ट आवश्यक असल्यास "/foo", तुम्ही श्रेणी विचारत आहात ["/foo", "/fop"). परंतु हे कीचे संपूर्ण उपवृक्ष परत करेल, जे उपवृक्ष मोठे असल्यास स्वीकार्य होणार नाही. सुरुवातीला आम्ही मुख्य भाषांतर यंत्रणा वापरण्याची योजना आखली, zetcd मध्ये लागू केले. यात कीच्या सुरूवातीस एक बाइट जोडणे समाविष्ट आहे, झाडाच्या नोडच्या खोलीइतके. मी तुम्हाला एक उदाहरण देतो.

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

मग सर्व तात्काळ मुलांना चावी मिळवा "/foo" श्रेणीची विनंती करून शक्य आहे ["u02/foo/", "u02/foo0"). होय, ASCII मध्ये "0" नंतर उभी आहे "/".

परंतु या प्रकरणात शिरोबिंदू काढण्याची अंमलबजावणी कशी करावी? असे दिसून आले की आपल्याला प्रकाराच्या सर्व श्रेणी हटविण्याची आवश्यकता आहे ["uXX/foo/", "uXX/foo0") XX साठी 01 ते FF पर्यंत. आणि मग आम्ही आत शिरलो ऑपरेशन क्रमांक मर्यादा एका व्यवहारात.

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

मग की हटवत आहे "/very" हटविण्यामध्ये बदलते "/u00very" आणि श्रेणी ["/very/", "/very0"), आणि सर्व मुले मिळवणे - श्रेणीतील चाव्यांच्या विनंतीनुसार ["/very/u00", "/very/u01").

ZooKeeper मधील की काढत आहे

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

या पद्धतीमुळे की हटवणे अत्यंत कुचकामी ठरते, जर त्याला मुले असतील, आणि त्याहूनही अधिक म्हणजे जर ऍप्लिकेशनने सबट्रीसह कार्य करणे, की हटवणे आणि तयार करणे सुरू ठेवले तर. तथापि, यामुळे आम्हाला etcd आणि Consul मधील इतर पद्धतींच्या अंमलबजावणीची गुंतागुंत टाळता आली.

ZooKeeper मध्ये सेट करा

ZooKeeper मध्ये ट्री स्ट्रक्चर (तयार करा, हटवा, getChildren) आणि नोड्समधील डेटासह कार्य करणाऱ्या वेगळ्या पद्धती आहेत (सेटडेटा, गेटडेटा) शिवाय, सर्व पद्धतींमध्ये कठोर पूर्वअटी आहेत: जर नोडमध्ये आधीच त्रुटी असेल तर तयार करा डेटा तयार केला, हटवला किंवा सेट केला - जर तो आधीपासून अस्तित्वात नसेल. आम्हाला एका सेट पद्धतीची आवश्यकता होती जी कीच्या उपस्थितीबद्दल विचार न करता कॉल केली जाऊ शकते.

एक पर्याय म्हणजे हटवण्याप्रमाणे आशावादी दृष्टीकोन घेणे. नोड अस्तित्वात आहे का ते तपासा. अस्तित्वात असल्यास, setData वर कॉल करा, अन्यथा तयार करा. शेवटच्या पद्धतीमध्ये त्रुटी आढळल्यास, ते पुन्हा पुन्हा करा. पहिली गोष्ट लक्षात घ्या की अस्तित्व चाचणी निरर्थक आहे. तुम्ही लगेच तयार कॉल करू शकता. यशस्वी पूर्ण होण्याचा अर्थ असा होईल की नोड अस्तित्वात नव्हता आणि तो तयार केला गेला होता. अन्यथा, तयार केल्याने योग्य त्रुटी येईल, ज्यानंतर तुम्हाला सेटडेटा कॉल करणे आवश्यक आहे. अर्थात, कॉल दरम्यान, प्रतिस्पर्धी कॉलद्वारे एक शिरोबिंदू हटविला जाऊ शकतो आणि सेटडेटा देखील त्रुटी देईल. या प्रकरणात, आपण हे सर्व पुन्हा करू शकता, परंतु ते फायदेशीर आहे का?

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

अधिक तांत्रिक तपशील

या विभागात आम्ही वितरित प्रणालींमधून ब्रेक घेऊ आणि कोडिंगबद्दल बोलू.
ग्राहकांच्या मुख्य आवश्यकतांपैकी एक क्रॉस-प्लॅटफॉर्म होती: किमान एक सेवा Linux, MacOS आणि Windows वर समर्थित असणे आवश्यक आहे. सुरुवातीला, आम्ही फक्त लिनक्ससाठी विकसित केले आणि नंतर इतर प्रणालींवर चाचणी सुरू केली. यामुळे बऱ्याच समस्या निर्माण झाल्या, ज्या काही काळासाठी पूर्णपणे अस्पष्ट होत्या की कसे संपर्क साधावे. परिणामी, तीनही समन्वय सेवा आता Linux आणि MacOS वर समर्थित आहेत, तर Windows वर फक्त Consul KV समर्थित आहेत.

अगदी सुरुवातीपासून, आम्ही सेवांमध्ये प्रवेश करण्यासाठी तयार लायब्ररी वापरण्याचा प्रयत्न केला. ZooKeeper च्या बाबतीत, निवड वर पडली झूकीपर C++, जे शेवटी Windows वर संकलित करण्यात अयशस्वी झाले. तथापि, हे आश्चर्यकारक नाही: लायब्ररी केवळ लिनक्स म्हणून स्थित आहे. कॉन्सुलसाठी एकच पर्याय होता ppconsul. त्यात आधार जोडावा लागला सत्रे и व्यवहार. etcd साठी, प्रोटोकॉलच्या नवीनतम आवृत्तीस समर्थन देणारी पूर्ण वाढ झालेली लायब्ररी आढळली नाही, म्हणून आम्ही फक्त व्युत्पन्न grpc क्लायंट.

ZooKeeper C++ लायब्ररीच्या असिंक्रोनस इंटरफेसने प्रेरित होऊन, आम्ही एक असिंक्रोनस इंटरफेस लागू करण्याचा निर्णय घेतला. ZooKeeper C++ यासाठी भविष्यातील/प्रॉमिस प्रिमिटिव्स वापरते. STL मध्ये, दुर्दैवाने, ते अतिशय विनम्रपणे लागू केले जातात. उदाहरणार्थ, नाही नंतर पद्धत, जे पास केलेले फंक्शन उपलब्ध झाल्यावर भविष्यातील निकालावर लागू करते. आमच्या बाबतीत, निकाल आमच्या लायब्ररीच्या स्वरूपात रूपांतरित करण्यासाठी अशी पद्धत आवश्यक आहे. या समस्येवर मात करण्यासाठी, आम्हाला आमचा स्वतःचा साधा थ्रेड पूल कार्यान्वित करावा लागला, कारण ग्राहकाच्या विनंतीनुसार आम्ही बूस्ट सारख्या जड तृतीय-पक्ष लायब्ररी वापरू शकत नाही.

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

आम्ही समान थ्रेड पूलचा वापर etcd आणि Consul साठी क्वेरी कार्यान्वित करण्यासाठी केला. याचा अर्थ असा की अंतर्निहित लायब्ररींमध्ये अनेक भिन्न थ्रेड्सद्वारे प्रवेश केला जाऊ शकतो. ppconsul थ्रेड सुरक्षित नाही, म्हणून त्यावर कॉल करणे लॉकद्वारे संरक्षित आहे.
तुम्ही एकाधिक थ्रेड्सवरून grpc सह कार्य करू शकता, परंतु त्यात सूक्ष्मता आहेत. etcd मध्ये घड्याळे grpc स्ट्रीमद्वारे लागू केली जातात. हे एका विशिष्ट प्रकारच्या संदेशांसाठी द्विदिशात्मक चॅनेल आहेत. लायब्ररी सर्व घड्याळांसाठी एकच धागा आणि येणाऱ्या संदेशांवर प्रक्रिया करणारा एकच धागा तयार करते. त्यामुळे grpc प्रवाहाला समांतर लेखन प्रतिबंधित करते. याचा अर्थ असा की घड्याळ सुरू करताना किंवा हटवताना, पुढील पाठवण्यापूर्वी मागील विनंती पाठवणे पूर्ण होईपर्यंत तुम्ही प्रतीक्षा करावी. आम्ही सिंक्रोनाइझेशनसाठी वापरतो सशर्त चल.

परिणाम

स्वतःसाठी पहा: liboffkv.

आमचा संघ: रायड रोमानोव्ह, इव्हान ग्लुशेन्कोव्ह, दिमित्री कमलदिनोव्ह, व्हिक्टर क्रॅपिव्हेन्स्की, विटाली इव्हानिन.

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