RedisRaft: फॉल्ट-टॉलरेंट Redis क्लस्टर के लिए स्ट्रॉन्ग-कंसिस्टेंसी मॉड्यूल

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

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

RedisRaft की शुरुआत

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

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

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

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

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

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

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

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

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

पहले सर्वर से कनेक्ट करने और Raft क्लस्टर बनाने का तरीका यहां है:

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 नोड्स) के लिए दोहराया गया है, और उनके स्थिर स्टोरेज में कमिट किया गया है।

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

एक फॉलोअर (गैर-लीडर) नोड पर वही ऑपरेशन आज़माने से यह प्रतिक्रिया मिलती है:

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

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

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

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

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

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

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

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

इसके बाद, हम उस ID को देखते हैं जिसे बेतरतीब ढंग से हमारे तीसरे नोड को सौंपा गया था:

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 विकास कार्य के हिस्से के रूप में, हम Kyle Kingsbury (a.k.a Aphyr) के साथ मिलकर RedisRaft का विश्लेषण और परीक्षण करने के लिए Jepsen का उपयोग कर रहे हैं, जो वितरित प्रणालियों की सुरक्षा और शुद्धता का परीक्षण करने के लिए एक प्रसिद्ध फ्रेमवर्क है। इस सहयोग का परिणाम अब तक यह प्रकाशित विश्लेषण है।

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