Redis 7.0 का रिलीज़ ट्रैक पर है, और हमने अभी इसका दूसरा रिलीज़ कैंडिडेट प्रकाशित किया है। यह रिलीज़ कैंडिडेट संस्करण की सुविधाओं को पूरा करने का एक नियोजित मील का पत्थर है, लेकिन यह नए संस्करण में अतिरिक्त सामग्री प्रस्तुत करने का अवसर भी है। उदाहरण के लिए, Redis Functions विकसित हुआ है जो Redis के पास संस्करण 2.6 से स्क्रिप्टिंग के लिए मौजूदा समर्थन था। इसी तरह, Redis की अधिक सुविधाएं विकसित हुई हैं।
प्रकृति में, विकास स्पष्ट रूप से यादृच्छिक रूप से होता है और प्राकृतिक चयन इसके परिणामों को छांटने का ख्याल रखता है। आम तौर पर, सॉफ्टवेयर में सामान्य रूप से, और विशेष रूप से Redis के साथ, यह प्रक्रिया पीछे की ओर होती है: हम वांछित पथ का चयन करते हैं और परियोजना को उसके अनुसार विकसित करते हैं। यादृच्छिकता को भविष्य तय करने देने के बजाय, हमारे रोडमैप की योजना और निष्पादन मुख्य रूप से उपयोगकर्ताओं की प्रतिक्रिया और नए उपयोग के मामलों द्वारा निर्देशित होते हैं जहां Redis एक अच्छा फिट है।
Redis 7.0 में, एक्सेस कंट्रोल लिस्ट (ACL) ने भी विकासवादी सीढ़ी पर कदम रखा है। Redis 6.0 में पेश किया गया, ACL ने उपयोगकर्ताओं और उनकी अनुमतियों को प्रबंधित करने के लिए तंत्र जोड़कर सुरक्षा के बारे में लंबे समय से चले आ रहे दृष्टिकोण को उलट दिया था कि यह परियोजना के दायरे से बाहर है। हालांकि, हमारे समुदाय ने हमें जल्दी से शिक्षित किया कि जबकि यह सही दिशा में उठाया गया एक कदम था, इस सुविधा में अभी भी आवश्यक क्षमताओं की कमी थी।
ACL में अंतराल में से एक को पहले ही Redis 6.2 द्वारा संबोधित किया गया था, अर्थात् Pub/Sub चैनल नामों के अनुमत पैटर्न को नियंत्रित करना। लेकिन यह केवल एक आंशिक स्टॉप-गैप था और शेष को संबोधित करने के लिए एक सरल और प्रभावी दृष्टिकोण के साथ आने में हमें अधिक समय लगा।
ACL के मूल डिजाइन ने केवल बुनियादी अनुमति-नियंत्रण उपयोग के मामलों के लिए प्रावधान किया था। यह प्रति उपयोगकर्ता कमांड, कुंजियों, और चैनलों के नाम पैटर्न के एकल सेट तक पहुंच प्रदान करने या अस्वीकार करने में सक्षम था। उदाहरण के लिए, किसी दिए गए उपयोगकर्ता के लिए `SET` कमांड को कुंजियों के एक सबसेट तक सीमित करना, और साथ ही `GET` को कुंजियों के दूसरे सबसेट की अनुमति देना असंभव था। प्रभावी रूप से, ACL सुरक्षा नीतियों को लागू करने के लिए एक प्रभावी तंत्र नहीं था।
Redis 7.0 की एक्सेस कंट्रोल लिस्ट, या संक्षेप में ACLv2, मूल के साथ संगत है लेकिन दो महत्वपूर्ण सुधार जोड़ता है। सबसे पहले, ACLv2 सेलेक्टर्स के बारे में है। दूसरा, ACLv2 विशिष्ट कुंजियों के लिए एक्सेस प्रकार की अनुमतियां सेट करने की अनुमति देता है। यह क्षमता उपयोगकर्ता को विशेष रूप से कुंजियों के सबसेट पर रीड-ओनली, राइट-ओनली, या रीड-राइट ऑपरेशंस तक सीमित करना संभव बनाती है।
मूल ACL डिजाइन ने प्रति उपयोगकर्ता केवल एक सेलेक्टर प्रदान किया - डिफ़ॉल्ट सेलेक्टर। सेलेक्टर उन कुंजियों और चैनलों का वर्णन करता है जिन्हें उपयोगकर्ता एक्सेस कर सकता है, श्रेणियां और कमांड। ACLv2 डिफ़ॉल्ट के शीर्ष पर किसी भी संख्या में सेलेक्टर जोड़ने की अनुमति देता है जो क्रम में लागू होते हैं। यह दृष्टिकोण अधिक मांग वाली सुरक्षा नीतियों की आवश्यकताओं को पूरा करता है और ACL को पूर्णता के करीब लाता है।
सर्वर की आत्मनिरीक्षण क्षमताएं Redis का एक और पहलू हैं जो संस्करण 7.0 में काफी उन्नत हुई हैं। Redis एक API, इसके कमांड के डिक्शनरी को उजागर करता है, जिसके माध्यम से यह इंटरैक्ट करता है। जैसे-जैसे परियोजना विकसित हुई, विभिन्न कमांड (और उनके सब-कमांड) की संख्या बढ़ी, जो संस्करण 7.0 में 380 से अधिक हो गई। चूंकि हर Redis कमांड दिए गए कार्यों के लिए विशेष है, प्रत्येक कमांड के आह्वान तर्क और व्यवहार का दस्तावेजीकरण परियोजना का एक मुख्य सिद्धांत है। यह दस्तावेजीकरण सर्वर और उसके क्लाइंट के बीच एकमात्र अनुबंध है।
ऐतिहासिक रूप से, कमांड को परियोजना के बाहर एक अलग कोड रिपॉजिटरी में बाहरी रूप से प्रलेखित किया गया था। हमने सभी दस्तावेजीकरण को (अधिकतर) मानव-पठनीय प्रारूप में रखा क्योंकि इसका इरादा लोगों द्वारा पढ़ा जाना था। इसने मशीनों (या बल्कि, जो लोग मशीनों को प्रोग्राम करते हैं) के लिए एक चुनौती पेश की क्योंकि गद्य को कोड में अनुवाद करना गन्दा और भंगुर है। विशेष रूप से, Redis के लिए क्लाइंट के लेखक केवल डॉक्यूमेंटेशन में परिवर्तनों की निगरानी करके और रिलीज नोट्स पढ़कर अपनी परियोजना को अद्यतन रखने की उम्मीद कर सकते थे।
इसलिए, संस्करण 2.8 तक, हमने महसूस किया कि हमें एक प्रोग्रामेटिक तरीके की भी आवश्यकता है जो सर्वर को अपने कमांड की रिपोर्ट करने की अनुमति दे। उपयुक्त नाम वाला (लेकिन जीभ-घुमाने वाला भी) `COMMAND` कमांड रनटाइम में उन कमांड को सूचीबद्ध करता है जो सर्वर समर्थन करता है। इसके अलावा, `COMMAND GETKEYS` सबकमांड क्लाइंट को एक शब्दशः कमांड और उसके तर्क भेजने देता है ताकि सर्वर उससे किसी भी कुंजी के नाम निकाल सके। कमांड से कुंजी नाम निकालना आवश्यक है ताकि क्लाइस्टर डिप्लॉयमेंट में ऑपरेशन को सही ढंग से निर्देशित किया जा सके।
आंशिक रूप से ACLv2-संबंधित प्रयासों से प्रेरित लेकिन रनटाइम कमांड सूची को क्लाइंट के लिए अधिक उपयोगी बनाने के लिए भी, संस्करण 7.0 सर्वर के कमांड प्रबंधन के आंतरिक तंत्र के बहुत से हिस्से को ओवरहाल करता है। इसके अलावा, हमने सर्वर द्वारा प्रत्येक कमांड के बारे में रखे गए मेटाडेटा को समृद्ध किया है, जिससे परिष्कृत क्लाइंट बनाना संभव हो जाता है जिनके पास सर्वर की क्षमताओं के बारे में (लगभग) कोई पूर्व ज्ञान नहीं होता। अंत में, संशोधित कमांड टेबल इस तरह से बनाई गई है कि Redis मॉड्यूल इसे अपने संबंधित कमांड के साथ विस्तारित कर सकते हैं, ताकि कोर कमांड के समान स्तर का आत्मनिरीक्षण प्रदान किया जा सके।
नई कमांड कुंजी विशिष्टताएं क्लाइंट को क्लस्टर के सर्वर को शामिल किए बिना शब्दशः कमांड से स्थानीय रूप से कुंजियों को निकालने की अनुमति देती हैं, इस प्रकार लेटेंसी में सुधार और नेटवर्क बैंडविड्थ को कम करती हैं। कमांड तर्कों के बारे में मेटाडेटा क्लाइंट को सर्वर संस्करणों के बीच कमांड सिंटैक्स में परिवर्तनों की खोज और अनुकूलन करने देता है। क्लाइंट कमांड टिप्स से विशेष परिस्थितियों और विभिन्न डिप्लॉयमेंट प्रकारों के तहत कमांड निष्पादित करने के बारे में और भी अधिक जानकारी प्राप्त कर सकते हैं।
इस प्रयास में सबकमांड को सर्वर की कमांड टेबल के फर्स्ट-क्लास नागरिकों के रूप में पदोन्नत करना भी शामिल था। मूल रूप से, सबकमांड को Redis में पेश किया गया था ताकि API की लगातार बढ़ती कार्डिनैलिटी का मुकाबला किया जा सके। तर्क यह था कि हर कार्य के लिए एक नया कमांड जोड़ने के बजाय, संबंधित कार्यों को केवल एक "पेरेंट" कमांड को कॉल करके आमंत्रित किया जाता है। "पेरेंट" कमांड अपने पहले तर्क के रूप में सबकमांड का नाम स्वीकार करता है, जो बदले में किए गए एक्शन को निर्धारित करता है। तकनीकी दृष्टिकोण से, सबकमांड अपने पेरेंट कमांड के सभी लक्षणों (जैसे, ACL श्रेणी, रीड/राइट फ्लैग, कुंजी विनिर्देश, आदि) को विरासत में लेते थे, जिससे उनके विभिन्न व्यवहारों के बीच एक बारीक अंतर प्राप्त करना असंभव हो जाता था।
उदाहरण के लिए, `CLIENT` कमांड कनेक्शन प्रबंधन कार्यों के लिए एक कैच-ऑल बास्केट है जिसमें कम से कम 15 अलग-अलग सबकमांड हैं। इसके कुछ सबकमांड, जैसे `CLIENT SETNAME`, सामान्य क्लाइंट कनेक्शन द्वारा नियमित रूप से कॉल किए जाते हैं, जबकि अन्य जैसे `CLIENT KILL` में दुरुपयोग की संभावना होती है और इसलिए उन्हें केवल एडमिन उपयोग तक सीमित रखा जाना चाहिए। Redis के पहले के संस्करणों में ऐसे अंतर करने का समर्थन करने वाले आंतरिक तंत्र का अभाव था, जिससे डेवलपर्स को डॉक्यूमेंटेशन की ओर निर्देशित किया जाता था और भ्रम पैदा होता था। Redis 7.0 में, हालांकि, हर सबकमांड के पास पेरेंट्स या सिबलिंग्स की परवाह किए बिना लक्षणों का अपना सेट होता है, जिससे इसके सटीक विवरण की अनुमति मिलती है।
यह पोस्ट काफी टेक्स्ट की दीवार बन गई है जो शायद अपने अंत की ओर बहुत अधिक तकनीकी विस्तार में जाती है (अगर ऐसा कुछ है जैसे बहुत अधिक तकनीकी विस्तार)। हम आशा करते हैं कि यह सब उबाऊ नहीं था, और हमने नए संस्करण और परियोजना में इसके फिट पर कुछ प्रकाश डाला है। हम संस्करण की सामान्य उपलब्धता की ओर अंतिम रिलीज कैंडिडेट पर काम कर रहे हैं, लेकिन इस श्रृंखला में हमारी अगली पोस्ट के लिए बने रहें जो नए संस्करण के दौरे को जारी रखेगी।
