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

हे हाबर!

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

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

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

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

कार्यान्वयन

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

• Redlock-rb (रुबी को लागी कार्यान्वयन)। पनि छ काँटा Redlock-rb, जसले वितरणको सहजताको लागि प्याकेज (रत्न) थप्छ, र त्यसको लागि मात्र होइन।
• Redlock-py (पाइथन कार्यान्वयन)।
• Aioredlock (Asyncio Python को लागी कार्यान्वयन)।
• Redlock-php (PHP को लागी कार्यान्वयन)।
• PHPRedisMutex (PHP को लागि अर्को कार्यान्वयन)
• cheprasov/php-redis-lock (लकहरूको लागि PHP पुस्तकालय)
• Redsync (Go को लागी कार्यान्वयन)।
• रेडिसन (जाभाको लागि कार्यान्वयन)।
• Redis::DistLock (Perl को लागी कार्यान्वयन)।
• Redlock-cpp (C++ को लागी कार्यान्वयन)।
• Redlock-cs (C#/.NET को लागी कार्यान्वयन)।
• RedLock.net (C#/.NET को लागी कार्यान्वयन)। async र लक विस्तारहरूको लागि समर्थनको साथ।
• स्कार्लेट लक (कन्फिगर योग्य डाटा स्टोरको साथ C# .NET को लागी कार्यान्वयन)
• Redlock4Net (C# .NET को लागी कार्यान्वयन)
• नोड-रेडलक (NodeJS को लागी कार्यान्वयन)। तालाहरू विस्तार गर्न समर्थन समावेश गर्दछ।

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

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

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

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

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

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

जाहिर छ, यस्तो मोडेल मा एक दौड अवस्था हुन्छ:

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

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

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

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

लक प्राप्त गर्न, यो गर्नुहोस्:

SET resource_name my_random_value NX PX 30000

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

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 सँग सीड गर्नु राम्रो हुन्छ र त्यसपछि यसबाट छद्म-यादृच्छिक स्ट्रिम उत्पन्न गर्नुहोस्। एक सरल समाधानले माइक्रोसेकेन्ड रिजोल्युसन र क्लाइन्ट आईडीमा युनिक्स समयको संयोजन समावेश गर्दछ; यो त्यति सुरक्षित छैन, तर यो सम्भवतः धेरै सन्दर्भहरूमा कार्यमा निर्भर छ।

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

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

Redlock एल्गोरिथ्म

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

लक प्राप्त गर्न, ग्राहकले निम्न कार्यहरू गर्दछ:

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

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

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

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

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

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

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

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

ताला छोड्नुहोस्

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

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

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

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

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

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

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

पहुँच विचारहरू

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

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

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

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

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

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

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

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

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

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

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

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

हामी एल्गोरिदमको उपलब्धता बढाउँछौं: हामी अवरुद्ध विस्तार गर्छौं

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

यदि ग्राहकले वैधता अवधि भित्र अधिकांश उदाहरणहरू लक गर्न व्यवस्थित गरेको छ भने मात्र लक पुन: प्राप्त गर्नको लागि विचार गर्नुपर्छ।

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

स्रोत: www.habr.com