"हडुप। ZooKeeper" Mail.Ru समूह टेक्नोस्ट्रीम श्रृंखलाबाट "हडूपमा डेटाको ठूलो मात्राको वितरण प्रशोधनका लागि विधिहरू"

म सुझाव दिन्छु कि तपाइँ लेक्चर "Hadoop. ZooKeeper" को शृङ्खला "Hadoop मा डाटा को ठूला मात्रा को वितरण प्रशोधन को लागी विधिहरु" को ट्रान्सक्रिप्ट पढ्नुहोस्।

ZooKeeper के हो, Hadoop इकोसिस्टममा यसको स्थान। वितरित कम्प्युटिङ बारे असत्य। मानक वितरण प्रणालीको रेखाचित्र। वितरण प्रणाली समन्वय गर्न कठिनाई। सामान्य समन्वय समस्याहरू। ZooKeeper को डिजाइन पछि सिद्धान्तहरू। ZooKeeper डाटा मोडेल। znode झण्डा। सत्रहरू। ग्राहक API। आदिम (कन्फिगरेसन, समूह सदस्यता, साधारण ताला, नेता चुनाव, बथान प्रभाव बिना लक)। ZooKeeper वास्तुकला। ZooKeeper DB। ZAB। ह्यान्डलर अनुरोध गर्नुहोस्।

आज हामी ZooKeeper को बारेमा कुरा गर्नेछौं। यो कुरा धेरै उपयोगी छ। यो, कुनै पनि Apache Hadoop उत्पादन जस्तै, एक लोगो छ। यसले मानिसलाई चित्रण गर्छ।

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

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

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

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

यो सबै कहाँबाट आउँछ? यस्तो देखिन्छ कि हामीले विभिन्न कम्प्युटरहरूमा समानान्तर रूपमा दुई अनुप्रयोगहरू सुरू गर्यौं, तिनीहरूलाई स्ट्रिङ वा जालमा जडान गर्‍यौं, र सबै काम गर्दछ। तर समस्या यो हो कि नेटवर्क अविश्वसनीय छ, र यदि तपाईंले ट्राफिक सुन्नुभयो वा त्यहाँ के भइरहेको छ कम स्तरमा हेर्नुभयो भने, ग्राहकहरूले नेटवर्कमा कसरी अन्तरक्रिया गर्छन्, तपाइँ प्राय: केहि प्याकेटहरू हराएको वा पुन: पठाइएको देख्न सक्नुहुन्छ। यो केहिको लागि होइन कि TCP प्रोटोकलहरू आविष्कार गरिएको थियो, जसले तपाईंलाई निश्चित सत्र स्थापना गर्न र सन्देशहरूको डेलिभरीको ग्यारेन्टी गर्न अनुमति दिन्छ। तर कुनै पनि अवस्थामा, TCP ले तपाईंलाई सधैं बचाउन सक्दैन। सबै कुराको समयावधि हुन्छ। नेटवर्क केही समयको लागि बन्द हुन सक्छ। यो केवल झिम्काउन सक्छ। र यो सबै तथ्यलाई निम्त्याउँछ कि तपाइँ नेटवर्क भरपर्दो हुनुमा भरोसा गर्न सक्नुहुन्न। यो समानान्तर अनुप्रयोगहरू लेख्ने मुख्य भिन्नता हो जुन एक कम्प्युटर वा एक सुपर कम्प्युटरमा चल्छ, जहाँ नेटवर्क छैन, जहाँ मेमोरीमा अधिक भरपर्दो डाटा एक्सचेन्ज बस छ। र यो एक मौलिक भिन्नता हो।

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

नेटवर्क टोपोलोजी परिवर्तन हुँदैछ। टोपोलोजी के हो - यो हाम्रो नेटवर्क उपकरण को प्लेसमेन्ट छ। त्यहाँ डाटा सेन्टरहरू छन्, त्यहाँ र्याकहरू छन् जुन त्यहाँ खडा छन्, त्यहाँ मैनबत्तीहरू छन्। यी सबै पुन: जडान गर्न सकिन्छ, सारियो, आदि। यो सबैलाई पनि ध्यानमा राख्न आवश्यक छ। IP नामहरू परिवर्तन हुन्छ, हाम्रो ट्राफिक यात्राको मार्ग परिवर्तन हुन्छ। यसलाई पनि ध्यानमा राख्नुपर्छ ।

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

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

एउटा प्रोसेसर भएको एउटा कम्प्युटरमा चल्ने एउटा प्रोग्राम लेख्न सजिलो हुन्छ।

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

यो स्पष्ट छ कि यो सबै छिट्टै अनुगमन गर्न सकिन्छ। यो पनि राम्रो छ, तर निगरानी एक सीमित चीज हो जसले तपाईंलाई उच्च स्तरमा केहि चीजहरू निगरानी गर्न अनुमति दिन्छ।

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

यी सबै प्रक्रियाहरूको समन्वय कुनै सानो कुरा होइन। र यसले विकासकर्तालाई अझ तल्लो तहमा जान बाध्य पार्छ, र प्रणालीहरू या त स्क्र्याचबाट लेख्छ, वा एकदम स्क्र्याचबाट होइन, तर यो त्यति सरल छैन।

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

आज हामी ZooKeeper को बारेमा कुरा गर्दैछौं। एकातिर, यो एक ढाँचा हो, अर्कोतर्फ, यो एक सेवा हो जसले विकासकर्ताको लागि जीवनलाई सजिलो बनाउँछ र तर्कको कार्यान्वयन र हाम्रो प्रक्रियाहरूको समन्वयलाई सकेसम्म सरल बनाउँछ।

मानक वितरण प्रणाली कस्तो देखिन सक्छ याद गरौं। यो हामीले कुरा गर्यौं - HDFS, HBase। त्यहाँ एक मास्टर प्रक्रिया छ जसले कामदार र दास प्रक्रियाहरू प्रबन्ध गर्दछ। उहाँ कार्यहरू समन्वय र वितरण गर्न, कामदारहरूलाई पुनः सुरु गर्न, नयाँ सुरु गर्न, र लोड वितरण गर्न जिम्मेवार हुनुहुन्छ।

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

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

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

यी मध्ये कुन योजनाले राम्रो काम गर्छ भन्न गाह्रो छ। प्रत्येकको आफ्नै फाइदा र बेफाइदा छ।

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

र यो योजना (माथि) सायद अधिक जटिल छ, तर अधिक विश्वसनीय।

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

तदनुसार, हामीले यो अवस्थालाई प्रशोधन गर्नुपर्छ। र सबैभन्दा सरल कुरा यो सन्देश पुन: पठाउन र हामीले प्रतिक्रिया प्राप्त नभएसम्म पर्खनु हो। यस अवस्थामा, प्राप्तकर्ताको अवस्था परिवर्तन भएको छ कि छैन भन्ने कुरालाई ध्यानमा राखिएको छैन। हामी सन्देश पठाउन सक्छौं र उही डाटा दुई पटक थप्न सक्छौं।

ZooKeeper ले त्यस्ता अस्वीकारहरूको सामना गर्ने तरिकाहरू प्रदान गर्दछ, जसले हाम्रो जीवनलाई पनि सजिलो बनाउँछ।

अलि पहिले उल्लेख गरिए अनुसार, यो बहु-थ्रेडेड प्रोग्रामहरू लेख्न मिल्दोजुल्दो छ, तर मुख्य भिन्नता यो हो कि हामीले बिभिन्न मेसिनहरूमा निर्माण गर्ने वितरित अनुप्रयोगहरूमा, सञ्चार गर्ने एक मात्र तरिका नेटवर्क हो। अनिवार्य रूपमा, यो साझा-कुनै पनि वास्तुकला हो। एउटै मेसिनमा चल्ने प्रत्येक प्रक्रिया वा सेवाको आफ्नै मेमोरी, आफ्नै डिस्क, आफ्नै प्रोसेसर हुन्छ, जुन यसले कसैसँग साझेदारी गर्दैन।

यदि हामीले एउटै कम्प्युटरमा बहु-थ्रेडेड प्रोग्राम लेख्यौं भने, हामी डेटा आदानप्रदान गर्न साझा मेमोरी प्रयोग गर्न सक्छौं। हामीसँग त्यहाँ सन्दर्भ स्विच छ, प्रक्रियाहरू स्विच गर्न सक्छन्। यसले कार्यसम्पादनलाई असर गर्छ । एकातिर, क्लस्टरमा कार्यक्रममा त्यस्तो केही छैन, तर नेटवर्कमा समस्याहरू छन्।

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

यहाँ हामी प्रणाली प्रक्रियाहरूको लागि स्थिर कन्फिगरेसनको बारेमा कुरा गर्दैछौं। यो पूर्ण रूपमा होइन, हुनसक्छ अपरेटिङ सिस्टमको दृष्टिकोणबाट, यो हाम्रो प्रक्रियाहरूको लागि स्थिर कन्फिगरेसन हुन सक्छ, त्यो हो, यो एक कन्फिगरेसन हो जुन सजिलै लिन र अद्यावधिक गर्न सकिँदैन।

त्यहाँ एक गतिशील कन्फिगरेसन पनि छ। यी मापदण्डहरू हुन् जुन हामी उडानमा परिवर्तन गर्न चाहन्छौं ताकि तिनीहरू त्यहाँ उठाइन्छ।

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

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

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

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

ZooKeeper ले तपाईंलाई यी सबै समस्याहरू एक डिग्री वा अर्कोमा समाधान गर्न अनुमति दिन्छ। र म उदाहरणहरू देखाउनेछु कि यसले तपाईंलाई कसरी यो गर्न अनुमति दिन्छ।

त्यहाँ कुनै अवरुद्ध आदिमहरू छैनन्। जब हामी केहि प्रयोग गर्न थाल्छौं, यो आदिमले कुनै घटना हुनको लागि पर्खदैन। सम्भवतः, यो चीज एसिन्क्रोनस रूपमा काम गर्दछ, यसैले प्रक्रियाहरूलाई तिनीहरूले केहिको लागि पर्खिरहेका बेला ह्याङ्ग हुन नदिने अनुमति दिन्छ। यो धेरै उपयोगी कुरा हो।

सबै ग्राहक अनुरोधहरू सामान्य लामको क्रममा प्रशोधन गरिन्छ।

र ग्राहकहरु लाई केहि राज्य मा परिवर्तन को बारे मा सूचना प्राप्त गर्ने अवसर छ, डाटा मा परिवर्तन को बारे मा, ग्राहकहरु लाई परिवर्तन गरिएको डाटा देख्नु अघि।

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

डाटा ग्राहक पक्ष मा क्यास गर्न सकिन्छ। यो एक मानक सिद्धान्त हो जसले गर्दा हामीले सेवामा अवरोध नगर्ने र उस्तै अनुरोधहरूसँग लोड नगर्ने। एक स्मार्ट क्लाइन्ट सामान्यतया यस बारे थाहा छ र यसलाई क्यास गर्दछ।

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

ग्राहक भनेको ZooKeeper प्रयोग गर्ने प्रयोगकर्ता हो।

सर्भर भनेको ZooKeeper प्रक्रिया नै हो।

Znode ZooKeeper मा मुख्य कुरा हो। सबै znodes ZooKeeper द्वारा मेमोरीमा भण्डारण गरिन्छ र एक श्रेणीबद्ध रेखाचित्रको रूपमा, रूखको रूपमा व्यवस्थित गरिन्छ।

त्यहाँ दुई प्रकारका अपरेशनहरू छन्। पहिलो अपडेट/लेखन हो, जब केहि अपरेशनले हाम्रो रूखको अवस्था परिवर्तन गर्दछ। रूख सामान्य छ।

र यो सम्भव छ कि ग्राहकले एउटा अनुरोध पूरा गर्दैन र विच्छेद भएको छ, तर एक सत्र स्थापना गर्न सक्छ जसको माध्यमबाट यो ZooKeeper सँग अन्तरक्रिया गर्दछ।

ZooKeeper को डाटा मोडेल फाइल प्रणाली जस्तै देखिन्छ। त्यहाँ एक मानक रूट छ र त्यसपछि हामी रूटबाट जाने डाइरेक्टरीहरू मार्फत गयौं। र त्यसपछि पहिलो स्तर, दोस्रो स्तर को सूची। यो सबै znodes हो।

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

Znodes धेरै प्रकार मा आउँछ। तिनीहरू सिर्जना गर्न सकिन्छ। र znode सिर्जना गर्दा, हामी यो सम्बन्धित हुनुपर्छ भन्ने प्रकार निर्दिष्ट गर्छौं।

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

दोस्रो प्रकार क्रमिक झण्डा हो। यसले znode को बाटोमा काउन्टर बढाउँछ। उदाहरणका लागि, हामीसँग एप्लिकेसन १_५ भएको डाइरेक्टरी थियो। र जब हामीले पहिलो नोड सिर्जना गर्यौं, यसले p_1, दोस्रो - p_5 प्राप्त गर्‍यो। र जब हामी यो विधिलाई प्रत्येक पटक कल गर्छौं, हामी पूर्ण पथ पार गर्छौं, पथको मात्र अंश संकेत गर्दै, र यो संख्या स्वचालित रूपमा बढ्छ किनभने हामीले नोड प्रकार - अनुक्रमिक संकेत गर्दछौं।

नियमित znode। उनी सधैं बाँच्नेछिन् र हामीले उनलाई बताएको नाम हुनेछ।

अर्को उपयोगी कुरा घडी झण्डा हो। यदि हामीले यसलाई स्थापना गर्छौं भने, ग्राहकले निश्चित नोडका लागि केही घटनाहरूको सदस्यता लिन सक्छ। यो कसरी गरिन्छ भन्ने उदाहरणको साथ म तपाईंलाई पछि देखाउनेछु। ZooKeeper आफैले ग्राहकलाई सूचित गर्दछ कि नोडमा डाटा परिवर्तन भएको छ। यद्यपि, अधिसूचनाहरूले ग्यारेन्टी गर्दैन कि केहि नयाँ डाटा आएको छ। तिनीहरू केवल भन्छन् कि केहि परिवर्तन भएको छ, त्यसैले तपाईले अझै पनि डेटा पछि फरक कलहरूसँग तुलना गर्नुपर्दछ।

र मैले पहिले नै भने, डाटा को क्रम किलोबाइट द्वारा निर्धारण गरिन्छ। त्यहाँ ठूलो पाठ डाटा भण्डारण गर्न आवश्यक छैन, किनभने यो डाटाबेस होइन, यो एक कार्य समन्वय सर्भर हो।

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

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

यसमा धेरै सुविधाहरू छैनन्, तर तपाईं यस API मार्फत विभिन्न चीजहरू गर्न सक्नुहुन्छ। त्यो कल हामीले देख्यौं सिर्जनाले znode सिर्जना गर्दछ र तीन प्यारामिटरहरू लिन्छ। यो znode को बाटो हो, र यो रूट देखि पूर्ण मा निर्दिष्ट हुनुपर्छ। र यो पनि केहि डाटा हो जुन हामी त्यहाँ स्थानान्तरण गर्न चाहन्छौं। र झण्डा को प्रकार। र सिर्जना पछि यो znode को बाटो फर्काउँछ।

दोस्रो, तपाईं यसलाई मेटाउन सक्नुहुन्छ। यहाँ चाल यो हो कि दोस्रो प्यारामिटर, znode को मार्ग को अतिरिक्त, संस्करण निर्दिष्ट गर्न सक्नुहुन्छ। तदनुसार, त्यो znode मेटाइनेछ यदि हामीले स्थानान्तरण गरेको यसको संस्करण वास्तवमा अवस्थितसँग बराबर छ।

यदि हामी यो संस्करण जाँच गर्न चाहँदैनौं भने, हामी केवल "-1" तर्क पास गर्छौं।

तेस्रो, यसले znode को अस्तित्वको लागि जाँच गर्दछ। यदि नोड अवस्थित छ भने सही फर्काउँछ, अन्यथा गलत।

र त्यसपछि झण्डा घडी देखिन्छ, जसले तपाईंलाई यो नोड निगरानी गर्न अनुमति दिन्छ।

तपाईंले यो झण्डा अस्तित्वहीन नोडमा पनि सेट गर्न सक्नुहुन्छ र यो देखा पर्दा सूचना प्राप्त गर्न सक्नुहुन्छ। यो पनि उपयोगी हुन सक्छ।

केही थप चुनौतीहरू छन् डाटा प्राप्त गर्नुहोस्। यो स्पष्ट छ कि हामी znode मार्फत डाटा प्राप्त गर्न सक्छौं। तपाईं झण्डा घडी पनि प्रयोग गर्न सक्नुहुन्छ। यस अवस्थामा, यदि कुनै नोड छैन भने यो स्थापना हुनेछैन। त्यसकारण, तपाईंले यो अवस्थित छ भनेर बुझ्न आवश्यक छ, र त्यसपछि डाटा प्राप्त गर्नुहोस्।

पनि छ डेटा सेट गर्नुहोस्। यहाँ हामी संस्करण पास गर्छौं। र यदि हामीले यसलाई पास गर्यौं भने, निश्चित संस्करणको znode मा डाटा अपडेट हुनेछ।

तपाईंले यो चेक बहिष्कार गर्न "-1" निर्दिष्ट गर्न सक्नुहुन्छ।

अर्को उपयोगी विधि हो बच्चाहरू प्राप्त गर्नुहोस्। हामी यसमा सम्बन्धित सबै znodes को सूची पनि प्राप्त गर्न सक्छौं। हामी झण्डा घडी सेट गरेर यसलाई निगरानी गर्न सक्छौं।

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

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

प्रायः एसिन्क्रोनस कलहरू प्रयोग गरिन्छ। यसले ग्राहकलाई विभिन्न अनुरोधहरूसँग समानान्तर काम गर्न अनुमति दिन्छ। तपाईं सिंक्रोनस दृष्टिकोण प्रयोग गर्न सक्नुहुन्छ, तर यो कम उत्पादक छ।

हामीले कुरा गरेका दुई अपरेशनहरू अपडेट/लेखन हुन्, जसले डाटा परिवर्तन गर्दछ। यी हुन् सिर्जना, सेट डाटा, सिङ्क, मेटाउने। र पढ्न अवस्थित छ, getData, getChildren।

अब तपाइँ कसरी वितरित प्रणालीमा काम गर्नका लागि आदिम बनाउन सक्नुहुन्छ भन्ने केही उदाहरणहरू। उदाहरण को लागी, केहि को कन्फिगरेसन संग सम्बन्धित। नयाँ कार्यकर्ता देखा परेको छ । हामीले मेसिन थप्यौं र प्रक्रिया सुरु गर्‍यौं। र त्यहाँ निम्न तीन प्रश्नहरू छन्। यसले कसरी कन्फिगरेसनको लागि ZooKeeper लाई सोध्छ? र यदि हामी कन्फिगरेसन परिवर्तन गर्न चाहन्छौं भने, हामी यसलाई कसरी परिवर्तन गर्ने? र हामीले यसलाई परिवर्तन गरेपछि, ती कामदारहरूले कसरी प्राप्त गर्छन्?

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

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

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

आदिम प्रयोगको लागि दोस्रो विकल्प हो समूह सदस्यता। हामीसँग वितरित आवेदन छ, त्यहाँ कामदारहरूको गुच्छा छ र हामी बुझ्न चाहन्छौं कि तिनीहरू सबै ठाउँमा छन्। त्यसकारण, तिनीहरूले आफैंलाई दर्ता गर्नुपर्छ कि तिनीहरूले हाम्रो आवेदनमा काम गर्छन्। र हामी मास्टर प्रक्रियाबाट वा अन्य कतैबाट, हामीसँग हाल रहेका सबै सक्रिय कार्यकर्ताहरूको बारेमा पनि पत्ता लगाउन चाहन्छौं।

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

यो जाभा कोडमा कसरी गर्न सकिन्छ भन्ने यस्तो भयानक कार्यान्वयन हो। मुख्य विधिको साथ अन्त्यबाट सुरु गरौं। यो हाम्रो कक्षा हो, यसको विधि बनाऔं। पहिलो तर्कको रूपमा हामीले होस्ट प्रयोग गर्छौं, जहाँ हामी जडान गर्दैछौं, अर्थात् हामीले यसलाई तर्कको रूपमा सेट गर्छौं। र दोस्रो तर्क समूहको नाम हो।

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

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

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

यदि नेता कुनै कारणको लागि मरे भने, उदाहरणका लागि, झर्यो, त्यसपछि हामी नयाँ नेता सिर्जना गर्ने प्रयास गर्छौं। र यदि हामी सफल हुन्छौं भने हाम्रो कार्यकर्ता नेता बन्छ। र यदि कसैले यस क्षणमा नयाँ नेता सिर्जना गर्न व्यवस्थित गर्यो भने, हामी यो को हो भनेर बुझ्न प्रयास गर्छौं र त्यसपछि उहाँलाई पछ्याउनुहोस्।

यहाँ तथाकथित हर्ड इफेक्ट अर्थात् हर्ड इफेक्ट उत्पन्न हुन्छ, किनकि नेताको मृत्यु हुँदा, समयमै पहिलो हुने नै नेता बन्छ।

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

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

ZooKeeper मा के समावेश छ? त्यहाँ 4 मुख्य कुराहरू छन्। यो प्रशोधन प्रक्रियाहरू हो - अनुरोध। र ZooKeeper परमाणु प्रसारण पनि। त्यहाँ एक कमिट लग छ जहाँ सबै कार्यहरू रेकर्ड हुन्छन्। र इन-मेमोरी प्रतिकृति DB आफैं, अर्थात् डाटाबेस आफैं जहाँ यो सम्पूर्ण रूख भण्डार गरिएको छ।

यो ध्यान दिन लायक छ कि सबै लेखन कार्यहरू अनुरोध प्रोसेसर मार्फत जान्छन्। र पढ्ने कार्यहरू सिधै इन-मेमोरी डाटाबेसमा जान्छ।

डाटाबेस आफैं पूर्ण रूपमा नक्कल गरिएको छ। ZooKeeper को सबै उदाहरणहरूले डाटाको पूर्ण प्रतिलिपि भण्डारण गर्दछ।

एक दुर्घटना पछि डाटाबेस पुनर्स्थापना गर्न को लागी, त्यहाँ एक प्रतिबद्ध लग छ। मानक अभ्यास भनेको डेटा मेमोरीमा आउनु अघि, त्यहाँ लेखिएको छ ताकि यदि यो क्र्यास भयो भने, यो लग फिर्ता प्ले गर्न सकिन्छ र प्रणाली स्थिति पुनर्स्थापित गर्न सकिन्छ। र डाटाबेसको आवधिक स्न्यापसटहरू पनि प्रयोग गरिन्छ।

ZooKeeper Atomic Broadcast एक चीज हो जुन प्रतिकृत डाटा कायम राख्न प्रयोग गरिन्छ।

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

यसले केवल लेख्न अनुरोधहरू प्रशोधन गर्दछ। यसको मुख्य कार्य यो हो कि यसले अपरेशनलाई लेनदेन अपडेटमा रूपान्तरण गर्दछ। यो विशेष रूपमा उत्पन्न अनुरोध हो।

र यहाँ यो ध्यान दिन लायक छ कि एउटै अपरेशनको लागि अद्यावधिकहरूको idempotency ग्यारेन्टी गरिएको छ। यो के हो? यो कुरा, यदि दुई पटक कार्यान्वयन गरियो भने, एउटै अवस्था हुनेछ, अर्थात् अनुरोध आफैंमा परिवर्तन हुनेछैन। र यो गर्न आवश्यक छ कि एक दुर्घटना को मामला मा, तपाईं अपरेशन पुन: सुरु गर्न सक्नुहुन्छ, यसैले यस क्षण मा झरेका परिवर्तनहरू फिर्ता रोलिंग। यस अवस्थामा, प्रणालीको अवस्था उस्तै हुनेछ, अर्थात् उस्तै श्रृंखलाहरू, उदाहरणका लागि, अद्यावधिक प्रक्रियाहरू, प्रणालीको विभिन्न अन्तिम अवस्थाहरूमा निम्त्याउने मामला हुनु हुँदैन।

स्रोत: www.habr.com