एक ऐसे उत्पाद की बात करें जो एक दशक से अधिक समय से विकसित हो रहा है, तो इसमें पुरानी तकनीकों का पाया जाना बिल्कुल भी आश्चर्यजनक नहीं है। लेकिन क्या होगा यदि छह महीने में आपको भार 10 गुना अधिक रखना पड़े, और गिरने की लागत सैकड़ों गुना बढ़ जाए? इस मामले में, आपको एक अच्छे हाईलोड इंजीनियर की आवश्यकता है। लेकिन नौकरानी की अनुपस्थिति में, उन्होंने समस्या को हल करने का जिम्मा मुझे सौंपा। लेख के पहले भाग में मैं आपको बताऊंगा कि हम रेडिस से रेडिस-क्लस्टर में कैसे चले गए, और दूसरे भाग में मैं सलाह दूंगा कि क्लस्टर का उपयोग कैसे शुरू करें और इसका उपयोग करते समय किन बातों पर ध्यान देना चाहिए।

प्रौद्योगिकी विकल्प

क्या यह बुरा है? अलग रेडिस (स्टैंडअलोन रेडिस) 1 मास्टर और एन स्लेव के कॉन्फ़िगरेशन में? मैं इसे अप्रचलित प्रौद्योगिकी क्यों कहता हूँ?

नहीं, रेडिस उतना बुरा नहीं है... हालाँकि, कुछ कमियाँ हैं जिन्हें नज़रअंदाज़ नहीं किया जा सकता।

• सबसे पहले, रेडिस मास्टर विफलता के बाद आपदा पुनर्प्राप्ति तंत्र का समर्थन नहीं करता है। इस समस्या को हल करने के लिए, हमने एक नए मास्टर को वीआईपी के स्वचालित हस्तांतरण के साथ एक कॉन्फ़िगरेशन का उपयोग किया, दासों में से एक की भूमिका बदल दी और बाकी को बदल दिया। यह तंत्र काम तो कर गया, लेकिन इसे विश्वसनीय समाधान नहीं कहा जा सका। सबसे पहले, झूठे अलार्म उत्पन्न हुए, और दूसरे, यह डिस्पोजेबल था, और ऑपरेशन के बाद स्प्रिंग को चार्ज करने के लिए मैन्युअल क्रियाओं की आवश्यकता थी।

• दूसरे, केवल एक मास्टर होने से शार्डिंग की समस्या उत्पन्न हुई। हमें कई स्वतंत्र क्लस्टर "1 मास्टर और एन स्लेव्स" बनाने थे, फिर इन मशीनों के बीच डेटाबेस को मैन्युअल रूप से वितरित करना था और उम्मीद थी कि कल डेटाबेस में से एक इतना नहीं बढ़ेगा कि इसे एक अलग उदाहरण में ले जाना होगा।

विकल्प क्या हैं?

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

उपयोग की विशिष्टताएँ

आइए देखें कि रेडिस के साथ हमने ऐतिहासिक रूप से किन समस्याओं का समाधान किया है और हमने किस कार्यक्षमता का उपयोग किया है:

• 2जीआईएस जैसी दूरस्थ सेवाओं के अनुरोध से पहले कैश गोलांग
  

  सेट एमजीईटी एमसेट प्राप्त करें "डीबी चुनें"

• MYSQL से पहले कैश | पीएचपी
  

  सेट एमजीईटी एमसेट स्कैन प्राप्त करें "पैटर्न द्वारा कुंजी" "डीबी चुनें"

• सत्र और ड्राइवर निर्देशांक के साथ काम करने की सेवा के लिए मुख्य भंडारण | गोलांग
  

  सेट प्राप्त करें एमजीईटी एमसेट "डीबी चुनें" "जियो कुंजी जोड़ें" "जियो कुंजी प्राप्त करें" स्कैन

जैसा कि आप देख सकते हैं, कोई उच्चतर गणित नहीं है। फिर कठिनाई क्या है? आइए प्रत्येक विधि को अलग से देखें।

विधि
विवरण
रेडिस-क्लस्टर की विशेषताएं
समाधान

तैयार हो जाओ
लिखें/पढ़ें कुंजी

एमजीईटी एमसेट
एकाधिक कुंजियाँ लिखें/पढ़ें
चाबियाँ अलग-अलग नोड्स पर होंगी। तैयार पुस्तकालय केवल एक नोड के भीतर बहु-संचालन कर सकते हैं
MGET को N GET संचालन की पाइपलाइन से बदलें

डीबी का चयन करें
वह आधार चुनें जिसके साथ हम काम करेंगे
एकाधिक डेटाबेस का समर्थन नहीं करता
सब कुछ एक डेटाबेस में रखें. कुंजियों में उपसर्ग जोड़ें

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

भू
जियोकी के साथ संचालन
जियोकी शार्ड नहीं है

पैटर्न के अनुसार कुंजी
पैटर्न के आधार पर कुंजी की खोज की जा रही है
चूँकि हमारे पास एक डेटाबेस है, हम क्लस्टर की सभी कुंजियों में खोज करेंगे। अधिक महंगा
स्कैन के मामले में, अपरिवर्तनीय को अस्वीकार करें या बनाए रखें

रेडिस बनाम रेडिस-क्लस्टर

क्लस्टर पर स्विच करने पर हम क्या खोते हैं और क्या हासिल करते हैं?

• नुकसान: हम कई डेटाबेस की कार्यक्षमता खो देते हैं।
  • यदि हम तार्किक रूप से असंबंधित डेटा को एक क्लस्टर में संग्रहीत करना चाहते हैं, तो हमें उपसर्गों के रूप में बैसाखी बनानी होगी।
  • हम सभी "आधार" ऑपरेशन खो देते हैं, जैसे SCAN, DBSIZE, CLEAR DB, आदि।
  • मल्टी-ऑपरेशंस को लागू करना अधिक कठिन हो गया है क्योंकि इसके लिए कई नोड्स तक पहुंच की आवश्यकता हो सकती है।
• लाभ:
  • मास्टर फेलओवर के रूप में दोष सहनशीलता।
  • रेडिस पक्ष पर साझाकरण।
  • नोड्स के बीच परमाणु रूप से और बिना डाउनटाइम के डेटा ट्रांसफर करें।
  • बिना डाउनटाइम के क्षमता और भार जोड़ें और पुनर्वितरित करें।

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

चलने की तैयारी कर रहा हूँ

आइए स्थानांतरण के लिए आवश्यकताओं से शुरुआत करें:

• यह निर्बाध होना चाहिए. 5 मिनट के लिए सेवा का पूर्ण रूप से बंद होना हमें शोभा नहीं देता।
• यह यथासंभव सुरक्षित और क्रमिक होना चाहिए। मैं स्थिति पर कुछ नियंत्रण रखना चाहता हूं. हम एक ही बार में सब कुछ ख़त्म नहीं करना चाहते और रोलबैक बटन के लिए प्रार्थना नहीं करना चाहते।
• चलते समय न्यूनतम डेटा हानि। हम समझते हैं कि परमाणु रूप से स्थानांतरित करना बहुत मुश्किल होगा, इसलिए हम नियमित और क्लस्टर्ड रेडिस में डेटा के बीच कुछ डीसिंक्रनाइज़ेशन की अनुमति देते हैं।

क्लस्टर रखरखाव

इस कदम से ठीक पहले, हमें इस बारे में सोचना चाहिए कि क्या हम क्लस्टर का समर्थन कर सकते हैं:

• चार्ट. हम सीपीयू लोड, मेमोरी उपयोग, क्लाइंट की संख्या, GET, SET, AUTH संचालन की संख्या आदि को ग्राफ़ करने के लिए प्रोमेथियस और ग्राफाना का उपयोग करते हैं।
• विशेषज्ञता. कल्पना कीजिए कि कल आपके जिम्मे एक बहुत बड़ा समूह होगा। यदि यह टूट जाता है, तो आपके अलावा कोई भी इसे ठीक नहीं कर सकता है। अगर वह धीमा होने लगे तो हर कोई आपकी ओर दौड़ेगा। यदि आपको संसाधन जोड़ने या भार का पुनर्वितरण करने की आवश्यकता है, तो आपके पास वापस आएं। 25 साल की उम्र में धूसर न होने के लिए, इन मामलों के लिए प्रावधान करने और पहले से जांच करने की सलाह दी जाती है कि तकनीक कुछ कार्यों के तहत कैसे व्यवहार करेगी। आइए "विशेषज्ञता" अनुभाग में इसके बारे में अधिक विस्तार से बात करें।
• निगरानी और अलर्ट. जब कोई क्लस्टर टूटता है, तो आप उसके बारे में सबसे पहले जानना चाहते हैं। यहां हमने खुद को एक अधिसूचना तक सीमित कर लिया है कि सभी नोड क्लस्टर की स्थिति के बारे में समान जानकारी लौटाते हैं (हां, यह अलग तरह से होता है)। और अन्य समस्याओं को Redis क्लाइंट सेवाओं के अलर्ट द्वारा अधिक तेज़ी से देखा जा सकता है।

चौराहा

हम कैसे आगे बढ़ेंगे:

• सबसे पहले, आपको क्लस्टर के साथ काम करने के लिए एक लाइब्रेरी तैयार करने की आवश्यकता है। हमने गो-रेडिस को गो संस्करण के आधार के रूप में लिया और इसे अपने अनुकूल बनाने के लिए इसमें थोड़ा बदलाव किया। हमने पाइपलाइनों के माध्यम से बहु-विधियों को लागू किया, और दोहराए जाने वाले अनुरोधों के नियमों को भी थोड़ा ठीक किया। PHP संस्करण में अधिक समस्याएँ थीं, लेकिन अंततः हमने php-redis पर निर्णय लिया। उन्होंने हाल ही में क्लस्टर सपोर्ट पेश किया है और हमारी राय में यह अच्छा लग रहा है।
• आगे आपको क्लस्टर को स्वयं तैनात करने की आवश्यकता है। यह कॉन्फ़िगरेशन फ़ाइल के आधार पर वस्तुतः दो कमांड में किया जाता है। हम नीचे सेटिंग पर अधिक विस्तार से चर्चा करेंगे।
• धीरे-धीरे आगे बढ़ने के लिए हम ड्राई-मोड का उपयोग करते हैं। चूँकि हमारे पास एक ही इंटरफ़ेस के साथ लाइब्रेरी के दो संस्करण हैं (एक नियमित संस्करण के लिए, दूसरा क्लस्टर के लिए), एक रैपर बनाने में कुछ भी खर्च नहीं होता है जो एक अलग संस्करण के साथ काम करेगा और समानांतर में क्लस्टर के सभी अनुरोधों को डुप्लिकेट करेगा, प्रतिक्रियाओं की तुलना करें और लॉग में विसंगतियां लिखें (न्यूरेलिक में हमारे मामले में)। इस प्रकार, भले ही रोलआउट के दौरान क्लस्टर संस्करण टूट जाए, हमारा उत्पादन प्रभावित नहीं होगा।
• क्लस्टर को ड्राई मोड में रोल आउट करने के बाद, हम शांति से प्रतिक्रिया विसंगतियों के ग्राफ को देख सकते हैं। यदि त्रुटि दर धीरे-धीरे लेकिन निश्चित रूप से कुछ छोटे स्थिरांक की ओर बढ़ती है, तो सब कुछ ठीक है। अभी भी विसंगतियाँ क्यों हैं? क्योंकि एक अलग संस्करण में रिकॉर्डिंग क्लस्टर की तुलना में थोड़ी देर पहले होती है, और माइक्रोलैग के कारण डेटा अलग हो सकता है। जो कुछ बचा है वह विसंगति लॉग को देखना है, और यदि उन सभी को रिकॉर्ड की गैर-परमाणुता द्वारा समझाया गया है, तो हम आगे बढ़ सकते हैं।
• अब आप ड्राई-मोड को विपरीत दिशा में स्विच कर सकते हैं। हम क्लस्टर से लिखेंगे और पढ़ेंगे, और इसे एक अलग संस्करण में डुप्लिकेट करेंगे। किस लिए? अगले सप्ताह मैं क्लस्टर के काम का निरीक्षण करना चाहूँगा। यदि यह अचानक पता चलता है कि चरम लोड पर समस्याएं हैं, या हमने कुछ ध्यान में नहीं रखा है, तो हमारे पास हमेशा पुराने कोड और ड्राई-मोड के कारण वर्तमान डेटा पर एक आपातकालीन रोलबैक होता है।
• जो कुछ बचा है वह ड्राई-मोड को अक्षम करना और अलग संस्करण को नष्ट करना है।

जांच

सबसे पहले, क्लस्टर डिज़ाइन के बारे में संक्षेप में।

सबसे पहले, रेडिस एक कुंजी-मूल्य स्टोर है। मनमानी तारों का उपयोग चाबियों के रूप में किया जाता है। संख्याओं, स्ट्रिंग्स और संपूर्ण संरचनाओं का उपयोग मानों के रूप में किया जा सकता है। उत्तरार्द्ध बहुत सारे हैं, लेकिन सामान्य संरचना को समझने के लिए यह हमारे लिए महत्वपूर्ण नहीं है।
कुंजियों के बाद अमूर्तन का अगला स्तर स्लॉट्स (SLOTS) है। प्रत्येक कुंजी 16 स्लॉट में से एक से संबंधित है। प्रत्येक स्लॉट के अंदर कितनी भी संख्या में चाबियाँ हो सकती हैं। इस प्रकार, सभी कुंजियाँ 383 असंयुक्त सेटों में विभाजित हैं।

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

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

अब उन ऑपरेशनों के बारे में बात करते हैं जिन्हें करने में सक्षम होना बेहतर होगा।

हम Redis-CLI के माध्यम से सिस्टम तक पहुँच प्राप्त करेंगे। चूँकि Redis में एक भी प्रवेश बिंदु नहीं है, आप किसी भी नोड पर निम्नलिखित ऑपरेशन कर सकते हैं। प्रत्येक बिंदु पर मैं लोड के तहत ऑपरेशन करने की संभावना पर अलग से ध्यान आकर्षित करता हूं।

• पहली और सबसे महत्वपूर्ण चीज़ जो हमें चाहिए वह है क्लस्टर नोड्स ऑपरेशन। यह क्लस्टर की स्थिति लौटाता है, नोड्स की सूची, उनकी भूमिकाएँ, स्लॉट वितरण आदि दिखाता है। क्लस्टर जानकारी और क्लस्टर स्लॉट का उपयोग करके अधिक जानकारी प्राप्त की जा सकती है।
• नोड्स जोड़ने और हटाने में सक्षम होना अच्छा होगा। इस उद्देश्य के लिए क्लस्टर मीट और क्लस्टर फॉरगेट ऑपरेशन हैं। कृपया ध्यान दें कि क्लस्टर फ़ॉरगेट को प्रत्येक नोड, मास्टर्स और प्रतिकृतियों दोनों पर लागू किया जाना चाहिए। और क्लस्टर मीट को केवल एक नोड पर कॉल करने की आवश्यकता है। यह अंतर परेशान करने वाला हो सकता है, इसलिए बेहतर होगा कि आप अपने क्लस्टर के साथ रहने से पहले इसके बारे में जान लें। नोड जोड़ना लड़ाई में सुरक्षित रूप से किया जाता है और किसी भी तरह से क्लस्टर के संचालन को प्रभावित नहीं करता है (जो तार्किक है)। यदि आप क्लस्टर से एक नोड को हटाने जा रहे हैं, तो आपको यह सुनिश्चित करना चाहिए कि उस पर कोई स्लॉट नहीं बचा है (अन्यथा आप इस नोड की सभी कुंजियों तक पहुंच खोने का जोखिम उठाते हैं)। साथ ही, ऐसे स्वामी को न हटाएं जिसके पास दास हों, अन्यथा नए स्वामी के लिए अनावश्यक वोट किया जाएगा। यदि नोड्स में अब स्लॉट नहीं हैं, तो यह एक छोटी सी समस्या है, लेकिन अगर हम पहले स्लेव को हटा सकते हैं तो हमें अतिरिक्त विकल्पों की आवश्यकता क्यों है।
• यदि आपको मास्टर और स्लेव पदों को जबरदस्ती बदलने की आवश्यकता है, तो क्लस्टर फेलओवर कमांड काम करेगा। युद्ध में इसे बुलाते समय, आपको यह समझने की ज़रूरत है कि ऑपरेशन के दौरान मास्टर उपलब्ध नहीं होगा। आमतौर पर स्विच एक सेकंड से भी कम समय में होता है, लेकिन यह परमाणु नहीं है। आप उम्मीद कर सकते हैं कि इस दौरान मास्टर से किए गए कुछ अनुरोध विफल हो जाएंगे।
• क्लस्टर से किसी नोड को हटाने से पहले, उस पर कोई स्लॉट नहीं छोड़ा जाना चाहिए। क्लस्टर रीशर्ड कमांड का उपयोग करके उन्हें पुनर्वितरित करना बेहतर है। स्लॉट एक मास्टर से दूसरे मास्टर को स्थानांतरित कर दिए जाएंगे। पूरे ऑपरेशन में कई मिनट लग सकते हैं, यह स्थानांतरित किए जा रहे डेटा की मात्रा पर निर्भर करता है, लेकिन स्थानांतरण प्रक्रिया सुरक्षित है और किसी भी तरह से क्लस्टर के संचालन को प्रभावित नहीं करती है। इस प्रकार, सभी डेटा को लोड के तहत सीधे एक नोड से दूसरे में स्थानांतरित किया जा सकता है, और इसकी उपलब्धता के बारे में चिंता किए बिना। हालाँकि, बारीकियाँ भी हैं। सबसे पहले, डेटा स्थानांतरण प्राप्तकर्ता और प्रेषक नोड्स पर एक निश्चित भार से जुड़ा होता है। यदि प्राप्तकर्ता नोड पहले से ही प्रोसेसर पर भारी लोड है, तो आपको इसे नए डेटा प्राप्त करने के साथ लोड नहीं करना चाहिए। दूसरे, जैसे ही भेजने वाले मास्टर पर एक भी स्लॉट नहीं बचेगा, उसके सभी दास तुरंत उस मास्टर के पास चले जाएंगे जिसके पास ये स्लॉट स्थानांतरित किए गए थे। और समस्या यह है कि ये सभी गुलाम एक ही बार में डेटा को सिंक्रनाइज़ करना चाहेंगे। और यदि यह पूर्ण सिंक्रनाइज़ेशन के बजाय आंशिक है तो आप भाग्यशाली होंगे। इसे ध्यान में रखें और स्लॉट्स को स्थानांतरित करने और स्लेव को अक्षम/स्थानांतरित करने के संचालन को संयोजित करें। या आशा करें कि आपके पास सुरक्षा का पर्याप्त मार्जिन है।
• यदि स्थानांतरण के दौरान आपको पता चले कि आपका स्लॉट कहीं खो गया है तो आपको क्या करना चाहिए? मुझे आशा है कि यह समस्या आपको प्रभावित नहीं करेगी, लेकिन यदि ऐसा होता है, तो क्लस्टर फिक्स ऑपरेशन होता है। कम से कम, वह स्लॉट्स को यादृच्छिक क्रम में नोड्स में बिखेर देगी। मैं पहले क्लस्टर से वितरित स्लॉट वाले नोड को हटाकर इसके संचालन की जांच करने की सलाह देता हूं। चूंकि असंबद्ध स्लॉट में डेटा पहले से ही अनुपलब्ध है, इसलिए इन स्लॉट की उपलब्धता के साथ समस्याओं के बारे में चिंता करने में बहुत देर हो चुकी है। बदले में, ऑपरेशन वितरित स्लॉट को प्रभावित नहीं करेगा।
• एक अन्य उपयोगी ऑपरेशन मॉनिटर है। यह आपको वास्तविक समय में नोड पर जाने वाले अनुरोधों की पूरी सूची देखने की अनुमति देता है। इसके अलावा, आप इसकी जानकारी ले सकते हैं और पता लगा सकते हैं कि आवश्यक ट्रैफ़िक है या नहीं।

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

विन्यास

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

• टाइमआउट 0
  वह समय जिसके बाद निष्क्रिय कनेक्शन बंद हो जाते हैं (सेकंड में)। 0 - बंद न करें
  हमारी प्रत्येक लाइब्रेरी कनेक्शनों को सही ढंग से बंद करने में सक्षम नहीं थी। इस सेटिंग को अक्षम करने से, हम ग्राहकों की संख्या की सीमा समाप्त होने का जोखिम उठाते हैं। दूसरी ओर, यदि ऐसी कोई समस्या है, तो खोए हुए कनेक्शनों की स्वचालित समाप्ति इसे छुपा देगी, और हम ध्यान नहीं दे पाएंगे। इसके अलावा, आपको पर्सिस्ट कनेक्शन का उपयोग करते समय इस सेटिंग को सक्षम नहीं करना चाहिए।
• xy सहेजें और केवल हाँ जोड़ें
  RDB स्नैपशॉट सहेजा जा रहा है।
  हम नीचे आरडीबी/एओएफ मुद्दों पर विस्तार से चर्चा करेंगे।
• स्टॉप-राइट-ऑन-बीजीसेव-एरर नंबर और स्लेव-सर्व-बासी-डेटा हां
  सक्षम होने पर, यदि आरडीबी स्नैपशॉट टूट जाता है, तो मास्टर परिवर्तन अनुरोध स्वीकार करना बंद कर देगा। यदि मास्टर से कनेक्शन टूट जाता है, तो दास अनुरोधों का जवाब देना जारी रख सकता है (हाँ)। या जवाब देना बंद कर देंगे (नहीं)
  हम उस स्थिति से खुश नहीं हैं जिसमें रेडिस कद्दू में बदल जाता है।
• उत्तर-पिंग-गुलाम-अवधि 5
  इस अवधि के बाद, हमें चिंता होने लगेगी कि मास्टर खराब हो गया है और फेलओवर प्रक्रिया को अंजाम देने का समय आ गया है।
  आपको झूठी सकारात्मकता और विफलता को ट्रिगर करने के बीच मैन्युअल रूप से संतुलन ढूंढना होगा। हमारे अभ्यास में यह 5 सेकंड है।
• उत्तर-बैकलॉग-आकार 1024एमबी और ईपीएल-बैकलॉग-टीटीएल 0
  हम एक असफल प्रतिकृति के लिए बफर में इतना ही डेटा संग्रहीत कर सकते हैं। यदि बफ़र ख़त्म हो जाता है, तो आपको पूरी तरह से सिंक्रनाइज़ करना होगा।
  अभ्यास से पता चलता है कि अधिक मूल्य निर्धारित करना बेहतर है। ऐसे बहुत से कारण हैं जिनकी वजह से एक प्रतिकृति पिछड़ने लगती है। यदि यह पिछड़ जाता है, तो सबसे अधिक संभावना है कि आपका मास्टर पहले से ही इससे निपटने के लिए संघर्ष कर रहा है, और पूर्ण सिंक्रनाइज़ेशन आखिरी तिनका होगा।
• अधिकतम ग्राहक 10000
  एकमुश्त ग्राहकों की अधिकतम संख्या.
  हमारे अनुभव में, अधिक मूल्य निर्धारित करना बेहतर है। रेडिस 10k कनेक्शन को ठीक से संभालता है। बस सुनिश्चित करें कि सिस्टम पर पर्याप्त सॉकेट हैं।
• मैक्समेमोरी-पॉलिसी वोलेटाइल-टीटीएल
  वह नियम जिसके द्वारा उपलब्ध मेमोरी सीमा पूरी होने पर कुंजियाँ हटा दी जाती हैं।
  यहां जो महत्वपूर्ण है वह स्वयं नियम नहीं है, बल्कि यह कैसे होगा इसकी समझ है। मेमोरी सीमा पूरी होने पर सामान्य रूप से काम करने की क्षमता के लिए रेडिस की प्रशंसा की जा सकती है।

आरडीबी और एओएफ समस्याएं

हालाँकि Redis स्वयं सभी सूचनाओं को RAM में संग्रहीत करता है, डेटा को डिस्क में सहेजने के लिए एक तंत्र भी है। अधिक सटीक रूप से, तीन तंत्र:

• आरडीबी-स्नैपशॉट - सभी डेटा का एक पूरा स्नैपशॉट। SAVE XY कॉन्फ़िगरेशन का उपयोग करके सेट करें और पढ़ें "यदि कम से कम Y कुंजियाँ बदल गई हैं तो प्रत्येक X सेकंड में सभी डेटा का पूरा स्नैपशॉट सहेजें।"
• केवल-संलग्न फ़ाइल - किए जाने वाले क्रम में कार्यों की एक सूची। प्रत्येक X सेकंड या प्रत्येक Y ऑपरेशन में फ़ाइल में नए आने वाले ऑपरेशन जोड़ता है।
• आरडीबी और एओएफ पिछले दो का संयोजन हैं।

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

सबसे पहले, RDB स्नैपशॉट को सहेजने के लिए FORK को कॉल करना आवश्यक है। यदि बहुत अधिक डेटा है, तो यह सभी रेडिस को कुछ मिलीसेकंड से एक सेकंड की अवधि के लिए लटका सकता है। इसके अलावा, सिस्टम को ऐसे स्नैपशॉट के लिए मेमोरी आवंटित करने की आवश्यकता होती है, जिससे लॉजिकल मशीन पर रैम की दोहरी आपूर्ति रखने की आवश्यकता होती है: यदि रेडिस के लिए 8 जीबी आवंटित किया जाता है, तो वर्चुअल मशीन पर 16 जीबी उपलब्ध होना चाहिए यह।

दूसरे, आंशिक सिंक्रनाइज़ेशन में समस्याएँ हैं। एओएफ मोड में, जब स्लेव को दोबारा कनेक्ट किया जाता है, तो आंशिक सिंक्रोनाइज़ेशन के बजाय, पूर्ण सिंक्रोनाइज़ेशन किया जा सकता है। ऐसा क्यों होता है, मैं समझ नहीं पाया. लेकिन यह याद रखने लायक है.

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

निष्कर्ष

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

स्रोत: www.habr.com