"हडूप. Mail.Ru ग्रुप टेक्नोस्ट्रीम मालिकेतील ZooKeeper "हडूपमधील डेटाच्या मोठ्या प्रमाणात वितरित प्रक्रियेसाठी पद्धती"

मी सुचवितो की तुम्ही "हडूप. झूकीपर" या व्याख्यानातील "हडूपमधील मोठ्या प्रमाणातील डेटाच्या वितरीत प्रक्रियेच्या पद्धती" या मालिकेतील उतारा वाचा

झूकीपर म्हणजे काय, हडूप इकोसिस्टममध्ये त्याचे स्थान. वितरित संगणनाबद्दल असत्य. प्रमाणित वितरण प्रणालीचे आकृती. वितरण प्रणालींमध्ये समन्वय साधण्यात अडचण. ठराविक समन्वय समस्या. ZooKeeper च्या डिझाइनमागील तत्त्वे. ZooKeeper डेटा मॉडेल. znode ध्वज. सत्रे. क्लायंट API. आदिम (कॉन्फिगरेशन, गट सदस्यत्व, साधे लॉक, लीडर इलेक्शन, हर्ड इफेक्टशिवाय लॉकिंग). झूकीपर आर्किटेक्चर. झूकीपर डीबी. ZAB. हँडलरची विनंती करा.

आज आपण ZooKeeper बद्दल बोलू. ही गोष्ट खूप उपयुक्त आहे. कोणत्याही Apache Hadoop उत्पादनाप्रमाणे, त्याचा लोगो आहे. हे एका माणसाचे चित्रण करते.

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

अशा ॲप्लिकेशन्सची गरज दिवसेंदिवस वाढत आहे, आमचा कोर्स हाच आहे. एकीकडे, MapReduce आणि हे तयार फ्रेमवर्क तुम्हाला ही जटिलता कमी करण्यास आणि प्रक्रियांचे परस्परसंवाद आणि समन्वय यासारख्या आदिम लेखनापासून प्रोग्रामरला मुक्त करण्यास अनुमती देते. पण दुसरीकडे, हे कसेही करावे लागणार नाही याची खात्री कोणीही देत ​​नाही. MapReduce किंवा इतर तयार फ्रेमवर्क नेहमी काही प्रकरणे पूर्णपणे बदलत नाहीत ज्यांचा वापर करून अंमलबजावणी केली जाऊ शकत नाही. स्वतः MapReduce आणि इतर Apache प्रकल्पांचा समावेश करून, ते देखील अनुप्रयोग वितरित केले जातात. आणि लेखन सोपे करण्यासाठी त्यांनी ZooKeeper लिहिले.

सर्व हडूप-संबंधित अनुप्रयोगांप्रमाणे, ते Yahoo! हे आता अधिकृत Apache अनुप्रयोग देखील आहे. हे HBase सारखे सक्रियपणे विकसित झालेले नाही. जर तुम्ही JIRA HBase वर गेलात, तर दररोज बग रिपोर्ट्सचा एक समूह, काहीतरी ऑप्टिमाइझ करण्यासाठी प्रस्तावांचा समूह, म्हणजे प्रकल्पातील जीवन सतत चालू असते. आणि ZooKeeper, एकीकडे, तुलनेने सोपे उत्पादन आहे, आणि दुसरीकडे, हे त्याची विश्वासार्हता सुनिश्चित करते. आणि हे वापरण्यास अगदी सोपे आहे, म्हणूनच हडूप इकोसिस्टममधील अनुप्रयोगांमध्ये ते एक मानक बनले आहे. त्यामुळे ते कसे कार्य करते आणि ते कसे वापरायचे हे समजून घेण्यासाठी त्याचे पुनरावलोकन करणे उपयुक्त ठरेल असे मला वाटले.

आमच्या काही व्याख्यानाचे हे चित्र आहे. आम्ही असे म्हणू शकतो की आम्ही आतापर्यंत विचारात घेतलेल्या प्रत्येक गोष्टीसाठी ते ऑर्थोगोनल आहे. आणि येथे सूचित केलेली प्रत्येक गोष्ट, एक किंवा दुसर्या प्रमाणात, ZooKeeper सह कार्य करते, म्हणजेच ही सर्व उत्पादने वापरणारी सेवा आहे. HDFS किंवा MapReduce दोघांनीही त्यांच्या स्वतःच्या समान सेवा लिहिल्या नाहीत ज्या त्यांच्यासाठी विशेषतः कार्य करतील. त्यानुसार झूकीपरचा वापर केला जातो. आणि हे विकास आणि त्रुटींशी संबंधित काही गोष्टी सुलभ करते.

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

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

नेटवर्क टोपोलॉजी बदलत आहे. टोपोलॉजी म्हणजे काय - हे आमच्या नेटवर्क उपकरणांचे प्लेसमेंट आहे. तेथे डेटा सेंटर आहेत, तेथे उभे असलेले रॅक आहेत, मेणबत्त्या आहेत. हे सर्व पुन्हा कनेक्ट केले जाऊ शकते, हलविले जाऊ शकते, इ. हे सर्व देखील लक्षात घेतले पाहिजे. IP नावे बदलतात, आमची रहदारी ज्या मार्गाने प्रवास करते ते बदलते. हे देखील लक्षात घेणे आवश्यक आहे.

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

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

एका प्रोसेसरसह एका संगणकावर चालणारा प्रोग्राम लिहिणे सोपे आहे.

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

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

जेव्हा आम्हाला आमची प्रक्रिया एकमेकांशी संवाद साधण्यास सुरुवात करायची असते, उदाहरणार्थ, एकमेकांना काही डेटा पाठवायचा, तेव्हा प्रश्न देखील उद्भवतो - हे कसे होईल? काही प्रकारची शर्यत स्थिती असेल, ते एकमेकांवर अधिलिखित करतील का, डेटा योग्यरित्या येईल का, वाटेत काही हरवले जाईल का? आम्हाला काही प्रकारचे प्रोटोकॉल विकसित करणे आवश्यक आहे.

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

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

आज आपण ZooKeeper बद्दल बोलत आहोत. एकीकडे, ही एक फ्रेमवर्क आहे, तर दुसरीकडे, ही एक सेवा आहे जी विकसकासाठी जीवन सुलभ करते आणि तर्कशास्त्र आणि आमच्या प्रक्रियांचे समन्वय शक्य तितके सोपे करते.

मानक वितरण प्रणाली कशी दिसू शकते हे लक्षात ठेवूया. आम्ही याबद्दल बोललो - HDFS, HBase. एक मास्टर प्रक्रिया आहे जी कामगार आणि गुलाम प्रक्रिया व्यवस्थापित करते. कामांचे समन्वय आणि वितरण, कामगार पुन्हा सुरू करणे, नवीन सुरू करणे आणि भार वितरित करणे यासाठी तो जबाबदार आहे.

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

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

एक आणखी प्रगत योजना आहे, जेव्हा आमच्याकडे मास्टर नसतो, तेव्हा सर्व नोड्स मास्टर स्लेव्ह असतात, त्यांच्या वर्तनात भिन्न असतात. परंतु तरीही त्यांना एकमेकांशी संवाद साधण्याची आवश्यकता आहे, म्हणून या क्रियांचे समन्वय साधण्यासाठी अद्याप काही सेवा बाकी आहे. कदाचित, या तत्त्वावर काम करणारी कॅसँड्रा या योजनेला बसते.

यापैकी कोणती योजना चांगली काम करते हे सांगणे कठीण आहे. प्रत्येकाचे स्वतःचे फायदे आणि तोटे आहेत.

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

आणि ही योजना (वरील) कदाचित अधिक जटिल, परंतु अधिक विश्वासार्ह आहे.

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

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

ZooKeeper अशा नकारांना सामोरे जाण्याचे मार्ग ऑफर करते, ज्यामुळे आपले जीवन देखील सोपे होते.

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

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

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

येथे आपण सिस्टम प्रक्रियेसाठी स्थिर कॉन्फिगरेशनबद्दल बोलत आहोत. हे पूर्णपणे नाही, कदाचित ऑपरेटिंग सिस्टमच्या दृष्टिकोनातून, हे आमच्या प्रक्रियेसाठी एक स्थिर कॉन्फिगरेशन असू शकते, म्हणजेच, हे एक कॉन्फिगरेशन आहे जे फक्त घेतले आणि अपडेट केले जाऊ शकत नाही.

डायनॅमिक कॉन्फिगरेशन देखील आहे. हे पॅरामीटर्स आहेत जे आम्ही फ्लायवर बदलू इच्छितो जेणेकरून ते तिथे उचलले जातील.

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

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

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

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

ZooKeeper तुम्हाला या सर्व समस्या एका किंवा दुसऱ्या प्रमाणात सोडवण्याची परवानगी देतो. आणि ते तुम्हाला हे कसे करण्यास अनुमती देते हे मी उदाहरणांसह दाखवीन.

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

सर्व क्लायंट विनंत्या सामान्य रांगेच्या क्रमाने प्रक्रिया केल्या जातात.

आणि क्लायंटला बदललेला डेटा स्वतः पाहण्यापूर्वी काही राज्यातील बदलांबद्दल, डेटामधील बदलांबद्दल सूचना प्राप्त करण्याची संधी ग्राहकांना असते.

झूकीपर दोन मोडमध्ये काम करू शकते. पहिला मोड स्टँडअलोन आहे, एकाच नोडवर. हे चाचणीसाठी सोयीस्कर आहे. ते क्लस्टर मोडमध्ये, कितीही नोड्सवर देखील काम करू शकते. सर्व्हरजर आपल्याकडे १०० मशीन्सचा क्लस्टर असेल, तर तो १०० मशीन्सवर चालण्याची गरज नाही. ZooKeeper चालवू शकेल अशा काही मशीन्स वाटून घेणे पुरेसे आहे. आणि ते उच्च उपलब्धतेच्या तत्त्वाचे पालन करते. ZooKeeper प्रत्येक चालू असलेल्या घटकावरील डेटाची संपूर्ण प्रत साठवते. ते हे कसे करते ते मी नंतर स्पष्ट करेन. ते डेटाचे तुकडे करत नाही किंवा विभाजन करत नाही. एकीकडे, हे एक गैरसोय आहे कारण आपण जास्त साठवू शकत नाही, परंतु दुसरीकडे, ते अनावश्यक आहे. ते त्यासाठी डिझाइन केलेले नाही; ते डेटाबेस नाही.

क्लायंटच्या बाजूने डेटा कॅश केला जाऊ शकतो. हे एक मानक तत्त्व आहे जेणेकरुन आम्ही सेवेमध्ये व्यत्यय आणू नये आणि समान विनंत्यांसह ती लोड करू नये. स्मार्ट क्लायंटला सहसा याबद्दल माहिती असते आणि ते कॅश करते.

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

ग्राहक हा वापरकर्ता आहे जो ZooKeeper वापरतो.

सर्व्हर ही ZooKeeper प्रक्रिया आहे.

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

ऑपरेशनचे दोन प्रकार आहेत. पहिले अपडेट/लिहा, जेव्हा काही ऑपरेशन्समुळे आपल्या झाडाची स्थिती बदलते. झाड सामान्य आहे.

आणि हे शक्य आहे की क्लायंट एक विनंती पूर्ण करत नाही आणि तो डिस्कनेक्ट झाला आहे, परंतु एक सत्र स्थापित करू शकतो ज्याद्वारे तो ZooKeeper शी संवाद साधतो.

ZooKeeper चे डेटा मॉडेल फाईल सिस्टीम सारखे आहे. एक मानक रूट आहे आणि मग आपण रूटपासून जाणाऱ्या डिरेक्टरीमधून गेलो आहोत. आणि नंतर पहिल्या स्तराचा कॅटलॉग, दुसरा स्तर. हे सर्व znodes आहे.

प्रत्येक znode काही डेटा संचयित करू शकतो, सहसा फार मोठा नसतो, उदाहरणार्थ, 10 किलोबाइट्स. आणि प्रत्येक झोनोडमध्ये विशिष्ट संख्येने मुले असू शकतात.

Znodes अनेक प्रकारात येतात. ते तयार केले जाऊ शकतात. आणि znode तयार करताना, तो कोणत्या प्रकारचा असावा हे आम्ही निर्दिष्ट करतो.

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

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

नियमित znode. ती नेहमी जगेल आणि तिचे नाव असेल जे आम्ही तिला सांगतो.

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

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

मी तुम्हाला सत्रांबद्दल थोडे सांगतो. जर आपल्याकडे अनेक सर्व्हर असतील तर आपण एका सर्व्हरवरून दुसऱ्या सर्व्हरवर पारदर्शकपणे स्विच करू शकतो. सर्व्हर, सत्र आयडी वापरून. हे खूप सोयीस्कर आहे.

प्रत्येक सत्राचा काही प्रकारचा कालबाह्य असतो. क्लायंट त्या सत्रादरम्यान सर्व्हरला काहीही पाठवतो की नाही यावर एक सत्र परिभाषित केले जाते. जर त्याने कालबाह्य दरम्यान काहीही प्रसारित केले नाही, तर सत्र बंद होईल किंवा क्लायंट स्वतः ते बंद करू शकेल.

यात इतकी वैशिष्ट्ये नाहीत, परंतु तुम्ही या API सह विविध गोष्टी करू शकता. आम्ही क्रिएट पाहिलेला कॉल एक znode तयार करतो आणि तीन पॅरामीटर्स घेतो. हा znode चा मार्ग आहे आणि तो रूट पासून संपूर्णपणे निर्दिष्ट करणे आवश्यक आहे. आणि हा काही डेटा आहे जो आम्हाला तिथे हस्तांतरित करायचा आहे. आणि ध्वजाचा प्रकार. आणि निर्मितीनंतर ते झोनोडचा मार्ग परत करते.

दुसरे, आपण ते हटवू शकता. येथे युक्ती अशी आहे की दुसरा पॅरामीटर, znode च्या मार्गाव्यतिरिक्त, आवृत्ती निर्दिष्ट करू शकतो. त्यानुसार, आम्ही हस्तांतरित केलेली झोनोडची आवृत्ती प्रत्यक्षात अस्तित्वात असलेल्या आवृत्तीशी समतुल्य असल्यास ती हटविली जाईल.

आम्ही ही आवृत्ती तपासू इच्छित नसल्यास, आम्ही फक्त "-1" युक्तिवाद पास करतो.

तिसरे, ते znode चे अस्तित्व तपासते. नोड अस्तित्वात असल्यास खरे मिळवते, अन्यथा असत्य.

आणि नंतर ध्वज घड्याळ दिसते, जे आपल्याला या नोडचे परीक्षण करण्यास अनुमती देते.

तुम्ही हा ध्वज अस्तित्वात नसलेल्या नोडवरही सेट करू शकता आणि जेव्हा तो दिसेल तेव्हा सूचना प्राप्त करू शकता. याचाही उपयोग होऊ शकतो.

आणखी काही आव्हाने आहेत डेटा मिळवा. हे स्पष्ट आहे की आम्ही znode द्वारे डेटा प्राप्त करू शकतो. आपण ध्वज घड्याळ देखील वापरू शकता. या प्रकरणात, नोड नसल्यास ते स्थापित होणार नाही. म्हणून, आपल्याला ते अस्तित्वात आहे हे समजून घेणे आवश्यक आहे आणि नंतर डेटा प्राप्त करा.

तसेच आहे डेटा सेट करा. येथे आम्ही आवृत्ती पास करतो. आणि जर आपण हे चालू केले तर, विशिष्ट आवृत्तीच्या znode वरील डेटा अद्यतनित केला जाईल.

हा चेक वगळण्यासाठी तुम्ही "-1" देखील निर्दिष्ट करू शकता.

दुसरी उपयुक्त पद्धत आहे मुले मिळवा. आम्ही त्याच्याशी संबंधित सर्व znodes ची यादी देखील मिळवू शकतो. आम्ही फ्लॅग वॉच सेट करून याचे निरीक्षण करू शकतो.

आणि पद्धत समक्रमण सर्व बदल एकाच वेळी पाठविण्यास अनुमती देते, ज्यामुळे ते जतन केले गेले आहेत आणि सर्व डेटा पूर्णपणे बदलला गेला आहे याची खात्री करते.

जर आम्ही नियमित प्रोग्रामिंगसह समानता काढली, तर जेव्हा तुम्ही राईट सारख्या पद्धती वापरता, जे डिस्कवर काहीतरी लिहिते आणि ते तुम्हाला प्रतिसाद देते, तेव्हा तुम्ही डिस्कवर डेटा लिहिला आहे याची खात्री नसते. आणि जरी ऑपरेटिंग सिस्टमला खात्री आहे की सर्वकाही लिहिले गेले आहे, डिस्कमध्येच अशी यंत्रणा आहेत जिथे प्रक्रिया बफरच्या स्तरांमधून जाते आणि त्यानंतरच डेटा डिस्कवर ठेवला जातो.

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

आम्ही ज्या दोन ऑपरेशन्सबद्दल बोललो ते अपडेट/लिहा, जे डेटा बदलतात. हे तयार करा, डेटा सेट करा, सिंक करा, हटवा. आणि वाचन अस्तित्वात आहे, getData, getChildren.

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

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

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

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

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

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

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

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

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

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

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

येथे तथाकथित हर्ड इफेक्ट उद्भवतो, म्हणजे झुंड प्रभाव, कारण जेव्हा नेता मरण पावतो, तेव्हा जो प्रथम असेल तो नेता होईल.

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

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

ZooKeeper मध्ये काय असते? 4 मुख्य गोष्टी आहेत. ही प्रक्रिया प्रक्रिया आहे - विनंती. आणि ZooKeeper Atomic Broadcast देखील. एक कमिट लॉग आहे जिथे सर्व ऑपरेशन्स रेकॉर्ड केल्या जातात. आणि इन-मेमरी रिप्लिकेटेड डीबी स्वतः, म्हणजे डेटाबेस स्वतः जिथे हे संपूर्ण झाड साठवले जाते.

हे लक्षात घेण्यासारखे आहे की सर्व लेखन ऑपरेशन्स विनंती प्रोसेसरद्वारे जातात. आणि रीड ऑपरेशन्स थेट इन-मेमरी डेटाबेसवर जातात.

डेटाबेस स्वतः पूर्णपणे प्रतिकृती आहे. ZooKeeper ची सर्व उदाहरणे डेटाची संपूर्ण प्रत संग्रहित करतात.

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

ZooKeeper Atomic Broadcast ही अशी गोष्ट आहे जी प्रतिकृत डेटा राखण्यासाठी वापरली जाते.

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

हे फक्त विनंत्या लिहिण्याची प्रक्रिया करते. त्याचे मुख्य कार्य हे आहे की ते ऑपरेशनला व्यवहाराच्या अद्यतनात रूपांतरित करते. ही खास तयार केलेली विनंती आहे.

आणि येथे हे लक्षात घेण्यासारखे आहे की त्याच ऑपरेशनसाठी अद्यतनांच्या इडम्पोटेन्सीची हमी दिली जाते. हे काय आहे? ही गोष्ट, जर दोनदा अंमलात आणली गेली, तर तिची स्थिती समान असेल, म्हणजेच विनंती स्वतःच बदलणार नाही. आणि हे करणे आवश्यक आहे जेणेकरून क्रॅश झाल्यास, आपण ऑपरेशन रीस्टार्ट करू शकता, त्याद्वारे या क्षणी पडलेले बदल परत आणू शकता. या प्रकरणात, सिस्टमची स्थिती सारखीच होईल, म्हणजे असे होऊ नये की समान मालिका, उदाहरणार्थ, अद्ययावत प्रक्रियेमुळे, सिस्टमच्या भिन्न अंतिम स्थिती निर्माण होतात.

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