RedisRaft का परिचय, एक नया मजबूत-संगति परिनियोजन विकल्प

RedisRaft (विकासाधीन) ओपन सोर्स Redis के लिए एक नया मॉड्यूल है जो एकल दोष-सहिष्णु, दृढ़ता से संगत क्लस्टर के रूप में कई Redis सर्वरों को संचालित करना संभव बनाता है। जैसा कि इसके नाम से पता चलता है, यह बेड़ा आम सहमति एल्गोरिथ्म और एक ओपन-सोर्स सी लाइब्रेरी पर आधारित है जो इसे लागू करता है।

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

RedisRaft की शुरुआत

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

RedisRaft क्लस्टर विश्वसनीय, प्रसिद्ध डेटा स्टोर जैसे ZooKeeper या Etcd से अपेक्षित समान स्तर की स्थिरता और विश्वसनीयता प्रदान करता है। संक्षेप में, RedisRaft में:

• स्वीकृत लेखन प्रतिबद्ध होने की गारंटी है और कभी नहीं खोया है।
• रीड्स हमेशा सबसे अप-टू-डेट प्रतिबद्ध लेखन लौटाएगा।

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

• क्लाइंट संचालन क्लस्टर नोड्स पर संदेशों का आदान-प्रदान करने पर निर्भर करता है, इसलिए वे नेटवर्क विलंबता के लिए बाध्य हो जाते हैं।
• लिखने को पूरा करने से पहले डिस्क पर फ्लश किया जाना चाहिए, ताकि वे डिस्क I/O विलंबता के लिए बाध्य हो जाएं।
• क्लस्टर केवल तब तक उपलब्ध है जब तक कि अधिकांश नोड ऊपर, स्वस्थ और एक दूसरे के साथ संवाद करने में सक्षम हैं।

RedisRaft कैसे काम करता है

एक बार जब RedisRaft मॉड्यूल Redis में लोड हो जाता है, तो यह क्लस्टर नोड्स के बीच संचार को संभाल लेता है, Raft लॉग या स्नैपशॉट की प्रतिकृति, दृढ़ता, और इसी तरह। रेडिस कोर इससे अनजान है और जहां तक ​​इसका संबंध है, यह बिना किसी क्लस्टरिंग, दृढ़ता या प्रतिकृति के एक स्टैंडअलोन सर्वर के रूप में काम कर रहा है।

तीन-नोड RedisRaft क्लस्टर सेट करना तीन Redis सर्वर शुरू करने जितना आसान है, जैसा कि यहां दिखाया गया है:

redis-server --loadmodule /path/to/redisraft.so

पहले सर्वर से कनेक्ट करने और राफ्ट क्लस्टर बनाने का तरीका इस प्रकार है:

10.0.0.1:6379> RAFT.CLUSTER INIT
OK 989645460313dd2ddb051f033c791222

फिर आप अन्य दो सर्वरों से जुड़ते हैं और उन्हें क्लस्टर से जोड़ते हैं:

10.0.0.2:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
10.0.0.3:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

क्लस्टर तक पहुंच

RedisRaft सेट हो जाने के बाद, हम अपने क्लस्टर में डेटा लिख ​​सकते हैं:

10.0.0.1:6379> INCR counter:1
(integer) 1

उत्तर प्राप्त करने से पता चलता है कि हमारे लेखन को कम से कम . पर दोहराया गया है अधिकांश क्लस्टर नोड्स (हमारे मामले में 2 नोड्स), और उनके निरंतर भंडारण के लिए प्रतिबद्ध हैं।

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

अनुयायी (गैर-नेता) नोड पर एक ही ऑपरेशन की कोशिश करने से यह प्रतिक्रिया उत्पन्न होती है:

10.0.0.3:6379> INCR counter:1
(error) MOVED 10.0.0.1:6379

इसलिए एक क्लाइंट के रूप में, अब हम इस त्रुटि को पकड़ सकते हैं, निर्दिष्ट किए गए अनुसार लीडर नोड के साथ एक कनेक्शन फिर से स्थापित कर सकते हैं, और अपने आदेश का पुनः प्रयास कर सकते हैं।

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

10.0.0.3:6379> RAFT.CONFIG SET follower-proxy yes
OK
10.0.0.3:6379> INCR counter:1
(integer) 2

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

क्लस्टर परिवर्तन

अपना क्लस्टर सेट करते समय, हमने वास्तव में तीन अलग-अलग ऑपरेशन किए हैं:

1. एक नोड पर क्लस्टर बनाया।
2. दूसरा नोड जोड़ा गया।
3. तीसरा नोड जोड़ा गया।

RedisRaft क्लस्टर कॉन्फ़िगरेशन स्थिर नहीं है, और क्लस्टर बनने के बाद और सक्रिय होने के दौरान अतिरिक्त नोड्स जोड़ना या निकालना संभव है।

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

10.0.0.4:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

इसके बाद, हम उस आईडी को देखते हैं जो हमारे तीसरे नोड को यादृच्छिक रूप से असाइन किया गया था:

redis-cli -h 10.0.0.1 --raw RAFT.INFO | grep 10.0.0.3
node2:id=1739451728,state=connected,voting=yes,addr=10.0.0.3,port=6379,
last_conn_secs=3537,conn_errors=0,conn_oks=1

और फिर हम इसे हटा देते हैं:

10.0.0.1:6379> RAFT.NODE REMOVE 1739451728
OK

RedisRaft रिलीज़ स्थिति

RedisRaft विकास कार्य के भाग के रूप में, हम वितरित प्रणालियों की सुरक्षा और शुद्धता का परीक्षण करने के लिए एक प्रसिद्ध ढांचे, Jepsen का उपयोग करके RedisRaft का विश्लेषण और परीक्षण करने के लिए काइल किंग्सबरी (a.k.a Aphyr) के साथ सहयोग कर रहे हैं। इस सहयोग के परिणामस्वरूप अब तक यह प्रकाशित विश्लेषण हुआ है।

हालांकि अभी भी विकास के अधीन है, रेडिसराफ्ट की अधिकांश बुनियादी कार्यक्षमता जगह में है। वर्तमान में हम पहले पूर्वावलोकन संस्करण की दिशा में काम कर रहे हैं, जिसके कुछ महीनों में उपलब्ध होने की उम्मीद है। जब आम तौर पर उपलब्ध होता है, तो RedisRaft को दोहरे लाइसेंस के तहत जारी किया जाएगा, या तो GNU AGPLv3 या Redis स्रोत उपलब्ध लाइसेंस (RSAL)।