पांच छात्रों और तीन वितरित की-वैल्यू स्टोर

या जैसा कि हमने ZooKeeper, etcd और Consul KV के लिए क्लाइंट C ++ लाइब्रेरी लिखा है

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



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

इस समस्या को हल करने के लिए डिज़ाइन किया गया विचार, एक ऑस्ट्रेलियाई परामर्श एजेंसी में उत्पन्न हुआ, और हमें, छात्रों की एक छोटी टीम को इसे लागू करना पड़ा, जिसके बारे में मैं आपको बताने जा रहा हूँ।

हम एक पुस्तकालय बनाने में सक्षम थे जो चिड़ियाघरकीपर, कॉर्ड और कॉन्सुल केवी के साथ काम करने के लिए एक सामान्य इंटरफ़ेस प्रदान करता है। लाइब्रेरी C ++ में लिखी गई है, लेकिन अन्य भाषाओं में पोर्ट करने की योजना है।

डेटा मॉडल

तीन अलग-अलग प्रणालियों के लिए एक सामान्य इंटरफ़ेस विकसित करने के लिए, आपको यह समझने की आवश्यकता है कि उनके पास क्या है और वे कैसे भिन्न हैं। चलो ठीक है।

चिड़ियाघर संचालक



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

etcd



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

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

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

कंसूल के.वी.

कोई सख्त पदानुक्रमित संरचना भी नहीं है, लेकिन कंसूल उपस्थिति बना सकती है जो मौजूद है: आप निर्दिष्ट उपसर्ग के साथ सभी कुंजी प्राप्त कर सकते हैं और हटा सकते हैं, अर्थात, कुंजी के "सबट्री" के साथ काम कर सकते हैं। ऐसे प्रश्नों को पुनरावर्ती कहा जाता है। इसके अलावा, कॉन्सल केवल उन चाबियों का चयन कर सकता है जिनमें उपसर्ग के बाद निर्दिष्ट चरित्र शामिल नहीं है, जो तत्काल "बच्चों" की प्राप्ति से मेल खाती है। लेकिन यह याद रखने योग्य है कि यह ठीक एक पदानुक्रमित संरचना की उपस्थिति है: यह एक कुंजी बनाने के लिए काफी संभव है अगर उसके माता-पिता मौजूद नहीं हैं या एक कुंजी को हटा दें जिसमें बच्चे हैं, जबकि बच्चे सिस्टम में संग्रहित रहेंगे।


घड़ियों के बजाय, कंसुल में HTTP अनुरोधों को अवरुद्ध कर रहे हैं। संक्षेप में, डेटा रीडिंग विधि के लिए ये सामान्य कॉल हैं, जिसके लिए अन्य मापदंडों के साथ, डेटा का अंतिम ज्ञात संस्करण इंगित किया गया है। यदि सर्वर पर संबंधित डेटा का वर्तमान संस्करण निर्दिष्ट एक से बड़ा है, तो प्रतिक्रिया तुरंत वापस कर दी जाती है, अन्यथा, जब मूल्य बदलता है। यहां ऐसे सत्र भी हैं जो किसी भी समय चाबियों से जुड़े हो सकते हैं। यह ध्यान देने योग्य है कि, etcd और ZooKeeper के विपरीत, जहां सत्र हटाने से संबंधित कुंजियों को हटाने की ओर जाता है, एक मोड है जहां सत्र बस उनसे अलग है। लेन-देन उपलब्ध हैं, बिना शाखा के, लेकिन सभी प्रकार के चेक के साथ।

इसे सब साथ लाएं

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

• अनुक्रम, कंटेनर और TTL नोड्स समर्थित नहीं हैं
• एसीएल समर्थित नहीं हैं
• यदि यह मौजूद नहीं था, तो सेट विधि एक कुंजी बनाता है (ZK सेटडाटा इस मामले में त्रुटि देता है)
• सेट और कैस तरीके अलग हैं (ZK में, वे मूल रूप से एक ही चीज हैं)
• मिटा विधि उपशीर्षक के साथ-साथ शीर्ष को हटाती है (यदि ZK हटाता है तो त्रुटि एक त्रुटि है)
• प्रत्येक कुंजी के लिए केवल एक संस्करण है - मूल्य का संस्करण (ZK में उनमें से तीन हैं )

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

शीर्ष चिड़ियाघरकीपर को हटाते समय एक ही व्यवहार को लागू करना प्रत्येक कुंजी के लिए etcd और Consul में एक अलग बच्चों के काउंटर को बनाए रखने की आवश्यकता होगी। चूंकि हमने मेटा-सूचनाओं को संग्रहीत करने से बचने की कोशिश की थी, इसलिए संपूर्ण उपप्रकार को हटाने का निर्णय लिया गया था।

कार्यान्वयन की सूक्ष्मता

आइए हम विभिन्न प्रणालियों में लाइब्रेरी इंटरफ़ेस के कार्यान्वयन के कुछ पहलुओं पर अधिक विस्तार से विचार करें।

इत्यादि में पदानुक्रम

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

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

फिर आप रेंज ["\u02/foo/", "\u02/foo0") को क्वेरी करके "/foo" कुंजी के सभी तत्काल बच्चे प्राप्त कर सकते हैं। हां, ASCII में, "0" तुरंत "/" अनुसरण करता है।

लेकिन कैसे, फिर, एक शीर्ष को हटाने के लिए? यह पता चला है कि आपको XX से 01 से एफएफ के लिए फॉर्म की सभी सीमाओं को हटाने की जरूरत है ["\uXX/foo/", "\uXX/foo0") । और फिर हम एक लेनदेन के भीतर संचालन की संख्या पर एक सीमा में भाग गए।

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

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

फिर "/very" कुंजी को हटाने से "/\u00very" और श्रेणी ["/very/", "/very0") को हटाने में बदल जाता है, और सभी बच्चों को सीमा से कुंजी के लिए अनुरोध करने में मदद ["/very/\u00", "/very/\u01") ।

चिड़ियाघर कीपर में एक चाबी निकालना

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

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

चिड़ियाघरकीपर में सेट

चिड़ियाघरकीपर में, अलग-अलग विधियाँ होती हैं जो ट्री स्ट्रक्चर (क्रिएट, डिलीट, गेट-चिल्ड्रेन) के साथ काम करती हैं और वह डेटा नोड्स (सेटडाटा, गेटडाटा) में काम करती हैं। इसके अलावा, सभी तरीकों में सख्त पूर्व शर्त होती हैं: यदि नोड पहले से ही बना है, तो एक त्रुटि वापस करेगा। setData - यदि यह अभी तक मौजूद नहीं है। हमें सेट विधि की आवश्यकता थी, जिसे कुंजी के बारे में सोचे बिना बुलाया जा सकता है।

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

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

अधिक तकनीकी विवरण

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

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

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

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

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

परिणाम

खुद के लिए देखें: liboffkv

हमारी टीम: रायड रोमानोव , इवान ग्लुशेनकोव , दिमित्री कमलडिनोव , विक्टर क्रैपिवेंस्की , विटाली इवान ।