Redis प्रयोग गरेर वितरित लक

हे हाबर!

आज, हामी तपाईंलाई रेडिस प्रयोग गरेर वितरित लकहरू लागू गर्ने बारे एउटा जटिल लेखको अनुवाद प्रस्तुत गर्दछौं र रेडिसको सम्भाव्यतालाई विषयको रूपमा छलफल गर्छौं। प्रश्नमा रहेको रेडलक एल्गोरिथ्मको विश्लेषण "" पुस्तकका लेखक मार्टिन क्लेपम्यानद्वारा प्रदान गरिएको छ।अत्यधिक लोड भएका अनुप्रयोगहरू", दिइएको छ यहाँ.

वितरित तालाहरू धेरै वातावरणहरूमा प्रयोग हुने धेरै उपयोगी आदिम हुन् जहाँ विभिन्न प्रक्रियाहरूले पारस्परिक रूपमा विशेष रूपमा साझा स्रोतहरूमा काम गर्नुपर्छ।

रेडिस प्रयोग गरेर DLM (वितरित लक प्रबन्धक) कसरी कार्यान्वयन गर्ने भनेर वर्णन गर्ने धेरै पुस्तकालयहरू र पोस्टहरू छन्, तर प्रत्येक पुस्तकालयले आफ्नै दृष्टिकोण लिन्छ, र तिनीहरूले प्रदान गर्ने ग्यारेन्टीहरू अलि बढी जटिल डिजाइनको साथ प्राप्त गर्न सकिने कुराको तुलनामा धेरै कमजोर छन्।

यस लेखमा, हामी रेडिस प्रयोग गरेर वितरित लकिङ कसरी कार्यान्वयन गर्ने भनेर देखाउने क्यानोनिकल एल्गोरिथ्मको वर्णन गर्ने प्रयास गर्नेछौं। हामी एउटा एल्गोरिथ्मको बारेमा छलफल गर्नेछौं जसलाई रेडलकयसले वितरित लक प्रबन्धक लागू गर्दछ, र हामी विश्वास गर्छौं कि यो एल्गोरिथ्म परम्परागत एकल-उदाहरण दृष्टिकोण भन्दा बढी सुरक्षित छ। हामी आशा गर्छौं कि समुदायले यसलाई विश्लेषण गर्नेछ, प्रतिक्रिया प्रदान गर्नेछ, र यसलाई थप जटिल वा वैकल्पिक परियोजनाहरूको लागि सुरुवात बिन्दुको रूपमा प्रयोग गर्नेछ।

कार्यान्वयन

एल्गोरिथ्मको वर्णन गर्नु अघि, हामी अवस्थित कार्यान्वयनहरूको धेरै लिङ्कहरू प्रदान गर्नेछौं। यी सन्दर्भको लागि प्रयोग गर्न सकिन्छ।

• रेडलक-आरबी (रुबीको लागि कार्यान्वयन)। त्यहाँ पनि छ काँटा Redlock-rb, जसले वितरणको सहजताको लागि प्याकेज (रत्न) थप्छ, र थप कुराहरू।
• रेडलक-पाइ (पाइथनको लागि कार्यान्वयन)।
• आइओरेडलक (Asyncio Python को लागि कार्यान्वयन)।
• रेडलक-php (PHP को लागि कार्यान्वयन)।
• PHPRedisMutex (PHP को लागि अर्को कार्यान्वयन)
• चेप्रासोभ/php-रेडिस-लक (ब्लक गर्नको लागि PHP लाइब्रेरी)
• रेडसिन्क (गोको लागि कार्यान्वयन)।
• रेडिसन (जाभाको लागि कार्यान्वयन)।
• रेडिस::डिस्टलक (पर्लको लागि कार्यान्वयन)।
• रेडलक-सीपीपी (C++ को लागि कार्यान्वयन)।
• रेडलक-सीएस (C#/.NET को लागि कार्यान्वयन)।
• रेडलक.नेट (C#/.NET को लागि कार्यान्वयन)। एसिन्क्रोनस र लक एक्सटेन्सनहरूको लागि समर्थन सहित।
• स्कारलेटलक (कन्फिगरयोग्य डेटा भण्डारणको साथ C# .NET को लागि कार्यान्वयन)
• रेडलक४नेट (C# .NET को लागि कार्यान्वयन)
• नोड-रेडलक (नोडजेएसको लागि कार्यान्वयन)। लक एक्सटेन्सनको लागि समर्थन समावेश गर्दछ।

सुरक्षा र उपलब्धता ग्यारेन्टीहरू

हामी हाम्रो डिजाइनलाई केवल तीन गुणहरूसँग मोडेल गर्न गइरहेका छौं जुन हामीलाई विश्वास छ कि वितरित लकहरूको प्रभावकारी प्रयोगको लागि आवश्यक न्यूनतम ग्यारेन्टीहरू प्रदान गर्दछ।

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

यस अवस्थामा फेलओभर-आधारित कार्यान्वयन किन पर्याप्त छैन?
हामीले के सुधार गर्न खोजिरहेका छौं भनेर बुझ्नको लागि, धेरैजसो रेडिस-आधारित वितरित लकिङ पुस्तकालयहरूको हालको अवस्थाको विश्लेषण गरौं।

Redis प्रयोग गरेर स्रोत लक गर्ने सबैभन्दा सरल तरिका भनेको उदाहरणमा कुञ्जी सिर्जना गर्नु हो। सामान्यतया, कुञ्जी सीमित जीवनकालको साथ सिर्जना गरिन्छ, Redis को म्याद समाप्त हुने सुविधा प्रयोग गरेर प्राप्त गरिन्छ, त्यसैले कुञ्जी अन्ततः जारी हुन्छ (हाम्रो सूचीमा गुण २)। जब क्लाइन्टलाई स्रोत जारी गर्न आवश्यक हुन्छ, यसले कुञ्जी मेटाउँछ।

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

स्पष्ट रूपमा, यस्तो मोडेलमा दौडको अवस्था उत्पन्न हुन्छ:

1. ग्राहक A ले मास्टरमा लक प्राप्त गर्छ।
2. कुञ्जी प्रविष्टि दासमा प्रसारित हुनुभन्दा पहिले मालिक असफल हुन्छ।
3. अनुयायीलाई नेतामा पदोन्नति गरिन्छ।
4. क्लाइन्ट B ले A द्वारा पहिले नै लक गरिएको उही स्रोतमा लक प्राप्त गर्दछ। सुरक्षा उल्लङ्घन!

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

एउटै उदाहरणको साथ सही कार्यान्वयन

माथि वर्णन गरिएको एकल-उदाहरण कन्फिगरेसनका कमजोरीहरूलाई पार गर्ने प्रयास गर्नु अघि, यो साधारण केसलाई कसरी राम्रोसँग ह्यान्डल गर्ने भनेर हेरौं, किनकि यस्तो समाधान वास्तवमा ती अनुप्रयोगहरूमा स्वीकार्य छ जहाँ दौड अवस्थाहरू कहिलेकाहीं स्वीकार्य हुन्छन्, र किनभने एकल-उदाहरण लकिङ यहाँ वर्णन गरिएको वितरित एल्गोरिथ्ममा प्रयोग गरिएको आधार हो।

ताला खरिद गर्न, यी चरणहरू पालना गर्नुहोस्:

SET resource_name my_random_value NX PX 30000

यो आदेशले कुञ्जी पहिले नै अवस्थित नभएको खण्डमा मात्र स्थापना गर्छ (विकल्प NX), जसको म्याद समाप्ति समय ३०००० मिलिसेकेन्ड (विकल्प PX) हुन्छ। कुञ्जी "मान" मा सेट गरिएको छ।myrandomvalue"। यो मान सबै क्लाइन्टहरू र सबै लक अनुरोधहरूमा अद्वितीय हुनुपर्छ।
मूलतः, अनियमित मान सुरक्षित रूपमा लक रिलिज गर्न प्रयोग गरिन्छ, एउटा स्क्रिप्ट प्रयोग गरेर जसले रेडिसलाई यदि कुञ्जी अवस्थित छ र यसमा भण्डारण गरिएको मान अपेक्षा गरिएको थियो भने मात्र मेटाउन भन्छ। यो निम्न लुआ स्क्रिप्टको साथ प्राप्त गरिन्छ:

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

अर्को क्लाइन्टले अर्को क्लाइन्टले राखेको लक हटाउनबाट रोक्नको लागि यो महत्त्वपूर्ण छ। उदाहरणका लागि, एक क्लाइन्टले लक खरिद गर्न सक्छ, त्यसपछि सुरुको लक भन्दा लामो समयसम्म चल्ने अपरेशनको क्रममा लक आउट हुन सक्छ (साँचोको म्याद सकिन अनुमति दिँदै), र त्यसपछि अर्को क्लाइन्टले राखेको लक हटाउन सक्छ।
साधारण DEL प्रयोग गर्नु असुरक्षित छ, किनकि क्लाइन्टले पहिले अर्को क्लाइन्टले राखेको लक मेटाउन सक्छ। यसको विपरीत, माथिको स्क्रिप्टको साथ, प्रत्येक लक अनियमित स्ट्रिङको साथ "हस्ताक्षर" गरिएको छ, त्यसैले पहिले राखेको क्लाइन्टले मात्र यसलाई मेटाउन सक्छ।

यो अनियमित स्ट्रिङ कस्तो हुनुपर्छ? मलाई लाग्छ यो /dev/urandom बाट २० बाइट हुनुपर्छ, तर तपाईंको उद्देश्यका लागि स्ट्रिङलाई पर्याप्त अद्वितीय बनाउने कम खर्चिलो तरिकाहरू छन्। उदाहरणका लागि, /dev/urandom सँग RC4 सिडिङ गर्नु र त्यसपछि त्यसबाट स्यूडो-अनियमित स्ट्रिम उत्पन्न गर्नु ठीक हुनेछ। एउटा सरल समाधानमा युनिक्स समयलाई माइक्रोसेकेन्ड रिजोल्युसन र क्लाइन्ट ID सँग संयोजन गर्नु समावेश छ; यो त्यति सुरक्षित छैन, तर यो सम्भवतः धेरैजसो सन्दर्भहरूको लागि पर्याप्त छ।

हामीले साँचोको आयु मापन गर्न प्रयोग गर्ने समयलाई "लक लाइफटाइम" भनिन्छ। यो मान भनेको लक स्वतः रिलिज हुने समय र अर्को क्लाइन्टले पारस्परिक बहिष्करण ग्यारेन्टीको उल्लङ्घन नगरी स्रोत लक गर्नु अघि क्लाइन्टले अपरेशन गर्नु पर्ने समय दुवै हो। यो ग्यारेन्टी एक निश्चित समय विन्डोमा सीमित छ, जुन लक प्राप्त भएपछि सुरु हुन्छ।

त्यसोभए, हामीले लक प्राप्त गर्ने र रिलिज गर्ने राम्रो तरिकाको बारेमा छलफल गरेका छौं। प्रणाली (यदि हामी एकल, सधैं उपलब्ध उदाहरण मिलेर बनेको गैर-वितरित प्रणालीको बारेमा कुरा गर्दैछौं) सुरक्षित छ। यो अवधारणालाई वितरित प्रणालीमा विस्तार गरौं, जहाँ हामीसँग त्यस्तो ग्यारेन्टी छैन।

रेडलक एल्गोरिथ्म

एल्गोरिथ्मको वितरित संस्करणले हामीसँग N Redis मास्टरहरू छन् भन्ने मान्दछ। यी नोडहरू एकअर्काबाट पूर्ण रूपमा स्वतन्त्र छन्, त्यसैले हामी प्रतिकृति वा अन्य कुनै पनि निहित समन्वय प्रणाली प्रयोग गर्दैनौं। हामीले पहिले नै एकल उदाहरणमा लक कसरी सुरक्षित रूपमा प्राप्त गर्ने र रिलीज गर्ने भनेर वर्णन गरिसकेका छौं। हामी मान्दछौं कि एकल उदाहरणसँग काम गर्दा एल्गोरिथ्मले यो विधि प्रयोग गर्नेछ। हाम्रा उदाहरणहरूमा, हामीले N लाई 5 मा सेट गरेका छौं, जुन एक उचित मान हो। त्यसकारण, हामीले विभिन्न कम्प्युटर वा भर्चुअल मेसिनहरूमा पाँचवटा Redis मास्टरहरू प्रयोग गर्नुपर्नेछ ताकि तिनीहरू एकअर्काबाट धेरै हदसम्म स्वतन्त्र रूपमा सञ्चालन हुन्छन्।

लक खरिद गर्न, ग्राहकले निम्न चरणहरू पूरा गर्दछ:

1. मिलिसेकेन्डमा हालको समय प्राप्त गर्दछ।
2. सबै N उदाहरणहरूमा लक प्राप्त गर्ने क्रमिक प्रयास, सबै केसहरूमा एउटै कुञ्जी नाम र अनियमित मानहरू प्रयोग गरेर। चरण २ मा, प्रत्येक उदाहरणको लागि लक प्राप्त गर्दा, क्लाइन्टले यसलाई प्राप्त गर्न ढिलाइ प्रयोग गर्दछ, जुन लक स्वचालित रूपमा रिलीज भएको समयको तुलनामा पर्याप्त छोटो छ। उदाहरणका लागि, यदि लक अवधि १० सेकेन्ड छ भने, ढिलाइ ~५-५० मिलिसेकेन्डको दायरामा हुन सक्छ। यसले असफल रेडिस नोडमा पुग्ने प्रयास गर्दा क्लाइन्ट लामो समयसम्म अवरुद्ध रहन सक्ने अवस्थालाई रोक्छ: यदि एउटा उदाहरण उपलब्ध छैन भने, हामी सकेसम्म चाँडो अर्को उदाहरणमा जडान गर्ने प्रयास गर्छौं।
3. लक प्राप्त गर्न, क्लाइन्टले हालको समयबाट चरण १ मा प्राप्त गरिएको टाइमस्ट्याम्प घटाएर कति समय बित्यो भनेर गणना गर्छ। यदि र केवल यदि क्लाइन्टले धेरैजसो उदाहरणहरूमा (कम्तीमा ३) लक प्राप्त गर्न सक्षम भयो भने, र लक प्राप्त गर्न आवश्यक कुल समय लकको म्याद समाप्त हुने समय भन्दा कम छ भने, लक प्राप्त गरिएको मानिन्छ।
4. यदि लक प्राप्त गरिएको छ भने, यसको अवधिलाई चरण ३ मा गणना गरिएको बितेको समय घटाएर मूल लक अवधि मानिन्छ।
5. यदि क्लाइन्टले कुनै कारणले लक प्राप्त गर्न असफल भयो भने (या त यो N/2+1 उदाहरणहरू लक गर्न असफल भयो, वा लक समाप्ति समय ऋणात्मक छ), यसले सबै उदाहरणहरू अनलक गर्ने प्रयास गर्नेछ (जुन यसलाई लक गर्न नसक्ने सोचिएको थियो)।

के एल्गोरिथ्म एसिन्क्रोनस छ?

यो एल्गोरिथ्म यो धारणामा आधारित छ कि, सबै प्रक्रियाहरूमा कुनै सिङ्क्रोनाइज्ड घडी नभए पनि, प्रत्येक प्रक्रियामा स्थानीय समय अझै पनि लगभग समान दरमा बग्छ, र लक स्वचालित रूपमा रिलीज हुने समग्र समयको तुलनामा त्रुटि सानो छ। यो धारणा नियमित कम्प्युटरहरूको लागि सामान्य अवस्थासँग धेरै मिल्दोजुल्दो छ: प्रत्येक कम्प्युटरमा स्थानीय घडी हुन्छ, र हामी सामान्यतया विभिन्न कम्प्युटरहरू बीचको समय भिन्नता सानो भएकोमा गणना गर्न सक्छौं।

यस बिन्दुमा, हामीले हाम्रो पारस्परिक बहिष्करण नियमलाई अझ सावधानीपूर्वक बनाउनु आवश्यक छ: पारस्परिक बहिष्करणको ग्यारेन्टी तब मात्र हुन्छ जब लक धारण गर्ने क्लाइन्टले लक मान्य भएको समय भित्र समाप्त हुन्छ (चरण ३ मा प्राप्त मान), केही अतिरिक्त समय घटाएर (प्रक्रियाहरू बीचको समय अन्तरालको क्षतिपूर्ति गर्न केही मिलिसेकेन्ड मात्र)।

निम्न रोचक लेखले समय-परिवर्तनशील समन्वय आवश्यक पर्ने समान प्रणालीहरूको बारेमा थप विवरणहरू प्रदान गर्दछ: पट्टाहरू: वितरित फाइल क्यास स्थिरताको लागि एक कुशल गल्ती-सहनशील संयन्त्र.

असफलतामा पुन: प्रयास गर्नुहोस्

जब कुनै क्लाइन्टले लक प्राप्त गर्न असफल हुन्छ, यसले अनियमित ढिलाइ पछि पुन: प्रयास गर्नुपर्छ। यो धेरै क्लाइन्टहरूलाई एउटै स्रोतमा लक प्राप्त गर्ने प्रयास गर्दा सिङ्क बाहिर हुनबाट रोक्नको लागि गरिन्छ (जसले "स्प्लिट-ब्रेन" स्थिति निम्त्याउन सक्छ जहाँ कुनै विजेता हुँदैनन्)। यसबाहेक, धेरैजसो रेडिस उदाहरणहरूमा क्लाइन्टले लक प्राप्त गर्ने प्रयास जति छिटो गर्छ, विभाजित-ब्रेन स्थिति हुन सक्ने विन्डो त्यति नै साँघुरो हुन्छ (र पुन: प्रयासको आवश्यकता त्यति नै कम हुन्छ)। त्यसकारण, आदर्श रूपमा, क्लाइन्टले मल्टिप्लेक्सिङ प्रयोग गरेर N उदाहरणहरूमा SET आदेशहरू एकैसाथ पठाउने प्रयास गर्नुपर्छ।

यहाँ यो कुरा जोड दिनु उचित छ कि धेरैजसो लकहरू प्राप्त गर्न असफल हुने ग्राहकहरूले आफूले प्राप्त गरेका लकहरू (आंशिक रूपमा) रिलिज गर्नु कत्तिको महत्त्वपूर्ण छ, ताकि उनीहरूले स्रोतमा फेरि लक प्राप्त गर्न सक्नु अघि साँचोको म्याद समाप्त हुनको लागि पर्खनु नपरोस् (यद्यपि यदि नेटवर्क विखंडन हुन्छ र ग्राहकले रेडिस उदाहरणहरूमा जडान गुमाउँछ भने, साँचोको म्याद समाप्त हुनको लागि पर्खँदा आउटेजको लागि जरिवाना हुन्छ)।

ताला खोल्दै

लक रिलिज गर्नु एउटा साधारण कार्य हो जसको लागि सबै उदाहरणहरू अनलक गर्न आवश्यक पर्दछ, ग्राहकले कुनै विशेष उदाहरण सफलतापूर्वक लक गर्न सक्षम भएको विश्वास गरे पनि।

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

के एल्गोरिथ्म सुरक्षित छ? विभिन्न परिदृश्यहरूमा के हुन्छ भनेर कल्पना गर्ने प्रयास गरौं।

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

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

यदि कुनै क्लाइन्टले अधिकतम लक अवधि बराबर वा सोभन्दा बढी समयमा धेरैजसो इन्स्ट्यान्सहरू लक गरेको छ भने, यसले लकलाई अमान्य ठान्नेछ र इन्स्ट्यान्सहरू अनलक गर्नेछ। त्यसकारण, हामीले केवल त्यो केसलाई विचार गर्न आवश्यक छ जहाँ क्लाइन्टले लक अवधि भन्दा कम समयमा धेरैजसो इन्स्ट्यान्सहरू लक गर्न सफल भएको छ। यस अवस्थामा, माथिको तर्कको सन्दर्भमा, MIN_VALIDITY कुनै पनि क्लाइन्टले लक पुन: प्राप्त गर्न सक्षम हुनु हुँदैन। त्यसकारण, धेरै क्लाइन्टहरूले समान समयमा N/2+1 उदाहरणहरू लक गर्न सक्षम हुनेछन् (जुन चरण २ को समाप्तिमा समाप्त हुन्छ) यदि बहुमत लक समय TTL भन्दा बढी थियो भने मात्र, जसले लकलाई अमान्य बनाउँछ।

के तपाईं सुरक्षाको औपचारिक प्रमाण प्रदान गर्न सक्नुहुन्छ, अवस्थित समान एल्गोरिदमहरू औंल्याउन सक्नुहुन्छ, वा प्रस्तुत गरिएको कुरामा बग फेला पार्न सक्नुहुन्छ?

पहुँचयोग्यता सम्बन्धी विचारहरू

प्रणालीको उपलब्धता तीन मुख्य विशेषताहरूमा निर्भर गर्दछ:

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

यद्यपि, नेटवर्क खण्डहरूमा TTL समय बराबर उपलब्धता घटेकोमा जरिवाना छ, त्यसैले यदि त्यहाँ नजिकका खण्डहरू छन् भने, यो जरिवाना अनिश्चितकालीन हुन सक्छ। यो तब हुन्छ जब ग्राहकले लक प्राप्त गर्छ र त्यसपछि यसलाई रिलीज गर्न सक्नु अघि अर्को खण्डमा काटिन्छ।

सिद्धान्ततः, अनन्त निरन्तर नेटवर्क खण्डहरू दिइएको खण्डमा, प्रणाली अनन्त समयको लागि अनुपलब्ध रहन सक्छ।

प्रदर्शन, फेलओभर, र fsync

धेरै मानिसहरूले रेडिस प्रयोग गर्छन् किनभने उनीहरूलाई उच्च लक सर्भर कार्यसम्पादन चाहिन्छ, लकहरू प्राप्त गर्न र रिलीज गर्न आवश्यक पर्ने विलम्बता, साथै प्रति सेकेन्ड गर्न सकिने अधिग्रहण/रिलीजहरूको संख्याको सन्दर्भमा। यो आवश्यकता पूरा गर्न, N Redis सर्भरहरूको लागि विलम्बता कम गर्न एक सञ्चार रणनीति अवस्थित छ। यो एक मल्टिप्लेक्सिङ रणनीति हो (वा "गरीब मानिसको मल्टिप्लेक्सिङ," जसमा सकेट गैर-ब्लकिङ मोडमा सेट गरिएको छ, सबै आदेशहरू पठाउँछ, र पछि आदेशहरू पुन: प्राप्त गर्दछ, क्लाइन्ट र प्रत्येक उदाहरण बीच समान राउन्ड-ट्रिप समय मान्दै)।

यद्यपि, यदि हामी भरपर्दो विफलता रिकभरीको साथ मोडेल सिर्जना गर्न चाहन्छौं भने हामीले डेटाको दीर्घकालीन भण्डारणलाई पनि विचार गर्नुपर्छ।

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

अग्रिम-समय (AOF) सक्षम गर्नाले स्थितिमा थोरै सुधार हुनेछ। उदाहरणका लागि, तपाईंले SHUTDOWN आदेश पठाएर र यसलाई पुन: सुरु गरेर सर्भरलाई प्रवर्द्धन गर्न सक्नुहुन्छ। Redis समाप्ति अपरेसनहरू अर्थपूर्ण रूपमा यसरी लागू गरिएको हुनाले सर्भर बन्द हुँदा पनि समय प्रवाहित रहन्छ, हाम्रा सबै आवश्यकताहरू पूरा हुन्छन्। जबसम्म एक आकर्षक बन्द सुनिश्चित गरिन्छ तबसम्म यो ठीक छ। तर पावर आउटेजको बारेमा के हुन्छ? यदि Redis पूर्वनिर्धारित रूपमा कन्फिगर गरिएको छ, प्रत्येक सेकेन्डमा डिस्कमा fsync सिङ्क्रोनाइजेसनको साथ, यो सम्भव छ कि पुन: सुरु गरेपछि हामीले हाम्रो कुञ्जी गुमाउनेछौं। सैद्धान्तिक रूपमा, यदि हामी कुनै पनि उदाहरण पुन: सुरुमा लक सुरक्षाको ग्यारेन्टी गर्न चाहन्छौं भने, हामीले सक्षम गर्नुपर्छ fsync=always निरन्तर डेटा सेटिङहरूमा। यसले कार्यसम्पादनलाई पूर्ण रूपमा नष्ट गर्नेछ, परम्परागत रूपमा वितरित लकहरू सुरक्षित रूपमा कार्यान्वयन गर्न प्रयोग गरिने CP प्रणालीहरूको स्तरसम्म।

तर अवस्था पहिलो नजरमा देखिने भन्दा राम्रो छ। सिद्धान्तमा, एल्गोरिथ्मको सुरक्षा संरक्षित छ, किनकि जब कुनै उदाहरण असफलता पछि पुन: सुरु हुन्छ, यो अब कुनै पनि हाल सक्रिय लकहरूमा भाग लिँदैन।

यसको ग्यारेन्टी गर्न, हामीले यो सुनिश्चित गर्न आवश्यक छ कि असफलता पछि, हामीले प्रयोग गरिरहेको अधिकतम TTL भन्दा अलि बढी समयको लागि उदाहरण अनुपलब्ध रहनेछ। यसले असफलताको समयमा सक्रिय रहेका सबै कुञ्जीहरूको म्याद समाप्त हुन र स्वचालित रूपमा रिलीज हुन अनुमति दिनेछ।

ढिलो पुन: सुरु प्रयोग गरेर, Redis मा कुनै पनि दीर्घकालीन निरन्तरता बिना पनि सुरक्षा प्राप्त गर्न सम्भव छ। यद्यपि, यो ध्यान दिन लायक छ कि यसले उपलब्धता उल्लङ्घनको लागि जरिवाना हुन सक्छ। उदाहरणका लागि, यदि धेरैजसो उदाहरणहरू असफल भएमा, प्रणाली TTL को लागि विश्वव्यापी रूपमा अनुपलब्ध हुनेछ (र यस समयमा कुनै पनि स्रोत लक गर्न सकिँदैन)।

एल्गोरिथ्मको उपलब्धता बढाउने: अवरुद्ध अवधि विस्तार गर्ने

यदि क्लाइन्टहरूले गर्ने काममा साना चरणहरू समावेश छन् भने, पूर्वनिर्धारित लकको जीवनकाल घटाउन र लक नवीकरण संयन्त्र लागू गर्न सम्भव छ। सिद्धान्तमा, यदि क्लाइन्ट गणना गर्न व्यस्त छ र लकको जीवनकाल खतरनाक रूपमा कम छ भने, यदि कुञ्जी अझै पनि अवस्थित छ र यसको मान अझै पनि लक प्राप्त गर्दा प्राप्त गरिएको अनियमित मान हो भने, सबै उदाहरणहरूमा लुआ स्क्रिप्ट पठाउन सकिन्छ जसले कुञ्जी TTL विस्तार गर्दछ।

ग्राहकले वैधता अवधि भित्र धेरैजसो उदाहरणहरू सफलतापूर्वक लक गरेको खण्डमा मात्र लक पुन: प्राप्त गर्ने विचार गर्नुपर्छ।

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

स्रोत: www.habr.com