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