रेडिस वापरून वितरित लॉकिंग

अहो हाब्र!

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

वितरित लॉकिंग हे अनेक वातावरणात वापरले जाणारे एक अतिशय उपयुक्त आदिम आहे जेथे विविध प्रक्रियांनी परस्पर अनन्य पद्धतीने सामायिक संसाधनांवर कार्य केले पाहिजे.

रेडिसचा वापर करून DLM (डिस्ट्रिब्युटेड लॉक मॅनेजर) कसे कार्यान्वित करायचे याचे वर्णन करणाऱ्या अनेक लायब्ररी आणि पोस्ट्स आहेत, परंतु प्रत्येक लायब्ररी भिन्न दृष्टीकोन घेते आणि त्यांनी दिलेली हमी थोडी अधिक अत्याधुनिक डिझाइनसह साध्य करण्यायोग्य आहे त्या तुलनेत खूपच कमकुवत आहे.

या लेखात, आम्ही रेडिस वापरून वितरित लॉकिंग कसे अंमलात आणायचे हे प्रदर्शित करणार्‍या सशर्त कॅनोनिकल अल्गोरिदमचे वर्णन करण्याचा प्रयत्न करू. आम्ही नावाच्या अल्गोरिदमबद्दल बोलू रेडलॉक, तो वितरित लॉक व्यवस्थापक लागू करतो आणि आमच्या मते, हा अल्गोरिदम नेहमीच्या सिंगल-इन्स्टन्स पद्धतीपेक्षा सुरक्षित आहे. आम्हाला आशा आहे की समुदाय त्याचे विश्लेषण करेल, अभिप्राय देईल आणि अधिक जटिल किंवा पर्यायी प्रकल्पांसाठी प्रारंभ बिंदू म्हणून वापरेल.

अंमलबजावणी

अल्गोरिदमच्या वर्णनाकडे जाण्यापूर्वी, आम्ही तयार केलेल्या अंमलबजावणीसाठी अनेक दुवे प्रदान करतो. ते संदर्भासाठी वापरले जाऊ शकतात.

• रेडलॉक-आरबी (रुबी साठी अंमलबजावणी). तसेच आहे काटा रेडलॉक-आरबी, जे वितरण सुलभतेसाठी पॅकेज (रत्न) जोडते आणि केवळ त्यासाठीच नाही.
• रेडलॉक-पी (पायथन अंमलबजावणी).
• Aioredlock (Asyncio Python साठी अंमलबजावणी).
• रेडलॉक-पीएचपी (PHP साठी अंमलबजावणी).
• PHPRedisMutex (PHP साठी दुसरी अंमलबजावणी)
• cheprasov/php-redis-lock (लॉकसाठी PHP लायब्ररी)
• रेडसिंक (Go साठी अंमलबजावणी).
• रेडिसन (जावा साठी अंमलबजावणी).
• रेडिस::डिस्टलॉक (Perl साठी अंमलबजावणी).
• रेडलॉक-सीपीपी (C++ साठी अंमलबजावणी).
• रेडलॉक-सीएस (C#/.NET साठी अंमलबजावणी).
• RedLock.net (C#/.NET साठी अंमलबजावणी). async आणि लॉक विस्तारासाठी समर्थनासह.
• स्कार्लेट लॉक (कॉन्फिगर करण्यायोग्य डेटा स्टोअरसह C# .NET साठी अंमलबजावणी)
• Redlock4Net (C# .NET साठी अंमलबजावणी)
• नोड-रेडलॉक (NodeJS साठी अंमलबजावणी). विस्तारित लॉकसाठी समर्थन समाविष्ट आहे.

सुरक्षा आणि उपलब्धता हमी

आम्ही आमच्या डिझाइनला फक्त तीन गुणधर्मांसह मॉडेल करणार आहोत जे आम्हाला वाटते की वितरित लॉकिंग प्रभावीपणे वापरण्यासाठी आवश्यक किमान हमी प्रदान करतात.

1. सुरक्षा मालमत्ता: परस्पर बहिष्कार. कोणत्याही वेळी, फक्त एक क्लायंट लॉक धारण करू शकतो.
2. उपलब्धता मालमत्ता A: कोणतेही डेडलॉक नाहीत. संसाधन लॉक केलेला क्लायंट अयशस्वी झाला किंवा वेगळ्या डिस्क सेगमेंटवर उतरला तरीही शेवटी लॉक मिळवणे नेहमीच शक्य असते.
3. उपलब्धता मालमत्ता ब: दोष सहिष्णुता. जोपर्यंत बहुतेक रेडिस नोड्स चालू आहेत, क्लायंट लॉक मिळवण्यास आणि सोडण्यास सक्षम आहेत.

अयशस्वी पुनर्प्राप्तीवर आधारित अंमलबजावणी या प्रकरणात पुरेसे का नाही
आपण काय सुधारणा करणार आहोत हे समजून घेण्यासाठी, Redis वर आधारित सर्वाधिक वितरित लॉकिंग लायब्ररींच्या सद्यस्थितीचे विश्लेषण करूया.

Redis वापरून संसाधन लॉक करण्याचा सर्वात सोपा मार्ग म्हणजे उदाहरणामध्ये की तयार करणे. सामान्यतः, मर्यादित जीवनकाळासह की तयार केली जाते, हे Redis मध्ये प्रदान केलेल्या कालबाह्य वैशिष्ट्याचा वापर करून साध्य केले जाते, त्यामुळे लवकर किंवा नंतर ही की जारी केली जाते (आमच्या सूचीमधील मालमत्ता 2). जेव्हा क्लायंटला संसाधन सोडण्याची आवश्यकता असते, तेव्हा ते की हटवते.

पहिल्या दृष्टीक्षेपात, हे समाधान चांगले कार्य करते, परंतु एक समस्या आहे: आमचे आर्किटेक्चर अपयशाचा एकच बिंदू तयार करते. होस्ट Redis उदाहरण अयशस्वी झाल्यास काय होईल? चला मग गुलाम जोडूया! आणि प्रस्तुतकर्ता अनुपलब्ध असल्यास आम्ही ते वापरू. दुर्दैवाने, हा पर्याय व्यवहार्य नाही. असे केल्याने, आम्ही सुरक्षितता सुनिश्चित करण्यासाठी आवश्यक असलेल्या परस्पर बहिष्कार गुणधर्माची योग्यरित्या अंमलबजावणी करू शकणार नाही, कारण Redis मधील प्रतिकृती असिंक्रोनस आहे.

अर्थात, अशा मॉडेलमध्ये शर्यतीची स्थिती उद्भवते:

1. क्लायंट A मास्टरवर लॉक मिळवतो.
2. की एंट्री स्लेव्हकडे हस्तांतरित करण्यापूर्वी मास्टर अयशस्वी होतो.
3. अनुयायाला नेता म्हणून बढती दिली जाते.
4. क्लायंट B त्याच संसाधनावर लॉक मिळवतो जो A ने आधीच लॉक केलेला आहे. सुरक्षेचे उल्लंघन!

काहीवेळा हे पूर्णपणे सामान्य आहे की विशेष परिस्थितीत, जसे की अपयश, अनेक क्लायंट एकाच वेळी लॉक धारण करू शकतात. अशा परिस्थितीत, प्रतिकृती-आधारित उपाय लागू केला जाऊ शकतो. अन्यथा, आम्ही या लेखात वर्णन केलेल्या उपायाची शिफारस करतो.

एकाच उदाहरणासह योग्य अंमलबजावणी

वर वर्णन केलेल्या सिंगल-इन्स्टन्स कॉन्फिगरेशनच्या उणीवांवर मात करण्याचा प्रयत्न करण्यापूर्वी, ही साधी केस योग्यरित्या कशी हाताळायची हे समजून घेऊया, कारण हे उपाय वास्तविक अनुप्रयोगांमध्ये वैध आहे जेथे वेळोवेळी शर्यतीची स्थिती स्वीकार्य आहे आणि शिवाय ब्लॉकिंगमुळे एकल उदाहरण येथे वर्णन केलेल्या वितरित अल्गोरिदममध्ये वापरला जाणारा आधार म्हणून काम करतो.

लॉक मिळविण्यासाठी, हे करा:

SET resource_name my_random_value NX PX 30000

ही कमांड 30000 मिलीसेकंद (PX पर्याय) च्या वैधतेच्या कालावधीसह (NX पर्याय) आधीपासून अस्तित्वात नसल्यासच की स्थापित करते. की "" वर सेट केली आहे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. सर्व प्रकरणांमध्ये समान की नाव आणि यादृच्छिक मूल्ये वापरून, सर्व N उदाहरणांवर लॉक मिळविण्याचा क्रमाने प्रयत्न करतो. स्टेज 2 मध्ये, जेव्हा क्लायंट प्रति-इंस्टन्स आधारावर लॉक सेट करतो, तेव्हा क्लायंट ते मिळवण्यासाठी विलंब वापरतो जे लॉक आपोआप रिलीझ होण्याच्या वेळेच्या तुलनेत पुरेसे कमी असते. उदाहरणार्थ, जर ब्लॉकिंग कालावधी 10 सेकंद असेल, तर विलंब ~5-50 मिलीसेकंदांच्या श्रेणीमध्ये असू शकतो. अयशस्वी रेडिस नोडपर्यंत पोहोचण्याचा प्रयत्न करत असताना क्लायंट दीर्घकाळ अवरोधित राहू शकेल अशी परिस्थिती हे काढून टाकते: उदाहरण अनुपलब्ध असल्यास, आम्ही शक्य तितक्या लवकर दुसर्‍या प्रसंगाशी कनेक्ट करण्याचा प्रयत्न करतो.
3. लॉक घेण्यासाठी, क्लायंट किती वेळ निघून गेला याची गणना करतो; हे करण्यासाठी, ते स्टेप 1 मध्ये मिळालेल्या टाइमस्टॅम्पच्या वास्तविक टाइम व्हॅल्यूमधून वजा करते. जर आणि फक्त जर क्लायंट बहुसंख्य उदाहरणांवर लॉक मिळवू शकला असेल (किमान 3), आणि त्याला लागणारा एकूण वेळ लॉक मिळवा, लॉक कालावधीपेक्षा कमी, लॉक प्राप्त झाले असे मानले जाते.
4. जर लॉक अधिग्रहित केले गेले असेल, तर लॉकचा कालावधी हा मूळ लॉक कालावधी वजा स्टेप 3 मध्‍ये काढलेला वेळ मानला जातो.
5. जर क्लायंट काही कारणास्तव लॉक मिळवण्यात अयशस्वी झाला (एकतर तो N/2+1 उदाहरणे लॉक करू शकला नाही, किंवा लॉक कालावधी नकारात्मक होता), तर तो सर्व उदाहरणे अनलॉक करण्याचा प्रयत्न करेल (जरी त्याला अवरोधित करू शकत नाही असे वाटले होते. ).

अल्गोरिदम असिंक्रोनस आहे का?

हे अल्गोरिदम या गृहितकावर आधारित आहे की, सर्व प्रक्रिया कार्य करतील असे कोणतेही सिंक्रोनाइझ केलेले घड्याळ नसले तरी, प्रत्येक प्रक्रियेतील स्थानिक वेळ अजूनही अंदाजे त्याच वेगाने वाहते आणि लॉकच्या एकूण वेळेच्या तुलनेत त्रुटी कमी आहे. आपोआप रिलीझ. हे गृहितक सामान्य संगणकांच्या वैशिष्ट्याप्रमाणेच आहे: प्रत्येक संगणकावर एक स्थानिक घड्याळ असते आणि आम्ही सहसा या वस्तुस्थितीवर विश्वास ठेवू शकतो की वेगवेगळ्या संगणकांमधील वेळेचा फरक कमी आहे.

या टप्प्यावर, आम्ही आमचा परस्पर बहिष्कार नियम अधिक काळजीपूर्वक तयार केला पाहिजे: परस्पर बहिष्काराची हमी केवळ तेव्हाच दिली जाते जेव्हा लॉक धारण करणारा क्लायंट लॉक वैध असताना बाहेर पडतो (हे मूल्य चरण 3 मध्ये प्राप्त होते), वजा आणखी काही वेळ (एकूण काही प्रक्रियांमधील वेळेतील फरकाची भरपाई करण्यासाठी मिलीसेकंद).

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

अपयशावर पुन्हा प्रयत्न करा

जेव्हा क्लायंट लॉक मिळवण्यात अयशस्वी होतो, तेव्हा यादृच्छिक विलंबानंतर पुन्हा प्रयत्न करणे आवश्यक आहे; एकाच वेळी एकाच रिसोर्सवर लॉक मिळवण्याचा प्रयत्न करणार्‍या अनेक क्लायंटना डी-सिंक्रोनाइझ करण्यासाठी हे केले जाते (ज्यामुळे "स्प्लिट-ब्रेन" परिस्थिती उद्भवू शकते ज्यामध्ये कोणतेही विजेते नाहीत). याव्यतिरिक्त, बहुतेक रेडिस उदाहरणांवर क्लायंट जितक्या वेगाने लॉक मिळवण्याचा प्रयत्न करेल, तितकी खिडकी अरुंद होईल ज्यामध्ये स्प्लिट-ब्रेन परिस्थिती उद्भवू शकते (आणि पुन्हा प्रयत्न करण्याची आवश्यकता कमी). म्हणून, आदर्शपणे, क्लायंटने मल्टीप्लेक्सिंग वापरून एकाच वेळी N घटनांमध्ये SET कमांड पाठवण्याचा प्रयत्न केला पाहिजे.

बहुसंख्य कुलूप मिळवण्यात अयशस्वी झालेल्या क्लायंटसाठी (अंशत:) अधिग्रहित कुलूप सोडणे किती महत्त्वाचे आहे, जेणेकरुन त्यांना संसाधनावरील लॉक पुन्हा मिळवण्याआधी की कालबाह्य होण्याची प्रतीक्षा करावी लागणार नाही, हे येथे आवर्जून सांगण्यासारखे आहे. (जरी नेटवर्क विखंडन झाल्यास, आणि क्लायंटने Redis उदाहरणांशी संपर्क गमावला, तर की कालबाह्य होण्याची वाट पाहत असताना तुम्हाला उपलब्धता दंड भरावा लागेल).

लॉक सोडा

लॉक रिलीझ करणे हे एक साधे ऑपरेशन आहे ज्यासाठी क्लायंटने विशिष्ट उदाहरण यशस्वीरित्या लॉक केले आहे की नाही याची पर्वा न करता सर्व उदाहरणे अनलॉक करणे आवश्यक आहे.

सुरक्षा विचार

अल्गोरिदम सुरक्षित आहे का? वेगवेगळ्या परिस्थितीत काय घडते याची कल्पना करण्याचा प्रयत्न करूया.

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

बहुतेक कळा वैध राहिल्याच्या काळात, दुसरा क्लायंट लॉक मिळवू शकणार नाही, कारण N/2+1 की आधीच अस्तित्वात असल्यास N/2+1 SET NX ऑपरेशन्स यशस्वी होऊ शकत नाहीत. म्हणून, एकदा लॉक अधिग्रहित केल्यावर, त्याच क्षणी ते पुन्हा मिळवणे अशक्य आहे (हे परस्पर बहिष्कार मालमत्तेचे उल्लंघन करेल).
तथापि, आम्ही हे सुनिश्चित करू इच्छितो की एकाच वेळी लॉक मिळवण्याचा प्रयत्न करणारे अनेक क्लायंट एकाच वेळी यशस्वी होऊ शकत नाहीत.

जर क्लायंटने जास्तीत जास्त लॉक कालावधीसाठी किंवा त्याहून अधिक उदाहरणे लॉक केली असतील, तर तो लॉक अवैध मानेल आणि उदाहरणे अनलॉक करेल. म्हणून, आम्हाला फक्त त्या प्रकरणाचा विचार करावा लागेल ज्यामध्ये क्लायंटने कालबाह्यता तारखेपेक्षा कमी वेळेत बहुतांश घटना अवरोधित केल्या आहेत. या प्रकरणी वरील युक्तिवाद संदर्भात, दरम्यान MIN_VALIDITY कोणताही क्लायंट लॉक पुन्हा मिळविण्यास सक्षम नसावा. त्यामुळे, अनेक क्लायंट एकाच वेळी N/2+1 घटना लॉक करू शकतील (जे स्टेज 2 च्या शेवटी संपेल) फक्त जेव्हा मेजॉरिटी लॉक करण्याची वेळ TTL वेळेपेक्षा जास्त असेल, जे लॉक अवैध ठरवते.

तुम्ही सुरक्षिततेचा औपचारिक पुरावा देऊ शकता, विद्यमान समान अल्गोरिदम दर्शवू शकता किंवा वरीलमध्ये बग शोधू शकता?

प्रवेशयोग्यता विचार

सिस्टमची उपलब्धता तीन मुख्य वैशिष्ट्यांवर अवलंबून असते:

1. लॉक आपोआप रिलीझ करा (की कालबाह्य झाल्यामुळे): लॉकसाठी वापरण्यासाठी की अखेरीस पुन्हा उपलब्ध होतील.
2. क्लायंट सामान्यत: जेव्हा इच्छित लॉक मिळवले गेले नाहीत किंवा मिळवले गेले आणि काम पूर्ण झाले तेव्हा लॉक काढून एकमेकांना मदत करतात ही वस्तुस्थिती; त्यामुळे लॉक पुन्हा मिळवण्यासाठी आम्हाला चाव्या कालबाह्य होण्याची वाट पाहावी लागणार नाही.
3. जेव्हा क्लायंटला लॉक मिळवण्यासाठी पुन्हा प्रयत्न करण्याची आवश्यकता असते, तेव्हा ते बहुतेक लॉक मिळविण्यासाठी आवश्यक असलेल्या कालावधीपेक्षा तुलनेने जास्त काळ प्रतीक्षा करते. यामुळे संसाधनांसाठी स्पर्धा करताना स्प्लिट-ब्रेन परिस्थिती उद्भवण्याची शक्यता कमी होते.

तथापि, नेटवर्क विभागांच्या TTL प्रमाणेच उपलब्धता दंड आहे, त्यामुळे तेथे संलग्न विभाग असल्यास, दंड अनिश्चित असू शकतो. जेव्हा जेव्हा क्लायंट लॉक घेतो आणि नंतर तो रिलीझ होण्याआधी दुसर्‍या सेगमेंटला फाडतो तेव्हा हे घडते.

तत्वतः, अनंत संलग्न नेटवर्क विभाग दिलेले, प्रणाली अनंत कालावधीसाठी अनुपलब्ध राहू शकते.

कार्यप्रदर्शन, फेलओव्हर आणि fsync

बरेच लोक रेडिस वापरतात कारण त्यांना लॉक मिळवण्यासाठी आणि रिलीझ करण्यासाठी आवश्यक असलेल्या विलंबतेच्या दृष्टीने उच्च लॉक सर्व्हर कार्यक्षमतेची आवश्यकता असते आणि प्रति सेकंद पूर्ण होऊ शकणार्‍या संपादन/रिलीजची संख्या. ही आवश्यकता पूर्ण करण्यासाठी, विलंब कमी करण्यासाठी एन रेडिस सर्व्हरशी संवाद साधण्याची एक रणनीती आहे. ही मल्टिप्लेक्सिंग स्ट्रॅटेजी आहे (किंवा "गरीब माणसाचे मल्टिप्लेक्सिंग", जेथे सॉकेट नॉन-ब्लॉकिंग मोडमध्ये ठेवले जाते, सर्व कमांड पाठवते, आणि क्लायंट आणि प्रत्येक उदाहरणामधील राउंड-ट्रिप वेळ सारखाच आहे असे गृहीत धरून नंतर कमांड वाचते) .

तथापि, आम्ही अपयशातून विश्वसनीय पुनर्प्राप्तीसह मॉडेल तयार करण्याचा प्रयत्न केल्यास दीर्घकालीन डेटा स्टोरेजशी संबंधित विचार देखील विचारात घेणे आवश्यक आहे.

मुळात, समस्येचे स्पष्टीकरण करण्यासाठी, आम्ही असे गृहीत धरू की आम्ही रेडिस ला दीर्घकालीन डेटा स्टोरेजशिवाय कॉन्फिगर करतो. क्लायंट 3 पैकी 5 घटना अवरोधित करण्यास व्यवस्थापित करतो. क्लायंटने अवरोधित करण्यात व्यवस्थापित केलेल्या उदाहरणांपैकी एक रीस्टार्ट झाला आहे, आणि या क्षणी त्याच संसाधनासाठी पुन्हा 3 उदाहरणे आहेत, जी आम्ही अवरोधित करू शकतो, आणि दुसरा क्लायंट, त्या बदल्यात, सुरक्षा मालमत्तेचे उल्लंघन करून, रीस्टार्ट केलेले प्रसंग अवरोधित करू शकतो. लॉकची अनन्यता गृहीत धरते.

तुम्ही डेटा अहेड (AOF) सक्षम केल्यास, परिस्थिती थोडी सुधारेल. उदाहरणार्थ, तुम्ही SHUTDOWN कमांड पाठवून आणि रीस्टार्ट करून सर्व्हरचा प्रचार करू शकता. Redis मधील कालबाह्यता ऑपरेशन्स अशा प्रकारे कार्यान्वित केल्या जातात की सर्व्हर बंद असतानाही वेळ वाहत राहतो, आमच्या सर्व आवश्यकता ठीक आहेत. जोपर्यंत सामान्य शटडाउन सुनिश्चित केले जाते तोपर्यंत हे सामान्य आहे. वीज खंडित झाल्यास काय करावे? जर रेडिस हे डीफॉल्टनुसार कॉन्फिगर केले असेल, प्रत्येक सेकंदाला डिस्कवर fsync सिंक्रोनाइझ करत असेल, तर हे शक्य आहे की रीस्टार्ट केल्यानंतर आमच्याकडे आमची की नसेल. सैद्धांतिकदृष्ट्या, आम्ही कोणत्याही घटना रीस्टार्ट दरम्यान लॉक सुरक्षिततेची हमी देऊ इच्छित असल्यास, आम्ही सक्षम केले पाहिजे fsync=always दीर्घकालीन डेटा स्टोरेजसाठी सेटिंग्जमध्ये. हे पारंपारिकपणे वितरित लॉक्स सुरक्षितपणे अंमलात आणण्यासाठी वापरल्या जाणार्‍या CP सिस्टीमच्या पातळीपर्यंत कार्यक्षमता पूर्णपणे नष्ट करेल.

परंतु परिस्थिती पहिल्या दृष्टीक्षेपात दिसते त्यापेक्षा चांगली आहे. तत्वतः, अल्गोरिदमची सुरक्षितता जतन केली जाते कारण जेव्हा अयशस्वी झाल्यानंतर उदाहरण पुन्हा सुरू केले जाते, तेव्हा ते सध्या सक्रिय असलेल्या कोणत्याही लॉकमध्ये सहभागी होत नाही.

हे सुनिश्चित करण्‍यासाठी, आम्‍हाला हे सुनिश्चित करण्‍याची आवश्‍यकता आहे की अयशस्वी झाल्‍यानंतर आम्‍ही वापरत असलेल्‍या कमाल TTL पेक्षा किंचित कालावधीसाठी उदाहरण अनुपलब्ध राहते. अशा प्रकारे आम्ही कालबाह्यता तारीख आणि अयशस्वी होण्याच्या वेळी सक्रिय असलेल्या सर्व की स्वयंचलितपणे रिलीझ होईपर्यंत प्रतीक्षा करू.

विलंबित रीस्टार्टचा वापर करून, रेडिसमध्ये दीर्घकालीन टिकाव नसतानाही सुरक्षितता प्राप्त करणे तत्त्वतः शक्य आहे. लक्षात ठेवा, तथापि, यामुळे प्रवेशयोग्यतेचे उल्लंघन केल्याबद्दल दंड होऊ शकतो. उदाहरणार्थ, बहुसंख्य उदाहरणे अयशस्वी झाल्यास, सिस्टम TTL साठी जागतिक स्तरावर अनुपलब्ध होईल (आणि या काळात कोणतेही संसाधन अवरोधित केले जाऊ शकत नाही).

आम्ही अल्गोरिदमची उपलब्धता वाढवतो: आम्ही ब्लॉकिंग वाढवतो

क्लायंटद्वारे केलेल्या कामात लहान पायऱ्यांचा समावेश असल्यास, डिफॉल्ट लॉक कालावधी कमी करणे आणि लॉक वाढवण्याची यंत्रणा लागू करणे शक्य आहे. तत्वतः, जर क्लायंट संगणन करण्यात व्यस्त असेल आणि लॉक एक्सपायरी व्हॅल्यू धोकादायकरीत्या कमी असेल, तर तुम्ही सर्व उदाहरणांना लुआ स्क्रिप्ट पाठवू शकता जी की अजूनही अस्तित्वात असल्यास आणि तिचे मूल्य अद्याप एक यादृच्छिक मूल्य असेल तेव्हा प्राप्त होते. लॉक अधिग्रहित केले.

जर क्लायंटने वैधता कालावधीत बहुतांश घटना लॉक करण्यास व्यवस्थापित केले असेल तरच लॉक पुन्हा मिळवण्याचा विचार केला पाहिजे.

खरे आहे, तांत्रिकदृष्ट्या अल्गोरिदम बदलत नाही, म्हणून लॉक मिळविण्यासाठी वारंवार प्रयत्नांची कमाल संख्या मर्यादित असणे आवश्यक आहे, अन्यथा प्रवेशयोग्यता गुणधर्मांचे उल्लंघन केले जाईल.

स्त्रोत: www.habr.com