Redis का उपयोग करके वितरित लॉकिंग

हे हबर!

आज हम आपके ध्यान में रेडिस का उपयोग करके वितरित लॉकिंग के कार्यान्वयन के बारे में एक जटिल लेख का अनुवाद लाते हैं और आपको एक विषय के रूप में रेडिस की संभावनाओं के बारे में बात करने के लिए आमंत्रित करते हैं। पुस्तक के लेखक मार्टिन क्लेपमैन से प्रश्न में रेडलॉक एल्गोरिदम का विश्लेषणउच्च लोड अनुप्रयोग", दिया गया यहां.

वितरित लॉकिंग एक बहुत ही उपयोगी प्रिमिटिव है जिसका उपयोग कई वातावरणों में किया जाता है जहां विभिन्न प्रक्रियाओं को पारस्परिक रूप से विशिष्ट तरीके से साझा संसाधनों पर काम करना होता है।

वहां कई लाइब्रेरी और पोस्ट हैं जो वर्णन करती हैं कि रेडिस का उपयोग करके डीएलएम (डिस्ट्रिब्यूटेड लॉक मैनेजर) को कैसे कार्यान्वित किया जाए, लेकिन प्रत्येक लाइब्रेरी एक अलग दृष्टिकोण अपनाती है और जो गारंटी वे प्रदान करते हैं वह थोड़े अधिक परिष्कृत डिजाइन के साथ प्राप्त की जाने वाली गारंटी की तुलना में काफी कमजोर है।

इस लेख में हम एक सशर्त विहित एल्गोरिथ्म का वर्णन करने का प्रयास करेंगे जो दर्शाता है कि रेडिस का उपयोग करके वितरित लॉकिंग को कैसे लागू किया जाए। हम नामक एल्गोरिदम के बारे में बात करेंगे रेडलॉक, यह एक वितरित लॉक मैनेजर को कार्यान्वित करता है और, हमारी राय में, यह एल्गोरिदम सामान्य सिंगल-इंस्टेंस दृष्टिकोण से अधिक सुरक्षित है। हमें उम्मीद है कि समुदाय इसका विश्लेषण करेगा, प्रतिक्रिया देगा और इसे अधिक जटिल या वैकल्पिक परियोजनाओं के लिए शुरुआती बिंदु के रूप में उपयोग करेगा।

कार्यान्वयन

एल्गोरिदम के विवरण पर आगे बढ़ने से पहले, हम तैयार कार्यान्वयन के लिए कई लिंक प्रदान करते हैं। उनका उपयोग संदर्भ के लिए किया जा सकता है.

• रेडलॉक-आरबी (रूबी के लिए कार्यान्वयन)। वहाँ भी है काँटा रेडलॉक-आरबी, जो वितरण में आसानी के लिए एक पैकेज (रत्न) जोड़ता है, न कि केवल उसके लिए।
• रेडलॉक-पाइ (पायथन कार्यान्वयन)।
• एयोरेडलॉक (एसिंसिओ पायथन के लिए कार्यान्वयन)।
• रेडलॉक-php (PHP के लिए कार्यान्वयन)।
• PHPRedisMutex (PHP के लिए एक और कार्यान्वयन)
• चेप्रासोव/पीएचपी-रेडिस-लॉक (ताले के लिए PHP लाइब्रेरी)
• रेडसिंक (गो के लिए कार्यान्वयन)।
• रेडिसन (जावा के लिए कार्यान्वयन)।
• रेडिस::डिस्टलॉक (पर्ल के लिए कार्यान्वयन)।
• रेडलॉक-सीपीपी (सी++ के लिए कार्यान्वयन)।
• रेडलॉक-सीएस (C#/.NET के लिए कार्यान्वयन)।
• RedLock.net (C#/.NET के लिए कार्यान्वयन)। एसिंक और लॉक एक्सटेंशन के समर्थन के साथ।
• स्कार्लेटलॉक (कॉन्फ़िगर करने योग्य डेटा स्टोर के साथ C# .NET के लिए कार्यान्वयन)
• रेडलॉक4नेट (C# .NET के लिए कार्यान्वयन)
• नोड-रेडलॉक (नोडजेएस के लिए कार्यान्वयन)। ताले को विस्तारित करने के लिए समर्थन शामिल है।

सुरक्षा और उपलब्धता की गारंटी

हम अपने डिज़ाइन को केवल तीन गुणों के साथ मॉडल करने जा रहे हैं जो हमें लगता है कि वितरित लॉकिंग का प्रभावी ढंग से उपयोग करने के लिए आवश्यक न्यूनतम गारंटी प्रदान करते हैं।

1. सुरक्षा संपत्ति: पारस्परिक बहिष्कार. किसी भी समय, केवल एक ग्राहक ही ताला पकड़ सकता है।
2. उपलब्धता संपत्ति ए: कोई गतिरोध नहीं। अंततः लॉक प्राप्त करना हमेशा संभव होता है, भले ही संसाधन लॉक करने वाला क्लाइंट विफल हो जाए या किसी भिन्न डिस्क सेगमेंट पर आ जाए।
3. उपलब्धता संपत्ति बी: दोष सहिष्णुता। जब तक अधिकांश रेडिस नोड चल रहे हैं, ग्राहक लॉक प्राप्त करने और जारी करने में सक्षम हैं।

इस मामले में विफलता पुनर्प्राप्ति पर आधारित कार्यान्वयन पर्याप्त क्यों नहीं है?
यह समझने के लिए कि हम क्या सुधार करने जा रहे हैं, आइए रेडिस पर आधारित अधिकांश वितरित लॉकिंग लाइब्रेरीज़ की वर्तमान स्थिति का विश्लेषण करें।

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

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

जाहिर है, ऐसे मॉडल में एक दौड़ की स्थिति उत्पन्न होती है:

1. क्लाइंट A मास्टर पर लॉक प्राप्त कर लेता है।
2. कुंजी प्रविष्टि को दास को स्थानांतरित करने से पहले मास्टर विफल हो जाता है।
3. अनुयायी को नेता के रूप में पदोन्नत किया जाता है।
4. क्लाइंट B उसी संसाधन पर लॉक प्राप्त करता है जिसे A ने पहले ही लॉक कर दिया है। सुरक्षा उल्लंघन!

कभी-कभी यह पूरी तरह से सामान्य है कि विशेष परिस्थितियों में, जैसे कि विफलता, कई ग्राहक एक ही समय में ताला लगा सकते हैं। ऐसे मामलों में, प्रतिकृति-आधारित समाधान लागू किया जा सकता है। अन्यथा, हम इस आलेख में वर्णित समाधान की अनुशंसा करते हैं।

एक ही उदाहरण से सही कार्यान्वयन

ऊपर वर्णित एकल-आवृत्ति कॉन्फ़िगरेशन की कमियों को दूर करने का प्रयास करने से पहले, आइए समझें कि इस सरल मामले को ठीक से कैसे संभालें, क्योंकि यह समाधान वास्तव में उन अनुप्रयोगों में मान्य है जहां दौड़ की स्थिति समय-समय पर स्वीकार्य होती है, और इसलिए भी कि एकल उदाहरण उस आधार के रूप में कार्य करता है जिसका उपयोग यहां वर्णित वितरित एल्गोरिदम में किया जाता है।

ताला प्राप्त करने के लिए, यह करें:

SET resource_name my_random_value NX PX 30000

यह कमांड केवल एक कुंजी स्थापित करता है यदि यह पहले से मौजूद नहीं है (एनएक्स विकल्प), 30000 मिलीसेकंड (पीएक्स विकल्प) की वैधता अवधि के साथ। कुंजी को "पर सेट किया गया हैmyrandomvalue" यह मान सभी क्लाइंट और सभी लॉक अनुरोधों के लिए अद्वितीय होना चाहिए।
मूल रूप से, लॉक को सुरक्षित रूप से रिलीज़ करने के लिए एक यादृच्छिक मान का उपयोग किया जाता है, जिसमें एक स्क्रिप्ट रेडिस को बताती है: केवल कुंजी को हटाएं यदि यह मौजूद है और इसमें संग्रहीत मान बिल्कुल वैसा ही है जैसा अपेक्षित था। यह निम्नलिखित लुआ स्क्रिप्ट का उपयोग करके हासिल किया गया है:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

किसी अन्य ग्राहक द्वारा रखे गए लॉक को हटाए जाने से रोकने के लिए यह महत्वपूर्ण है। उदाहरण के लिए, एक ग्राहक एक लॉक प्राप्त कर सकता है, फिर कुछ ऑपरेशन में लॉक हो सकता है जो पहले लॉक से अधिक समय तक चलता है (ताकि कुंजी को समाप्त होने का समय हो), और बाद में किसी अन्य क्लाइंट द्वारा लगाए गए लॉक को हटा दें।
साधारण DEL का उपयोग करना असुरक्षित है क्योंकि एक क्लाइंट दूसरे क्लाइंट द्वारा रखे गए लॉक को हटा सकता है। इसके विपरीत, उपरोक्त स्क्रिप्ट का उपयोग करते समय, प्रत्येक लॉक को एक यादृच्छिक स्ट्रिंग के साथ "हस्ताक्षरित" किया जाता है, इसलिए केवल वही क्लाइंट इसे हटा सकता है जिसने इसे पहले रखा था।

यह यादृच्छिक स्ट्रिंग क्या होनी चाहिए? मैं अनुमान लगा रहा हूं कि यह /dev/urandom से 20 बाइट्स होना चाहिए, लेकिन आप अपने उद्देश्यों के लिए स्ट्रिंग को अद्वितीय बनाने के लिए कम महंगे तरीके पा सकते हैं। उदाहरण के लिए, RC4 को /dev/urandom के साथ सीड करना और फिर उससे एक छद्म-यादृच्छिक स्ट्रीम उत्पन्न करना ठीक रहेगा। एक सरल समाधान में माइक्रोसेकंड रिज़ॉल्यूशन और क्लाइंट आईडी में यूनिक्स समय का संयोजन शामिल है; यह उतना सुरक्षित नहीं है, लेकिन संभवतः अधिकांश संदर्भों में यह कार्य के अनुरूप है।

कुंजी के जीवनकाल के माप के रूप में हम जिस समय का उपयोग करते हैं उसे "लॉक जीवनकाल" कहा जाता है। यह मान लॉक स्वचालित रूप से जारी होने से पहले की समयावधि और एक ग्राहक को किसी अन्य ग्राहक द्वारा उस संसाधन को लॉक करने से पहले एक ऑपरेशन पूरा करने की मात्रा, वास्तव में पारस्परिक बहिष्करण गारंटी का उल्लंघन किए बिना, दोनों है। यह गारंटी केवल समय की एक निश्चित अवधि तक ही सीमित है, जो ताला खरीदने के क्षण से शुरू होती है।

इसलिए हमने लॉक प्राप्त करने और जारी करने के एक अच्छे तरीके पर चर्चा की है। सिस्टम (यदि हम एक गैर-वितरित सिस्टम के बारे में बात कर रहे हैं जिसमें एकल और हमेशा उपलब्ध उदाहरण शामिल है) सुरक्षित है। आइए इस अवधारणा को एक वितरित प्रणाली तक विस्तारित करें, जहां हमारे पास ऐसी कोई गारंटी नहीं है।

रेडलॉक एल्गोरिदम

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

लॉक प्राप्त करने के लिए, क्लाइंट निम्नलिखित ऑपरेशन करता है:

1. वर्तमान समय मिलीसेकंड में प्राप्त होता है.
2. सभी मामलों में समान कुंजी नाम और यादृच्छिक मानों का उपयोग करके, सभी एन उदाहरणों पर क्रमिक रूप से लॉक प्राप्त करने का प्रयास किया जाता है। स्टेज 2 में, जब क्लाइंट प्रति-इंस्टेंस के आधार पर लॉक सेट करता है, तो क्लाइंट इसे प्राप्त करने के लिए देरी का उपयोग करता है जो उस समय की तुलना में काफी कम है जिसके बाद लॉक स्वचालित रूप से जारी हो जाता है। उदाहरण के लिए, यदि अवरोधन अवधि 10 सेकंड है, तो विलंब ~5-50 मिलीसेकंड की सीमा में हो सकता है। यह उस स्थिति को समाप्त कर देता है जिसमें क्लाइंट विफल रेडिस नोड तक पहुंचने की कोशिश में लंबे समय तक अवरुद्ध रह सकता है: यदि उदाहरण अनुपलब्ध है, तो हम जितनी जल्दी हो सके दूसरे उदाहरण से कनेक्ट करने का प्रयास करते हैं।
3. लॉक लेने के लिए, ग्राहक गणना करता है कि कितना समय बीत चुका है; ऐसा करने के लिए, यह चरण 1 में प्राप्त टाइमस्टैम्प को वास्तविक समय मान से घटा देता है। यदि और केवल तभी जब ग्राहक अधिकांश उदाहरणों (कम से कम 3) पर लॉक प्राप्त करने में सक्षम था, और इसमें लगने वाला कुल समय लॉक प्राप्त करने की अवधि से कम अवधि पर लॉक प्राप्त हुआ माना जाता है।
4. यदि कोई लॉक प्राप्त कर लिया गया है, तो लॉक अवधि को चरण 3 में गणना की गई बीता हुआ समय घटाकर मूल लॉक अवधि माना जाता है।
5. यदि क्लाइंट किसी कारण से लॉक प्राप्त करने में विफल रहता है (या तो यह एन/2+1 इंस्टेंसेस को लॉक करने में असमर्थ था, या लॉक अवधि नकारात्मक थी), तो यह सभी इंस्टेंसेस को अनलॉक करने का प्रयास करेगा (यहां तक ​​​​कि जिन्हें उसने सोचा था कि वह ब्लॉक नहीं कर सकता है) ).

क्या एल्गोरिदम अतुल्यकालिक है?

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

इस बिंदु पर, हमें अपने पारस्परिक बहिष्करण नियम को अधिक सावधानी से तैयार करना चाहिए: पारस्परिक बहिष्करण की गारंटी केवल तभी होती है जब ताला रखने वाला ग्राहक उस समय के दौरान बाहर निकलता है जब ताला वैध होता है (यह मान चरण 3 में प्राप्त होता है), कुछ और समय घटाकर (कुल कुछ) प्रक्रियाओं के बीच समय के अंतर की भरपाई के लिए मिलीसेकंड)।

निम्नलिखित दिलचस्प लेख ऐसी प्रणालियों के बारे में अधिक बताता है जिन्हें समय अंतराल के समन्वय की आवश्यकता होती है: पट्टे: वितरित फ़ाइल कैश स्थिरता के लिए एक कुशल दोष-सहिष्णु तंत्र.

असफलता पर पुनः प्रयास करें

जब कोई ग्राहक लॉक प्राप्त करने में विफल रहता है, तो उसे यादृच्छिक विलंब के बाद पुनः प्रयास करना होगा; यह एक ही समय में एक ही संसाधन पर लॉक प्राप्त करने का प्रयास करने वाले कई क्लाइंट को डी-सिंक्रनाइज़ करने के लिए किया जाता है (जिससे "स्प्लिट-ब्रेन" स्थिति हो सकती है जिसमें कोई विजेता नहीं होता है)। इसके अतिरिक्त, जितनी तेज़ी से ग्राहक रेडिस के अधिकांश उदाहरणों पर लॉक प्राप्त करने का प्रयास करता है, विंडो उतनी ही संकीर्ण होती है जिसमें विभाजन-मस्तिष्क की स्थिति उत्पन्न हो सकती है (और पुनः प्रयास की आवश्यकता कम होती है)। इसलिए, आदर्श रूप से, क्लाइंट को मल्टीप्लेक्सिंग का उपयोग करके एक साथ SET कमांड को N इंस्टेंस पर भेजने का प्रयास करना चाहिए।

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

ताला खोलो

लॉक जारी करना एक सरल ऑपरेशन है जिसके लिए बस सभी इंस्टेंस को अनलॉक करने की आवश्यकता होती है, भले ही क्लाइंट ने किसी विशेष इंस्टेंस को सफलतापूर्वक लॉक कर दिया हो।

सुरक्षा संबंधी विचार

क्या एल्गोरिदम सुरक्षित है? आइए कल्पना करने का प्रयास करें कि विभिन्न परिदृश्यों में क्या होता है।

आरंभ करने के लिए, मान लें कि ग्राहक अधिकांश उदाहरणों पर लॉक प्राप्त करने में सक्षम था। प्रत्येक उदाहरण में सभी के लिए समान जीवनकाल वाली एक कुंजी होगी। हालाँकि, इनमें से प्रत्येक कुंजी अलग-अलग समय पर स्थापित की गई थी, इसलिए वे अलग-अलग समय पर समाप्त हो जाएंगी। लेकिन, यदि पहली कुंजी ऐसे समय में स्थापित की गई थी जो T1 से अधिक खराब नहीं थी (वह समय जो हम पहले सर्वर से संपर्क करने से पहले चुनते हैं), और अंतिम कुंजी ऐसे समय में स्थापित की गई थी जो T2 से अधिक खराब नहीं थी (वह समय जिस पर प्रतिक्रिया प्राप्त हुई थी) अंतिम सर्वर से), तो हमें विश्वास है कि सेट में समाप्त होने वाली पहली कुंजी कम से कम जीवित रहेगी MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. अन्य सभी कुंजियाँ बाद में समाप्त हो जाएंगी, इसलिए हम निश्चिंत हो सकते हैं कि सभी कुंजियाँ कम से कम इस समय के लिए एक साथ वैध रहेंगी।

उस समय के दौरान जब अधिकांश कुंजियाँ वैध रहती हैं, कोई अन्य क्लाइंट लॉक प्राप्त नहीं कर पाएगा, क्योंकि यदि N/2+1 कुंजियाँ पहले से मौजूद हैं तो N/2+1 SET NX ऑपरेशन सफल नहीं हो सकते हैं। इसलिए, एक बार एक ताला हासिल कर लेने के बाद, उसी क्षण इसे दोबारा हासिल करना असंभव है (यह पारस्परिक बहिष्करण संपत्ति का उल्लंघन होगा)।
हालाँकि, हम यह सुनिश्चित करना चाहते हैं कि एक ही समय में लॉक प्राप्त करने का प्रयास करने वाले कई ग्राहक एक ही समय में सफल न हो सकें।

यदि क्लाइंट ने अधिकांश इंस्टेंसेस को अधिकतम लॉक अवधि के बारे में या उससे अधिक समय के लिए लॉक कर दिया है, तो वह लॉक को अमान्य मान लेगा और इंस्टेंसेस को अनलॉक कर देगा। इसलिए, हमें केवल उस मामले को ध्यान में रखना होगा जिसमें ग्राहक समाप्ति तिथि से कम समय में अधिकांश उदाहरणों को ब्लॉक करने में कामयाब रहा। ऐसे में उक्त तर्क के संबंध में इस दौरान मो MIN_VALIDITY कोई भी ग्राहक लॉक पुनः प्राप्त करने में सक्षम नहीं होना चाहिए। इसलिए, कई ग्राहक एक ही समय में एन/2+1 इंस्टेंस को लॉक करने में सक्षम होंगे (जो चरण 2 के अंत में समाप्त होता है) केवल तभी जब बहुमत को लॉक करने का समय टीटीएल समय से अधिक था, जो लॉक को अमान्य बना देता है।

क्या आप सुरक्षा का औपचारिक प्रमाण प्रदान कर सकते हैं, मौजूदा समान एल्गोरिदम का संकेत दे सकते हैं, या उपरोक्त में कोई बग ढूंढ सकते हैं?

अभिगम्यता संबंधी विचार

सिस्टम की उपलब्धता तीन मुख्य विशेषताओं पर निर्भर करती है:

1. स्वचालित रूप से ताले जारी करें (चाबियाँ समाप्त होने पर): चाबियाँ अंततः ताले के लिए उपयोग करने के लिए फिर से उपलब्ध होंगी।
2. तथ्य यह है कि ग्राहक आमतौर पर तब ताले हटाकर एक-दूसरे की मदद करते हैं जब वांछित ताला हासिल नहीं किया गया हो, या हासिल कर लिया गया हो और काम पूरा हो गया हो; इसलिए यह संभव है कि हमें ताले को पुनः प्राप्त करने के लिए चाबियों के समाप्त होने की प्रतीक्षा नहीं करनी पड़ेगी।
3. तथ्य यह है कि जब किसी ग्राहक को ताला प्राप्त करने के लिए पुनः प्रयास करने की आवश्यकता होती है, तो उसे अधिकांश ताले प्राप्त करने के लिए आवश्यक अवधि की तुलना में अपेक्षाकृत अधिक समय तक इंतजार करना पड़ता है। इससे संसाधनों के लिए प्रतिस्पर्धा करते समय विभाजन-दिमाग की स्थिति उत्पन्न होने की संभावना कम हो जाती है।

हालाँकि, नेटवर्क खंडों के टीटीएल के बराबर उपलब्धता जुर्माना है, इसलिए यदि सन्निहित खंड हैं, तो जुर्माना अनिश्चितकालीन हो सकता है। ऐसा तब होता है जब कोई ग्राहक एक लॉक प्राप्त करता है और फिर उसे जारी करने से पहले दूसरे सेगमेंट में तोड़ देता है।

सिद्धांत रूप में, अनंत सन्निहित नेटवर्क खंडों को देखते हुए, एक सिस्टम अनंत समय तक अनुपलब्ध रह सकता है।

प्रदर्शन, विफलता और fsync

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

हालाँकि, यदि हम विफलताओं से विश्वसनीय पुनर्प्राप्ति के साथ एक मॉडल बनाने का प्रयास करते हैं तो हमें दीर्घकालिक डेटा भंडारण से जुड़े विचार को भी ध्यान में रखना होगा।

मूल रूप से, समस्या को स्पष्ट करने के लिए, मान लें कि हम रेडिस को बिना किसी दीर्घकालिक डेटा भंडारण के कॉन्फ़िगर करते हैं। क्लाइंट 3 में से 5 उदाहरणों को ब्लॉक करने का प्रबंधन करता है। जिन उदाहरणों को क्लाइंट ब्लॉक करने में कामयाब रहा, उनमें से एक को फिर से शुरू किया गया है, और इस समय उसी संसाधन के लिए फिर से 3 उदाहरण हैं, जिन्हें हम ब्लॉक कर सकते हैं, और दूसरा क्लाइंट, बदले में, सुरक्षा संपत्ति का उल्लंघन करते हुए, पुनरारंभ किए गए उदाहरण को ब्लॉक कर सकता है। तालों की विशिष्टता मानता है।

यदि आप डेटा अहेड (एओएफ) सक्षम करते हैं, तो स्थिति में थोड़ा सुधार होगा। उदाहरण के लिए, आप SHUTDOWN कमांड भेजकर और इसे पुनरारंभ करके किसी सर्वर को बढ़ावा दे सकते हैं। चूंकि रेडिस में समाप्ति संचालन को शब्दार्थ रूप से इस तरह से कार्यान्वित किया जाता है कि सर्वर बंद होने पर भी समय प्रवाहित होता रहता है, हमारी सभी आवश्यकताएं ठीक हैं। यह तब तक सामान्य है जब तक सामान्य शटडाउन सुनिश्चित किया जाता है। बिजली कटौती की स्थिति में क्या करें? यदि रेडिस को डिफ़ॉल्ट रूप से कॉन्फ़िगर किया गया है, जिसमें हर सेकंड डिस्क पर fsync सिंक्रनाइज़ होता है, तो यह संभव है कि पुनः आरंभ करने के बाद हमारे पास हमारी कुंजी नहीं होगी। सैद्धांतिक रूप से, यदि हम किसी भी इंस्टेंस पुनरारंभ के दौरान लॉक सुरक्षा की गारंटी देना चाहते हैं, तो हमें सक्षम करना चाहिए fsync=always दीर्घकालिक डेटा भंडारण के लिए सेटिंग्स में। यह प्रदर्शन को पूरी तरह से खत्म कर देगा, सीपी सिस्टम के स्तर तक जो परंपरागत रूप से वितरित ताले को सुरक्षित रूप से लागू करने के लिए उपयोग किया जाता है।

लेकिन स्थिति पहली नज़र में लगने से बेहतर है। सिद्धांत रूप में, एल्गोरिदम की सुरक्षा संरक्षित है क्योंकि जब विफलता के बाद इंस्टेंस को पुनरारंभ किया जाता है, तो यह वर्तमान में सक्रिय किसी भी लॉक में भाग नहीं लेता है।

इसे सुनिश्चित करने के लिए, हमें बस यह सुनिश्चित करना होगा कि विफलता के बाद उदाहरण हमारे द्वारा उपयोग की जाने वाली अधिकतम टीटीएल से थोड़ी अधिक अवधि के लिए अनुपलब्ध रहे। इस तरह हम समाप्ति तिथि और विफलता के समय सक्रिय सभी कुंजियों के स्वचालित रिलीज़ होने तक प्रतीक्षा करेंगे।

विलंबित पुनरारंभ का उपयोग करके, रेडिस में किसी दीर्घकालिक दृढ़ता के अभाव में भी सुरक्षा प्राप्त करना सैद्धांतिक रूप से संभव है। हालाँकि, ध्यान दें कि इसके परिणामस्वरूप पहुंच का उल्लंघन करने पर जुर्माना लगाया जा सकता है। उदाहरण के लिए, यदि अधिकांश उदाहरण विफल हो जाते हैं, तो सिस्टम टीटीएल के लिए विश्व स्तर पर अनुपलब्ध हो जाएगा (और इस दौरान किसी भी संसाधन को अवरुद्ध नहीं किया जा सकता है)।

हम एल्गोरिदम की उपलब्धता बढ़ाते हैं: हम अवरोधन का विस्तार करते हैं

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

किसी ग्राहक को किसी लॉक को पुनः प्राप्त करने पर केवल तभी विचार करना चाहिए जब वह वैधता अवधि के भीतर अधिकांश उदाहरणों को लॉक करने में कामयाब रहा हो।

सच है, तकनीकी रूप से एल्गोरिथ्म नहीं बदलता है, इसलिए ताले हासिल करने के बार-बार किए गए प्रयासों की अधिकतम संख्या सीमित होनी चाहिए, अन्यथा पहुंच गुणों का उल्लंघन होगा।

स्रोत: www.habr.com