"हडूप. मेल.आरयू ग्रुप टेक्नोस्ट्रीम श्रृंखला से ज़ूकीपर" "हडोप में बड़ी मात्रा में डेटा के वितरित प्रसंस्करण के तरीके"

मेरा सुझाव है कि आप "Hadoop में बड़ी मात्रा में डेटा के वितरित प्रसंस्करण के तरीके" श्रृंखला से व्याख्यान "Hadoop. ZooKeeper" की प्रतिलेख पढ़ें।

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

आज हम बात करेंगे ज़ूकीपर के बारे में। ये चीज़ बहुत काम की है. किसी भी Apache Hadoop उत्पाद की तरह इसका भी एक लोगो है। इसमें एक आदमी को दर्शाया गया है.

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

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

Hadoop से संबंधित सभी अनुप्रयोगों की तरह, इसे Yahoo! द्वारा विकसित किया गया था। यह अब एक आधिकारिक अपाचे एप्लिकेशन भी है। यह HBase की तरह सक्रिय रूप से विकसित नहीं है। यदि आप JIRA HBase पर जाते हैं, तो हर दिन बग रिपोर्टों का एक समूह, कुछ को अनुकूलित करने के प्रस्तावों का एक समूह होता है, यानी परियोजना में जीवन लगातार चल रहा है। और ज़ूकीपर, एक ओर, अपेक्षाकृत सरल उत्पाद है, और दूसरी ओर, यह इसकी विश्वसनीयता सुनिश्चित करता है। और इसका उपयोग करना काफी आसान है, यही कारण है कि यह Hadoop पारिस्थितिकी तंत्र के भीतर अनुप्रयोगों में एक मानक बन गया है। इसलिए मैंने सोचा कि यह कैसे काम करता है और इसका उपयोग कैसे करना है, यह समझने के लिए इसकी समीक्षा करना उपयोगी होगा।

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

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

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

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

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

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

एक प्रोग्राम लिखना आसान है जो एक प्रोसेसर वाले एक कंप्यूटर पर चलता है।

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

साफ है कि इन सब पर तुरंत नजर रखी जा सकेगी. यह भी अच्छा है, लेकिन मॉनिटरिंग एक सीमित चीज है जो आपको उच्चतम स्तर पर कुछ चीजों की निगरानी करने की अनुमति देती है।

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

इन सभी प्रक्रियाओं का समन्वय कोई मामूली बात नहीं है। और यह डेवलपर को और भी निचले स्तर पर जाने के लिए मजबूर करता है, और सिस्टम को या तो स्क्रैच से लिखता है, या बिल्कुल स्क्रैच से नहीं, लेकिन यह इतना आसान नहीं है।

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

आज हम बात कर रहे हैं ज़ूकीपर के बारे में। एक ओर, यह एक रूपरेखा है, दूसरी ओर, यह एक ऐसी सेवा है जो डेवलपर के लिए जीवन को आसान बनाती है और हमारी प्रक्रियाओं के तर्क और समन्वय के कार्यान्वयन को यथासंभव सरल बनाती है।

आइए याद रखें कि एक मानक वितरित प्रणाली कैसी दिख सकती है। हमने इसी बारे में बात की - HDFS, HBase। एक मास्टर प्रक्रिया है जो श्रमिकों और दास प्रक्रियाओं का प्रबंधन करती है। वह कार्यों के समन्वय और वितरण, श्रमिकों को फिर से शुरू करने, नए लॉन्च करने और भार वितरित करने के लिए जिम्मेदार है।

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

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

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

यह कहना मुश्किल है कि इनमें से कौन सी योजना बेहतर काम करती है। प्रत्येक के अपने फायदे और नुकसान हैं।

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

और यह योजना (ऊपर) संभवतः अधिक जटिल है, लेकिन अधिक विश्वसनीय है।

मुख्य समस्या आंशिक विफलता है. उदाहरण के लिए, जब हम नेटवर्क पर कोई संदेश भेजते हैं, तो किसी प्रकार की दुर्घटना होती है, और जिसने संदेश भेजा है उसे पता नहीं चलेगा कि उसका संदेश प्राप्त हुआ या नहीं और प्राप्तकर्ता की ओर से क्या हुआ, उसे पता नहीं चलेगा कि संदेश सही ढंग से संसाधित हुआ या नहीं , यानी उसे कोई पुष्टिकरण नहीं मिलेगा।

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

ज़ूकीपर ऐसे इनकारों से निपटने के तरीके प्रदान करता है, जो हमारे जीवन को भी आसान बनाता है।

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

यदि हम एक कंप्यूटर पर मल्टी-थ्रेडेड प्रोग्राम लिखते हैं, तो हम डेटा का आदान-प्रदान करने के लिए साझा मेमोरी का उपयोग कर सकते हैं। हमारे पास वहां एक संदर्भ स्विच है, प्रक्रियाएं स्विच कर सकती हैं। इससे प्रदर्शन प्रभावित होता है. एक ओर, क्लस्टर पर प्रोग्राम में ऐसी कोई चीज़ नहीं है, लेकिन नेटवर्क में समस्याएँ हैं।

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

यहां हम सिस्टम प्रक्रियाओं के लिए स्थिर कॉन्फ़िगरेशन के बारे में बात कर रहे हैं। यह पूरी तरह से नहीं है, शायद ऑपरेटिंग सिस्टम के दृष्टिकोण से, यह हमारी प्रक्रियाओं के लिए एक स्थिर कॉन्फ़िगरेशन हो सकता है, अर्थात, यह एक ऐसा कॉन्फ़िगरेशन है जिसे आसानी से लिया और अपडेट नहीं किया जा सकता है।

एक गतिशील विन्यास भी है. ये वे पैरामीटर हैं जिन्हें हम तुरंत बदलना चाहते हैं ताकि उन्हें वहां उठाया जा सके।

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

एक अन्य समस्या समूह सदस्यता है. हमारे पास हमेशा कुछ श्रमिकों का समूह होता है, हम हमेशा यह जानना चाहते हैं कि उनमें से कौन जीवित है, कौन मृत है। यदि कोई मास्टर है, तो उसे यह समझना होगा कि किन श्रमिकों को ग्राहकों पर पुनर्निर्देशित किया जा सकता है ताकि वे गणना चला सकें या डेटा के साथ काम कर सकें, और कौन से नहीं। एक समस्या जो लगातार उठती रहती है वह यह है कि हमें यह जानना होगा कि हमारे क्लस्टर में कौन काम कर रहा है।

एक अन्य विशिष्ट समस्या नेता चुनाव है, जब हम जानना चाहते हैं कि प्रभारी कौन है। एक उदाहरण प्रतिकृति है, जब हमारे पास कुछ प्रक्रिया होती है जो लेखन संचालन प्राप्त करती है और फिर उन्हें अन्य प्रक्रियाओं के बीच दोहराती है। वह नेता होगा, बाकी सभी लोग उसकी बात मानेंगे, उसका अनुसरण करेंगे। एक प्रक्रिया का चयन करना आवश्यक है ताकि यह सभी के लिए स्पष्ट हो, ताकि ऐसा न हो कि दो नेताओं का चयन किया जाए।

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

ज़ूकीपर आपको इन सभी समस्याओं को किसी न किसी हद तक हल करने की अनुमति देता है। और मैं उदाहरणों के साथ दिखाऊंगा कि यह आपको ऐसा करने की अनुमति कैसे देता है।

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

सभी क्लाइंट अनुरोधों को सामान्य कतार के क्रम में संसाधित किया जाता है।

और ग्राहकों के पास किसी राज्य में परिवर्तन के बारे में, डेटा में परिवर्तन के बारे में सूचना प्राप्त करने का अवसर होता है, इससे पहले कि ग्राहक स्वयं परिवर्तित डेटा देखे।

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

डेटा को क्लाइंट साइड पर कैश किया जा सकता है। यह एक मानक सिद्धांत है ताकि हम सेवा को बाधित न करें और इसे समान अनुरोधों से लोड न करें। एक स्मार्ट क्लाइंट आमतौर पर इसके बारे में जानता है और इसे कैश कर लेता है।

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

क्लाइंट वह उपयोगकर्ता है जो ज़ूकीपर का उपयोग करता है।

सर्वर ज़ूकीपर प्रक्रिया ही है।

ज़ूकीपर में ज़्नोड प्रमुख चीज़ है। सभी znodes को ZooKeeper द्वारा मेमोरी में संग्रहीत किया जाता है और एक पेड़ के रूप में एक पदानुक्रमित आरेख के रूप में व्यवस्थित किया जाता है।

ऑपरेशन दो प्रकार के होते हैं. पहला है अपडेट/राइट, जब कोई ऑपरेशन हमारे पेड़ की स्थिति को बदल देता है। पेड़ आम है.

और यह संभव है कि क्लाइंट एक अनुरोध पूरा नहीं करता है और डिस्कनेक्ट हो जाता है, लेकिन एक सत्र स्थापित कर सकता है जिसके माध्यम से वह ज़ूकीपर के साथ इंटरैक्ट करता है।

ज़ूकीपर का डेटा मॉडल एक फ़ाइल सिस्टम जैसा दिखता है। एक मानक रूट है और फिर हम उन निर्देशिकाओं के माध्यम से चले गए जो रूट से जाती हैं। और फिर प्रथम स्तर, द्वितीय स्तर की सूची। यह सभी znodes है.

प्रत्येक znode कुछ डेटा संग्रहीत कर सकता है, आमतौर पर बहुत बड़ा नहीं, उदाहरण के लिए, 10 किलोबाइट। और प्रत्येक znode में एक निश्चित संख्या में बच्चे हो सकते हैं।

ज़्नोड्स कई प्रकार के होते हैं। उन्हें बनाया जा सकता है. और एक znode बनाते समय, हम उस प्रकार को निर्दिष्ट करते हैं जिससे यह संबंधित होना चाहिए।

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

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

नियमित ज़ोनोड. वह हमेशा जीवित रहेगी और उसका वही नाम होगा जो हम उसे बताएंगे।

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

और जैसा कि मैंने पहले ही कहा, डेटा का क्रम किलोबाइट्स द्वारा निर्धारित किया जाता है। वहां बड़े टेक्स्ट डेटा को स्टोर करने की जरूरत नहीं है, क्योंकि यह कोई डेटाबेस नहीं है, यह एक एक्शन कोऑर्डिनेशन सर्वर है।

मैं आपको सत्रों के बारे में थोड़ा बताऊंगा। यदि हमारे पास एकाधिक सर्वर हैं, तो हम सत्र पहचानकर्ता का उपयोग करके पारदर्शी रूप से एक सर्वर से दूसरे सर्वर पर जा सकते हैं। यह काफी सुविधाजनक है.

प्रत्येक सत्र में कुछ प्रकार का टाइमआउट होता है। एक सत्र को इस बात से परिभाषित किया जाता है कि क्लाइंट उस सत्र के दौरान सर्वर को कुछ भेजता है या नहीं। यदि उसने टाइमआउट के दौरान कुछ भी प्रसारित नहीं किया, तो सत्र बंद हो जाता है, या ग्राहक इसे स्वयं बंद कर सकता है।

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

दूसरा, आप इसे हटा सकते हैं. यहां चाल यह है कि दूसरा पैरामीटर, znode के पथ के अलावा, संस्करण निर्दिष्ट कर सकता है। तदनुसार, उस znode को हटा दिया जाएगा यदि उसका संस्करण जो हमने स्थानांतरित किया है वह वास्तव में मौजूद संस्करण के बराबर है।

यदि हम इस संस्करण की जाँच नहीं करना चाहते हैं, तो हम बस "-1" तर्क पास कर देते हैं।

तीसरा, यह एक znode के अस्तित्व की जाँच करता है। यदि नोड मौजूद है तो सत्य लौटाता है, अन्यथा गलत लौटाता है।

और फिर फ़्लैग वॉच दिखाई देती है, जो आपको इस नोड की निगरानी करने की अनुमति देती है।

आप इस ध्वज को गैर-मौजूद नोड पर भी सेट कर सकते हैं और इसके प्रकट होने पर एक अधिसूचना प्राप्त कर सकते हैं। ये भी उपयोगी हो सकता है.

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

वहाँ भी सेटडेटा. यहां हम संस्करण पास करते हैं। और यदि हम इसे आगे बढ़ाते हैं, तो एक निश्चित संस्करण के znode पर डेटा अपडेट किया जाएगा।

आप इस चेक को बाहर करने के लिए "-1" भी निर्दिष्ट कर सकते हैं।

एक और उपयोगी तरीका है बच्चे प्राप्त करें. हम इससे संबंधित सभी znodes की एक सूची भी प्राप्त कर सकते हैं। हम फ़्लैग वॉच सेट करके इसकी निगरानी कर सकते हैं।

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

यदि हम पारंपरिक प्रोग्रामिंग के साथ सादृश्य बनाते हैं, तो जब आप लिखने जैसे तरीकों का उपयोग करते हैं, जो डिस्क पर कुछ लिखते हैं, और इसके बाद यह आपको प्रतिक्रिया देता है, तो इसकी कोई गारंटी नहीं है कि आपने डिस्क पर डेटा लिखा है। और यहां तक ​​कि जब ऑपरेटिंग सिस्टम आश्वस्त होता है कि सब कुछ लिखा जा चुका है, तो डिस्क में ही ऐसे तंत्र होते हैं जहां प्रक्रिया बफ़र्स की परतों से होकर गुजरती है, और उसके बाद ही डेटा को डिस्क पर रखा जाता है।

अधिकतर एसिंक्रोनस कॉल का उपयोग किया जाता है। यह क्लाइंट को विभिन्न अनुरोधों के समानांतर काम करने की अनुमति देता है। आप समकालिक दृष्टिकोण का उपयोग कर सकते हैं, लेकिन यह कम उत्पादक है।

जिन दो ऑपरेशनों के बारे में हमने बात की वे अपडेट/राइट हैं, जो डेटा बदलते हैं। ये हैं क्रिएट, सेटडेटा, सिंक, डिलीट। और पढ़ा हुआ मौजूद है, getData, getChildren।

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

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

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

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

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

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

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

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

किसी संसाधन को कैसे लॉक करें? यहां सब कुछ थोड़ा अधिक जटिल है। हमारे पास श्रमिकों का एक समूह है, कुछ संसाधन हैं जिन्हें हम लॉक करना चाहते हैं। ऐसा करने के लिए, हम एक अलग नोड बनाते हैं, उदाहरण के लिए, जिसे लॉक1 कहा जाता है। अगर हम इसे बनाने में सफल रहे तो हमें यहां एक ताला मिल गया।' और यदि हम इसे बनाने में असमर्थ होते हैं, तो कार्यकर्ता यहां से getData प्राप्त करने का प्रयास करता है, और चूंकि नोड पहले ही बनाया जा चुका है, तो हम यहां एक वॉचर लगाते हैं और जैसे ही इस नोड की स्थिति बदलती है, हमें इसके बारे में पता चल जाएगा। और हम इसे पुनः बनाने के लिए समय निकालने का प्रयास कर सकते हैं। यदि हमने यह नोड लिया, यह लॉक लिया, तो जब हमें लॉक की आवश्यकता नहीं रह जाएगी, तो हम इसे छोड़ देंगे, क्योंकि नोड केवल सत्र के भीतर मौजूद है। तदनुसार, यह गायब हो जाएगा. और एक अन्य ग्राहक, दूसरे सत्र के ढांचे के भीतर, इस नोड पर लॉक लेने में सक्षम होगा, या बल्कि, उसे एक अधिसूचना प्राप्त होगी कि कुछ बदल गया है और वह इसे समय पर करने का प्रयास कर सकता है।

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

यदि किसी कारण से नेता की मृत्यु हो जाती है, उदाहरण के लिए, वह गिर जाता है, तो हम एक नया नेता बनाने का प्रयास करते हैं। और अगर हम सफल होते हैं तो हमारा कार्यकर्ता नेता बन जाता है. और अगर इस समय कोई नया नेता बनाने में कामयाब होता है, तो हम यह समझने की कोशिश करते हैं कि वह कौन है और फिर उसका अनुसरण करते हैं।

यहां तथाकथित झुंड प्रभाव उत्पन्न होता है, यानी झुंड प्रभाव, क्योंकि जब एक नेता की मृत्यु हो जाती है, तो जो सबसे पहले समय पर आएगा वह नेता बन जाएगा।

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

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

ज़ूकीपर में क्या शामिल है? 4 मुख्य बातें हैं. यह प्रसंस्करण प्रक्रियाएं हैं - अनुरोध। और ज़ूकीपर परमाणु प्रसारण भी। एक कमिट लॉग है जहां सभी ऑपरेशन रिकॉर्ड किए जाते हैं। और इन-मेमोरी रेप्लिकेटेड डीबी स्वयं, यानी डेटाबेस ही जहां यह पूरा पेड़ संग्रहीत है।

यह ध्यान देने योग्य है कि सभी लेखन कार्य अनुरोध प्रोसेसर के माध्यम से चलते हैं। और रीड ऑपरेशन सीधे इन-मेमोरी डेटाबेस में जाते हैं।

डेटाबेस स्वयं पूरी तरह से दोहराया गया है। ज़ूकीपर के सभी इंस्टेंस डेटा की पूरी प्रतिलिपि संग्रहीत करते हैं।

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

ज़ूकीपर एटॉमिक ब्रॉडकास्ट एक ऐसी चीज़ है जिसका उपयोग प्रतिकृति डेटा को बनाए रखने के लिए किया जाता है।

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

यह केवल लिखने के अनुरोधों को संसाधित करता है। इसका मुख्य कार्य यह है कि यह ऑपरेशन को ट्रांजेक्शनल अपडेट में बदल देता है। यह एक विशेष रूप से तैयार किया गया अनुरोध है.

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

स्रोत: www.habr.com