🚣🏽 🧕🏽 🈷️ चिड़ियाघर कीपर या वितरित लॉक सेवा लिखें 🛷 👨🏼‍🔬 🥋

अस्वीकरण ऐसा हुआ कि पिछले महीने के लिए मैं ज़ूकिपर के साथ छंटनी कर रहा हूं, और मुझे यह पता लगाने की इच्छा थी कि मुझे क्या मिला, वास्तव में इसके बारे में पोस्ट, और लॉक सेवा के बारे में नहीं, जैसा कि आप नाम से सोच सकते हैं। चलो चलते हैं!

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

वितरित लॉक सेवा की आवश्यकता उचित है:

नेटवर्क ब्लिंकिंग की स्थितियों में काम करने की क्षमता (वितरित सिस्टम का पहला नियम यह है ~~कि वितरित सिस्टम के बारे में बात करने के लिए~~ नेटवर्क अविश्वसनीय ~~नहीं है~~ )
विफलता के एक भी बिंदु की कमी

ZooKeeper हमें इस तरह की सेवा बनाने में मदद करेगा।

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

मुख्य स्थान एक पेड़ बनाता है (फाइल सिस्टम के समान पदानुक्रम)
मूल्यों को पदानुक्रम के किसी भी नोड में समाहित किया जा सकता है, और केवल पत्तियों में नहीं (जैसे कि फाइलें एक ही समय में निर्देशिका भी थीं), पदानुक्रम नोड को znode कहा जाता है
क्लाइंट और सर्वर के बीच द्विदिश संचार है, इसलिए, ग्राहक को एक विशिष्ट मूल्य या एक पदानुक्रम के हिस्से में परिवर्तन के रूप में सदस्यता ली जा सकती है
एक अस्थायी कुंजी / मान युग्म बनाना संभव है जो मौजूद है जबकि ग्राहक जिसने इसे बनाया है वह क्लस्टर से जुड़ा है
सभी डेटा स्मृति में फिट होना चाहिए
क्लस्टर नोड्स की गैर-महत्वपूर्ण संख्या की मृत्यु प्रतिरोध

एक अपरिचित प्रणाली के साथ परिचित होना सबसे पहले एपीआई के साथ शुरू होना चाहिए जो इसे प्रदान करता है, इसलिए

समर्थित कार्य

मौजूद है	znode के अस्तित्व की जाँच करता है और उसका मेटाडेटा लौटाता है
बनाने	znode बनाता है
हटाना	znode निकालता है
GetData	डेटा znode के साथ जुड़ा हुआ है
setData	नए डेटा को znode के साथ जोड़ता है
getChildren	निर्दिष्ट znode के बच्चे हो जाते हैं
सिंक	क्लस्टर नोड के सिंक्रनाइज़ेशन की प्रतीक्षा कर रहे हैं जिससे हम जुड़े हुए हैं, और विज़ार्ड।

इन ऑपरेशनों को निम्नलिखित समूहों में विभाजित किया जा सकता है

कॉलबैक	कैस
मौजूद है	हटाना
GetData	setData
getChildren		बनाने
		सिंक

कॉलबैक - रीड-ओनली ऑपरेशंस जिसके लिए कॉलबैक को इंगित किया जा सकता है, अनुरोधित इकाई में परिवर्तन होने पर कॉलबैक काम करेगा। कॉलबैक एक बार से अधिक काम नहीं करेगा, इस मामले में जब आपको लगातार मूल्य की निगरानी करने की आवश्यकता होती है, तो आपको इवेंट हैंडलर में लगातार साइन-इन करने की आवश्यकता होती है ।

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

create - एक नया znode (key / value pair) बनाता है और कुंजी देता है। यह अजीब लगता है कि कुंजी को एक तर्क के रूप में इंगित करने पर लौटा दिया जाता है, लेकिन तथ्य यह है कि चिड़ियाघर कीपर को कुंजी के साथ उपसर्ग किया जा सकता है और कह सकते हैं कि ज़ेनोड अनुक्रमिक है, फिर एक उप संख्या को उपसर्ग में जोड़ा जाएगा और परिणाम को कुंजी के रूप में उपयोग किया जाएगा। यह गारंटी है कि एक ही उपसर्ग के साथ अनुक्रमिक ज़नोड बनाकर, कुंजियाँ एक वृद्धि (लेक्सिको-ग्राफिक अर्थ में) अनुक्रम बनाएंगी ।

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

ज़नोड, अल्पकालिक और अनुक्रमिक दोनों हो सकता है।

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

उनके हटाने के लिए लगातार पंचांग znode और सदस्यता के आधार पर, आप ~~आसानी से~~ एक वितरित लॉक सिस्टम बना सकते ~~हैं~~ ।

वितरित लॉक सिस्टम

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

एक उपसर्ग के रूप में "_locknode_ / guide-lock-" का उपयोग करके एक अल्पकालिक सीरियल ज़नोड बनाएं, जहां _locknode_ उस संसाधन का नाम है जिसे हम लॉक कर रहे हैं, और गाइड हौसले से जेनरेट किया गया गाइड है
हमें घटना की सदस्यता लिए बिना बच्चों की सूची _locknode_ मिलती है
यदि पहले चरण में बनाए गए znode में कुंजी में न्यूनतम संख्यात्मक प्रत्यय है: एल्गोरिथ्म से बाहर निकलें - हमने संसाधन को पकड़ लिया
अन्यथा, हम प्रत्यय द्वारा बच्चों की सूची को सॉर्ट करते हैं और कॉल ज़ोनोड पर कॉलबैक के साथ मौजूद है, जो कि चरण 1 में हमने जो बनाया है उससे पहले सूची में है
यदि आप झूठे हैं, तो चरण 2 पर जाएं, अन्यथा हम घटना की प्रतीक्षा कर रहे हैं और चरण 2 पर जाएं

सामग्री की आत्मसात की जांच करने के लिए, इसे स्वयं समझने की कोशिश करें, अवरोही या आरोही क्रम में, आपको चरण 4 में सूची को सॉर्ट करने की आवश्यकता है।

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

वैसे, मैंने ऐसा नहीं कहा था, लेकिन मुझे लगता है कि आपने पहले ही अनुमान लगा लिया था कि क्रमिक शून्य के लिए प्रत्यय की गणना करने के लिए, यह उपसर्ग के लिए एक अद्वितीय अनुक्रम नहीं है, लेकिन माता-पिता के लिए एक अद्वितीय अनुक्रम जिसमें ज़नोड बनाया जाएगा।

WTF

सिद्धांत रूप में, कोई भी खत्म कर सकता था, लेकिन जैसा कि अभ्यास से पता चला है, सबसे दिलचस्प शुरू होता है - wtf की। Wtf से, मेरा मतलब है कि सिस्टम और इसके वास्तविक व्यवहार, ध्यान, wtf के बारे में मेरे सहज विचारों के बीच विसंगति एक मूल्य निर्णय नहीं लेती है, इसके अलावा, मैं पूरी तरह से समझता हूं कि चिड़ियाघरकीपर के रचनाकारों ने इस तरह के वास्तु निर्णय क्यों किए।

डब्ल्यूटीएफ # 1 - हम कोड को अंदर बाहर करते हैं

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

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

क्या यह आपको कुछ याद दिलाता है? एक ओर - घटनाओं, दूसरे पर - कार्यक्रम के प्रवाह के साथ "खेलने" की आवश्यकता है, मेरी राय में निरंतरता और मोनाड के पास कहीं।

सामान्य तौर पर, मैंने प्रोग्राम के चरणों को रूप में तैयार किया है:

public interface Task { Task continueWith(Task continuation); //     void run(Executor context, Object arg); //   void error(Executor context, Exception error); //  ,    -   }

निष्पादक कहां है

 public interface Executor { void execute(Task task, Object arg, Timer timeout); // timeout     / TimeoutException  error ,   real-time }

आवश्यक कॉम्बिनेटरों को जोड़ते हुए, आप निम्नलिखित कार्यक्रमों का निर्माण कर सकते हैं, कहीं कदमों की उदासीनता का उपयोग कर रहे हैं, कहीं स्पष्ट रूप से गारबेज की सफाई कर रहे हैं:

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

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

डब्ल्यूटीएफ # 2 - मुख्य सर्वर

हम कह सकते हैं कि ज़ूकीपर में सर्वर (क्लस्टर) मुख्य है, और ग्राहकों को व्यावहारिक रूप से कोई अधिकार नहीं है। कभी-कभी यह पूर्णता में जाता है, उदाहरण के लिए ... चिड़ियाघरकीपर कॉन्फ़िगरेशन में सत्र टाइमआउट के रूप में एक ऐसा पैरामीटर है, यह निर्धारित करता है कि क्लस्टर और क्लाइंट के बीच का कनेक्शन कितना गायब हो सकता है, यदि अधिकतम पार हो गया है, तो इस क्लाइंट का सत्र बंद हो जाएगा और इस ग्राहक के सभी पंचांग znode को हटा दिया जाएगा; यदि कनेक्शन पुनर्स्थापित किया जाता है, तो क्लाइंट SESSIONEXPIRED ईवेंट प्राप्त करेगा। इसलिए, जब कनेक्शन खो जाता है (CONNECTIONLOSS) और सत्र का समय समाप्त हो जाता है, तो यह मूर्खतापूर्ण इंतजार करता है और कुछ भी नहीं करता है, हालांकि, विचार के अनुसार, वह अनुमान लगा सकता था कि सत्र मृत था और अपने हैंडलर को SESSIONEXPOSED फेंक दिया।

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

दिलचस्प बात यह है कि यह परिदृश्य आपको उत्पादन पर ज़ूकेर को मूल रूप से अपडेट करने की अनुमति देता है:

ज़ुकीपर बंद करें - सभी ग्राहक CONNECTIONLOSS राज्य में जाते हैं
ZooKeeper अपडेट कर रहा है
हम ZooKeeper को चालू करते हैं, सर्वर के साथ कनेक्शन बहाल किया गया था, लेकिन सर्वर SESSIONEXPIRED को नहीं भेजता है, क्योंकि डिस्कनेक्शन के समय को सर्वर के सापेक्ष रोक दिया गया था

वैसे, यह इस व्यवहार के कारण ठीक है कि मैं एक्ज़ीक्यूशन टाइमर के पास जाता हूं, जो टास्क के निष्पादन को रद्द कर देता है यदि हम बहुत लंबे समय तक कनेक्ट नहीं कर सकते हैं।

डब्ल्यूटीएफ # 3 - इंट ओवरफ्लो

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

क्या करें? यह समय-समय पर / फिर से तैयार करने के लिए आवश्यक है _locknode_ - जबकि इसके साथ जुड़े काउंटर को रीसेट किया जाता है और एक नीरस अनुक्रम के सिद्धांत का फिर से उल्लंघन किया जाता है, लेकिन तथ्य यह है कि znode को केवल तभी हटाया जा सकता है जब इसके कोई बच्चे न हों , और अब अनुमान लगाएं कि _versionnode_ cversion कब रीसेट होता है इसका कोई बच्चा नहीं है जो लॉक एल्गोरिथम को प्रभावित नहीं करता है।

डब्ल्यूटीएफ # 4 - कोरम लिखना लेकिन पढ़ना नहीं

जब ZooKeeper ने राइट रिक्वेस्ट पर ओके किया, तो इसका मतलब है कि डेटा कोरम (क्लस्टर में अधिकांश मशीनें, 3 मशीनों के मामले में, कोरम 2 के होते हैं) को लिखा गया था , लेकिन पढ़ने पर उपयोगकर्ता को उस मशीन से डेटा प्राप्त होता है जिससे वह जुड़ा था। अर्थात्, एक स्थिति संभव है जब उपयोगकर्ता पुराना डेटा प्राप्त करता है।

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

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

उत्पादकता

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

ज़ुकीपर की एक और विशेषता यह है कि यह दृढ़ता प्रदान करता है - यह इसके लिए भी आवश्यक है, क्योंकि डिस्क को लिखने में लगने वाला समय अनुरोध प्रसंस्करण के दौरान शामिल होता है।

और प्रदर्शन का आखिरी झटका अनुरोधों के सख्त आदेश के कारण है - यह सुनिश्चित करने के लिए कि सभी लिखित अनुरोध एक क्लस्टर मशीन के माध्यम से जाते हैं।

मैंने एक स्थानीय लैपटॉप पर परीक्षण किया, हाँ यह दृढ़ता से मिलता जुलता है:

देवोप्स बोरट

बिग डेटा एनालिटिक्स 90% डेपॉप्स है जो वाक्य में 'बेंचमार्क' शब्द का उपयोग करते हैं, इसी वाक्य में 'लैपटॉप' शब्द का भी उपयोग करते हैं।

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

गहन रिकॉर्डिंग के दौरान प्रदर्शन छत लगभग 10K संचालन प्रति सेकंड था, यह लिखने के लिए 1ms लेता है, इसलिए, एक ग्राहक के दृष्टिकोण से, सर्वर प्रति सेकंड 1K संचालन से अधिक तेजी से नहीं चल सकता है।

इसका क्या मतलब है? ऐसी स्थितियों में जब हम डिस्क के खिलाफ आराम नहीं करते हैं (10% के स्तर पर ssd का उपयोग, निष्ठा के लिए, मैंने रैमफ्स के माध्यम से मेमोरी में डेटा डालने की कोशिश भी की - मुझे प्रदर्शन में थोड़ी वृद्धि हुई), हम सीपीयू पर चलते हैं। कुल मिलाकर, यह पता चला कि ज़ूकेपर साइट पर अपने रचनाकारों द्वारा बताए गए अंकों की तुलना में केवल 2 गुना धीमा है, जो यह देखते हुए बुरा नहीं है कि वे जानते हैं कि इससे सब कुछ कैसे प्राप्त किया जाए।

सारांश

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

एक बार फिर, मैं सूची बनाऊंगा कि आपको चिड़ियाघरकीपर के साथ विकास करते समय क्या ध्यान रखना चाहिए:

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

वितरित ताले के बारे में

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

चिड़ियाघरकीपर की जानकारी के लिए कुछ लिंक

zookeeper.apache.org
outerthought.org/blog/435-ot.html
highscalability.com/zookeeper-reliable-scalable-distributed-coordination-system
research.yahoo.com/node/3280

चिड़ियाघर कीपर या वितरित लॉक सेवा लिखें