ज़ूकीपर बनाम इन-मेमोरी-डेटा-ग्रिड बनाम रेडिस

https://zookeeper.apache.org/doc/current/zookeeperOver.html

डिफ़ॉल्ट रूप से, ज़ूकीपर आपके सभी डेटा को प्रत्येक नोड में दोहराता है और ग्राहकों को परिवर्तनों के लिए डेटा देखने देता है। ग्राहकों को परिवर्तन बहुत जल्दी (एक सीमित समय के भीतर) भेजे जाते हैं। आप "अल्पकालिक नोड्स" भी बना सकते हैं, जो क्लाइंट के डिस्कनेक्ट होने पर एक निर्दिष्ट समय के भीतर हटा दिए जाते हैं। ZooKeeper पढ़ने . के लिए अत्यधिक अनुकूलित है , जबकि लिखना बहुत धीमा होता है (चूंकि वे आम तौर पर प्रत्येक क्लाइंट को जैसे ही लिखते हैं, उन्हें भेज दिया जाता है)। अंत में, ज़ूकीपर में "फ़ाइल" (ज़्नोड) का अधिकतम आकार 1MB है, लेकिन आम तौर पर वे सिंगल स्ट्रिंग्स होंगे।

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

मूल रूप से, ज़ूकीपर (और क्यूरेटर, जो उस पर बनाया गया है) क्लस्टरिंग के यांत्रिकी को संभालने में मदद करता है - दिल की धड़कन, अपडेट/कॉन्फ़िगरेशन वितरित करना, वितरित ताले, आदि।

यह वास्तव में Redis से तुलनीय नहीं है, लेकिन विशिष्ट प्रश्नों के लिए...

1. यह किसी भी गणना का समर्थन नहीं करता है और अधिकांश डेटा सेट के लिए, किसी भी प्रदर्शन के साथ डेटा संग्रहीत करने में सक्षम नहीं होगा।

2. यह क्लस्टर में सभी नोड्स के लिए दोहराया गया है (रेडिस क्लस्टरिंग जैसा कुछ भी नहीं है जहां डेटा वितरित किया जा सकता है)। सभी संदेशों को परमाणु रूप से पूर्ण रूप से संसाधित किया जाता है और अनुक्रमित किया जाता है, इसलिए कोई वास्तविक लेनदेन नहीं होता है। इसका उपयोग आपकी सेवाओं के लिए क्लस्टर-वाइड लॉक को लागू करने के लिए किया जा सकता है (यह वास्तव में उस पर बहुत अच्छा है), और tehre znodes पर स्वयं को नियंत्रित करने के लिए बहुत सारे लॉकिंग प्रिमिटिव हैं जो यह नियंत्रित करते हैं कि कौन से नोड उन्हें एक्सेस करते हैं।

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

लिंक किए गए प्रश्न का उद्धरण...

ज़ूकीपर के उपयोग का एक विहित उदाहरण वितरित-स्मृति संगणना है

... है, आईएमओ, थोड़ा भ्रामक। आप इसका उपयोग गणना को व्यवस्थित करने के लिए करेंगे, न कि डेटा प्रदान करने के लिए। उदाहरण के लिए, मान लें कि आपको किसी तालिका की पंक्तियों 1-100 को संसाधित करना है। आप "1-10", "11-20", "21-30", आदि जैसे नामों के साथ 10 ZK नोड्स को ऊपर रख सकते हैं। क्लाइंट एप्लिकेशन को ZK द्वारा स्वचालित रूप से इस परिवर्तन के बारे में सूचित किया जाएगा, और पहला " 1-10" और एक क्षणिक नोड सेट करें clients/192.168.77.66/processing/rows_1_10

अगला आवेदन इसे देखेगा और अगले समूह को संसाधित करने के लिए जाएगा। गणना करने के लिए वास्तविक डेटा कहीं और संग्रहीत किया जाएगा (यानी रेडिस, एसक्यूएल डेटाबेस, आदि)। यदि नोड गणना के माध्यम से विफल हो जाता है, तो दूसरा नोड इसे (30-60 सेकंड के बाद) देख सकता है और फिर से काम शुरू कर सकता है।

मैं कहूंगा कि ज़ूकीपर का विहित उदाहरण नेता चुनाव है, हालाँकि। मान लीजिए कि आपके पास 3 नोड हैं - एक मास्टर है और दूसरा 2 गुलाम है। यदि मास्टर नीचे चला जाता है, तो दास नोड को नया नेता बनना होगा। इस प्रकार की चीज़ ZK के लिए एकदम सही है।