परिचय
<पी> वितरित ताले तब तक सरल लगते हैं जब तक आप वास्तव में उत्पादन में उन पर निर्भर नहीं होते। <पी> एक प्रक्रिया को किसी संसाधन तक विशेष पहुंच की आवश्यकता होती है। एकाधिक सर्वर चल रहे हैं. रेडिस बीच में बैठता है. विचार सीधा लगता है:रेडिस में ताला लगाएं और आगे बढ़ें। <पी> कुछ समय के लिए, यह दृष्टिकोण काम करता प्रतीत होता है। फिर एक प्रक्रिया क्रैश हो जाती है, नेटवर्क विलंब होता है, या विलंबता स्पाइक्स होती है। अचानक, दो प्रक्रियाएँ एक ही लॉक का दावा करती हैं, कोई प्रक्रिया इसका स्वामी नहीं होती, या लॉक कभी रिलीज़ नहीं होता। <पी> अधिकांश रेडिस लॉकिंग समस्याएँ स्वयं रेडिस के कारण नहीं होती हैं। ऐसा इसलिए होता है क्योंकि वितरित ताले को अक्सर गलत समझा जाता है। रेडिस समन्वय के लिए एक उपकरण प्रदान करता है, न कि पूर्ण विशिष्टता की गारंटी।एक वितरित ताला वास्तव में क्या है
<पी> एक वितरित लॉक इन-मेमोरी म्यूटेक्स के समान नहीं है। यह पूर्ण गारंटी प्रदान नहीं करता है, और यह विफलता को समाप्त नहीं कर सकता है। <पी> वितरित ताले समन्वय तंत्र हैं जो अविश्वसनीय वातावरण में काम करते हैं। नेटवर्क विफल हो जाते हैं, प्रक्रियाएँ क्रैश हो जाती हैं, और घड़ियाँ ख़राब हो जाती हैं। कोई भी लॉकिंग रणनीति जो सही व्यवहार मानती है अंततः टूट जाएगी। <पी> रेडिस ताले सर्वोत्तम प्रयास वाले ताले हैं। जब सही ढंग से डिज़ाइन किया जाता है, तो वे बेहद प्रभावी होते हैं। जब लापरवाही से लागू किया जाता है, तो वे सूक्ष्म नस्ल की स्थिति और डेटा भ्रष्टाचार का परिचय देते हैं। <पी> रेडिस लॉक का सुरक्षित रूप से उपयोग करने में पहला कदम अपेक्षाओं को समायोजित करना है।जब रेडिस लॉक्स समझ में आते हैं
<पी> Redis वितरित ताले तब उपयुक्त होते हैं जब:- <पी> आपको एक महत्वपूर्ण अनुभाग के समवर्ती निष्पादन को रोकने की आवश्यकता है
- <पी> कार्य को अनेक सर्वरों पर समन्वित किया जाना चाहिए
- <पी> ऑपरेशन अल्पकालिक है
- <पी> पुनः प्रयास स्वीकार्य हैं
रेडिस में एकमात्र सुरक्षित लॉकिंग आदिम
<पी> सबसे सुरक्षित रेडिस लॉकिंग प्रिमिटिव एक एकल परमाणु कमांड है: <पी> कुंजी मान NX EX ttl सेट करें <पी> यह कमांड केवल तभी लॉक बनाता है जब यह पहले से मौजूद नहीं है, एक अद्वितीय स्वामी मान निर्दिष्ट करता है, और एक टीटीएल सेट करता है ताकि लॉक स्वचालित रूप से समाप्त हो जाए। <पी> कोई भी वैकल्पिक दृष्टिकोण नस्ल की स्थितियों का परिचय देता है। टीटीएल के बिना SETNX का उपयोग करना या समाप्ति को एक अलग चरण में सेट करना विफलता के तहत टूट जाता है। टीटीएल अनिवार्य है और जब कोई प्रक्रिया अप्रत्याशित रूप से क्रैश हो जाती है तो यह सिस्टम की सुरक्षा करता है।लॉक टीटीएल क्यों अनिवार्य है
<पी> टीटीएल के बिना, रेडिस लॉक हमेशा के लिए जीवित रह सकता है। यदि कोई प्रक्रिया लॉक पकड़ते समय क्रैश हो जाती है, तो सिस्टम चुपचाप रुक जाता है। <पी> टीटीएल ताले को स्व-उपचारित बनाता है। जब कोई विफलता होती है, तो लॉक अंततः समाप्त हो जाता है और प्रगति को फिर से शुरू करने की अनुमति देता है। इसके परिणामस्वरूप संक्षिप्त ओवरलैप हो सकता है, लेकिन यह ट्रेडऑफ़ जानबूझकर किया गया है। <पी> जो ताले कभी ख़त्म नहीं होते, वे ताले न होने से भी ज़्यादा ख़तरनाक होते हैं।स्वामित्व को लॉक करें और सुरक्षित रिलीज
<पी> रेडिस लॉक को केवल उसी प्रक्रिया द्वारा जारी किया जाना चाहिए जिसने इसे हासिल किया है। यही कारण है कि लॉक मान विशिष्ट पहचानकर्ता होने चाहिए, स्थिर स्ट्रिंग नहीं। <पी> लॉक जारी करने के लिए स्वामित्व की पुष्टि की आवश्यकता होती है। सुरक्षित तरीका लुआ स्क्रिप्ट का उपयोग करना है जो संग्रहीत मूल्य की जांच करता है और लॉक को केवल तभी हटाता है जब यह अपेक्षित मालिक से मेल खाता हो। <पी> यह उस दौड़ की स्थिति को रोकता है जहां एक लॉक समाप्त हो जाता है, किसी अन्य प्रक्रिया द्वारा अधिग्रहित किया जाता है, और फिर मूल धारक द्वारा गलती से हटा दिया जाता है।सुरक्षित लॉक अवधि चुनना
<पी> लॉक टीटीएल को संरक्षित ऑपरेशन के अधिकतम अपेक्षित निष्पादन समय से अधिक होना चाहिए। औसत निष्पादन समय का उपयोग करना पर्याप्त नहीं है। <पी> यदि कोई लॉक तब समाप्त हो जाता है जब काम अभी भी चल रहा है, तो कोई अन्य प्रक्रिया उसे प्राप्त कर सकती है और उसी कार्य को समवर्ती रूप से निष्पादित कर सकती है। इससे नकल या भ्रष्टाचार हो सकता है। <पी> साथ ही, कुछ गलत होने पर अत्यधिक लंबे टीटीएल पुनर्प्राप्ति में देरी करते हैं। लॉक अवधि एक संतुलन है जो सिस्टम में बदलाव के साथ विकसित होता है। <पी> बंद किए गए काम को छोटा और सीमित रखना सबसे सुरक्षित तरीका है।लॉक एक्सटेंशन और दिल की धड़कन
<पी> कुछ ऑपरेशनों में अपेक्षा से अधिक समय लगता है। टीटीएल को समय-समय पर ताज़ा करके ताले का विस्तार करना संभव है, लेकिन यह जटिलता और नए विफलता मोड जोड़ता है। <पी> केवल ताला मालिक को टीटीएल का विस्तार करने की अनुमति दी जानी चाहिए, और स्वामित्व खो जाने पर विस्तार तुरंत रुक जाना चाहिए। <पी> कई मामलों में, लॉक एक्सटेंशन लॉजिक को लागू करने की तुलना में काम को छोटे टुकड़ों में फिर से डिज़ाइन करना अधिक सुरक्षित है।रेडलॉक डिबेट
<पी> रेडलॉक एक एल्गोरिदम है जो लॉक सुरक्षा में सुधार के लिए कई रेडिस इंस्टेंस का उपयोग करता है। यह विवादास्पद और परिचालन रूप से जटिल भी है। <पी> अधिकांश प्रणालियों के लिए, रेडलॉक लाभ की तुलना में अधिक जटिलता का परिचय देता है। यह समय संबंधी धारणाओं पर निर्भर करता है जिनकी वास्तविक दुनिया के वातावरण में गारंटी देना मुश्किल है। <पी> यदि रेडलॉक-स्तरीय गारंटी की आवश्यकता है, तो रेडिस उपयुक्त उपकरण नहीं हो सकता है। ट्रांजेक्शनल लॉकिंग या विशेष समन्वय प्रणाली वाले डेटाबेस बेहतर फिट हो सकते हैं। <पी> अधिकांश रेडिस उपयोग मामलों के लिए, उचित टीटीएल-आधारित लॉकिंग वाला एक एकल रेडिस उदाहरण पर्याप्त है।ताले लेनदेन नहीं हैं
<पी> रेडिस लॉक परिचालन को लेन-देन संबंधी नहीं बनाते हैं। जब ऑपरेशन के बीच में विफलता होती है तो वे स्वचालित रोलबैक प्रदान नहीं करते हैं या निरंतरता की गारंटी नहीं देते हैं। <पी> ताले समवर्तीता को कम करते हैं; वे असफलता को ख़त्म नहीं करते. महत्वपूर्ण अनुभागों को निष्क्रिय करने के लिए डिज़ाइन किया जाना चाहिए ताकि बार-बार निष्पादन से नुकसान न हो। <पी> यह डिज़ाइन सिद्धांत लॉकिंग-संबंधित बग के जोखिम को काफी कम कर देता है।क्या होता है जब रेडिस डाउन हो जाता है
<पी> जब रेडिस बंद हो जाता है या पुनः आरंभ होता है, तो सभी लॉक गायब हो जाते हैं। यह अपेक्षित व्यवहार है. <पी> जब रेडिस ऑनलाइन वापस आता है, तो कई प्रक्रियाएं एक साथ ताले प्राप्त कर सकती हैं और काम शुरू कर सकती हैं। सिस्टम को इस संभावना को सहन करना चाहिए। <पी> यदि रेडिस पुनरारंभ के दौरान लॉक खोने से भ्रष्टाचार होता है, तो लॉकिंग डिज़ाइन असुरक्षित है और इस पर पुनर्विचार करने की आवश्यकता है।उत्पादन में ताले की निगरानी
<पी> रेडिस ताले कभी भी अदृश्य नहीं होने चाहिए। टीमों को निगरानी करनी चाहिए कि कितने ताले मौजूद हैं, वे कितने समय तक जीवित रहते हैं, और कितनी बार ताला अधिग्रहण विफल रहता है। <पी> असामान्य रूप से लंबे समय तक चलने वाले ताले रुकी हुई प्रक्रियाओं का संकेत देते हैं। बार-बार अधिग्रहण विफलताएं विवाद या गलत लॉक डिज़ाइन का सुझाव देती हैं। <पी> सुरक्षित संचालन के लिए दृश्यता आवश्यक है।सामान्य रेडिस लॉक एंटी-पैटर्न
<पी> सामान्य गलतियों में टीटीएल के बिना SETNX का उपयोग करना, लॉक स्वामित्व के लिए स्थिर मानों का उपयोग करना, लॉक को आँख बंद करके हटाना, लंबे समय तक चलने वाले कार्यों के लिए लॉक को पकड़ना और यह मान लेना कि लॉक सही होने की गारंटी देता है। <पी> ये विरोधी पैटर्न वास्तविक दुनिया में उत्पादन की रुकावटों में अक्सर दिखाई देते हैं।एक प्रैक्टिकल लॉकिंग चेकलिस्ट
<पी> एक सुरक्षित रेडिस लॉकिंग कार्यान्वयन में शामिल हैं:- <पी> TTLs से चाबियाँ लॉक करें
- <पी> अद्वितीय लॉक स्वामित्व मान
- <पी> रिलीज़ पर स्वामित्व सत्यापन
- <पी> अल्पकालिक महत्वपूर्ण अनुभाग
- <पी> निष्प्रभावी संचालन
- <पी> परीक्षण किए गए विफलता पथ
