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

प्रविधि चयन

के यो खराब छ? अलग Redis (स्ट्यान्डअलोन रेडिस) १ मास्टर र एन दासहरूको कन्फिगरेसनमा? यसलाई अप्रचलित प्रविधि किन भनौँ ?

होइन, रेडिस त्यति नराम्रो होइन... यद्यपि, त्यहाँ केही कमजोरीहरू छन् जुन बेवास्ता गर्न सकिँदैन।

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

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

के विकल्पहरू छन्?

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

प्रयोगको विशिष्टताहरू

हामीले ऐतिहासिक रूपमा रेडिससँग कुन समस्याहरू समाधान गरेका छौं र हामीले कुन कार्यक्षमता प्रयोग गर्यौं भनेर हेरौं:

• 2GIS | जस्तै रिमोट सेवाहरूको अनुरोध अघि क्यास गोलाङ
  

  GET SET MGET MSET "SELECT DB" प्राप्त गर्नुहोस्

• MYSQL अघि क्यास | PHP
  

  GET SET MGET MSET SCAN "KY BY PATTERN" "DB चयन गर्नुहोस्"

• सत्र र चालक समन्वय संग काम को सेवा को लागि मुख्य भण्डारण | गोलाङ
  

  MGET MSET सेट गर्नुहोस् "DB चयन गर्नुहोस्" "जियो कुञ्जी थप्नुहोस्" "जियो कुञ्जी प्राप्त गर्नुहोस्" स्क्यान गर्नुहोस्

तपाईले देख्न सक्नुहुन्छ, उच्च गणित छैन। त्यसो भए अप्ठ्यारो के छ ? प्रत्येक विधिलाई अलग-अलग हेरौं।

विधि
विवरण
Redis-क्लस्टर को विशेषताहरु
निर्णय

सेट गर्नुहोस्
कुञ्जी लेख्नुहोस्/पढ्नुहोस्

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

DB चयन गर्नुहोस्
हामीले काम गर्ने आधार छान्नुहोस्
धेरै डाटाबेस समर्थन गर्दैन
सबै एक डाटाबेस मा राख्नुहोस्। कुञ्जीहरूमा उपसर्गहरू थप्नुहोस्

स्क्यान
डाटाबेसमा सबै कुञ्जीहरू मार्फत जानुहोस्
हामीसँग एउटा डाटाबेस भएकोले, क्लस्टरका सबै कुञ्जीहरू मार्फत जान धेरै महँगो छ
एउटा कुञ्जी भित्र अपरिवर्तनीय राख्नुहोस् र यो कुञ्जीमा HSCAN गर्नुहोस्। वा पूर्ण रूपमा अस्वीकार गर्नुहोस्

भू
geokey संग सञ्चालन
geokey sharded छैन

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

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

क्लस्टरमा स्विच गर्दा हामीले के गुमाउँछौं र के प्राप्त गर्छौं?

• बेफाइदाहरू: हामीले धेरै डाटाबेसहरूको कार्यक्षमता गुमाउँछौं।
  • यदि हामी तार्किक रूपमा असंबंधित डाटा एक क्लस्टरमा भण्डारण गर्न चाहन्छौं भने, हामीले उपसर्गको रूपमा क्रचहरू बनाउनु पर्छ।
  • हामीले स्क्यान, DBSIZE, CLEAR DB, आदि जस्ता सबै "आधार" सञ्चालनहरू गुमाउँछौं।
  • बहु-अपरेसनहरू लागू गर्न धेरै गाह्रो भएको छ किनभने यसलाई धेरै नोडहरूमा पहुँच आवश्यक हुन सक्छ।
• प्लस:
  • मास्टर फेलओभरको रूपमा दोष सहिष्णुता।
  • Redis छेउमा Sharding।
  • परमाणु र डाउनटाइम बिना नोडहरू बीच डाटा स्थानान्तरण।
  • डाउनटाइम बिना क्षमता र लोडहरू थप्नुहोस् र पुन: वितरण गर्नुहोस्।

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

सार्ने तयारी गर्दै

सार्नका लागि आवश्यकताहरूसँग सुरु गरौं:

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

क्लस्टर मर्मत

चाल गर्नु अघि, हामीले क्लस्टरलाई समर्थन गर्न सक्छौं कि भनेर सोच्नु पर्छ:

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

पुनर्वास

हामी कसरी सार्नेछौं:

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

विशेषज्ञता

पहिले, क्लस्टर डिजाइनको बारेमा छोटकरीमा।

सबै भन्दा पहिले, Redis एक प्रमुख-मूल्य स्टोर हो। आर्बिट्ररी स्ट्रिङहरू कुञ्जीहरूको रूपमा प्रयोग गरिन्छ। संख्याहरू, तारहरू, र सम्पूर्ण संरचनाहरू मानहरूको रूपमा प्रयोग गर्न सकिन्छ। त्यहाँ पछिल्ला धेरै छन्, तर सामान्य संरचना बुझ्नको लागि यो हाम्रो लागि महत्त्वपूर्ण छैन।
कुञ्जीहरू पछि सार्ने अर्को स्तर स्लटहरू (SLOTS) हो। प्रत्येक कुञ्जी 16 स्लटहरू मध्ये एकसँग सम्बन्धित छ। प्रत्येक स्लट भित्र कुञ्जीहरूको कुनै पनि संख्या हुन सक्छ। यसरी, सबै कुञ्जीहरू 383 विच्छेदन सेटहरूमा विभाजित छन्।

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

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

अब सञ्चालनको कुरा गरौं कि यो गर्न सक्षम हुनु राम्रो हुनेछ।

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

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

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

कन्फिगरेसन

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

• टाइमआउट १०
  निष्क्रिय जडानहरू बन्द हुने समय (सेकेन्डमा)। 0 - बन्द नगर्नुहोस्
  हाम्रो प्रत्येक पुस्तकालयले सही रूपमा जडानहरू बन्द गर्न सक्षम थिएन। यो सेटिङ असक्षम गरेर, हामी ग्राहकहरूको संख्याको सीमामा पुग्ने जोखिममा छौं। अर्कोतर्फ, यदि यस्तो समस्या छ भने, हराएको जडानको स्वचालित समाप्तिले यसलाई मास्क गर्नेछ, र हामीले याद नगर्न सक्छौं। थप रूपमा, तपाईंले निरन्तर जडानहरू प्रयोग गर्दा यो सेटिङ सक्षम गर्नु हुँदैन।
• xy बचत गर्नुहोस् र हो जोड्नुहोस्
  RDB स्न्यापसट बचत गर्दै।
  हामी तल विस्तृत रूपमा RDB/AOF मुद्दाहरू छलफल गर्नेछौं।
• stop-writes-on-bgsave-त्रुटि होइन र दास-सेवा-बासी-डेटा हो
  यदि सक्षम पारियो भने, यदि RDB स्न्यापसट ब्रेक भयो भने, मास्टरले परिवर्तन अनुरोधहरू स्वीकार गर्न बन्द गर्नेछ। यदि मालिकसँग जडान हराएको छ भने, दासले अनुरोधहरूको जवाफ दिन जारी राख्न सक्छ (हो)। वा प्रतिक्रिया दिन बन्द हुनेछ (होइन)
  रेडिस कद्दूमा परिणत भएको अवस्थामा हामी खुसी छैनौं।
• repl-ping-slave-period 5
  समयको यस अवधि पछि, हामी चिन्ता गर्न थाल्छौं कि मास्टर टुटेको छ र यो फेलओभर प्रक्रिया पूरा गर्ने समय हो।
  तपाईंले म्यानुअल रूपमा गलत सकारात्मक र असफलता ट्रिगर गर्ने बीच सन्तुलन खोज्नुपर्छ। हाम्रो अभ्यासमा यो 5 सेकेन्ड हो।
• repl-backlog-size 1024mb र epl-backlog-ttl ०
  हामी असफल प्रतिकृतिको लागि बफरमा यति धेरै डाटा भण्डारण गर्न सक्छौं। यदि बफर सकियो भने, तपाईंले पूर्ण रूपमा सिङ्क्रोनाइज गर्नुपर्नेछ।
  अभ्यासले सुझाव दिन्छ कि यो उच्च मूल्य सेट गर्न राम्रो छ। त्यहाँ धेरै कारणहरू छन् किन एक प्रतिकृति ढिलो हुन सक्छ। यदि यो ढिलो भयो भने, सम्भवतः तपाइँको मालिक पहिले नै सामना गर्न संघर्ष गर्दै हुनुहुन्छ, र पूर्ण सिंक्रोनाइजेसन अन्तिम स्ट्रा हुनेछ।
• अधिकतम 10000
  एक पटकका ग्राहकहरूको अधिकतम संख्या।
  हाम्रो अनुभव मा, यो एक उच्च मूल्य सेट गर्न राम्रो छ। Redis ले 10k जडानहरू राम्रोसँग ह्यान्डल गर्दछ। केवल सुनिश्चित गर्नुहोस् कि प्रणालीमा पर्याप्त सकेटहरू छन्।
• maxmemory-policy volatile-ttl
  उपलब्ध मेमोरी सीमा पुग्दा कुञ्जीहरू मेटिने नियम।
  यहाँ के महत्त्वपूर्ण छ नियम आफैंमा होइन, तर यो कसरी हुन्छ भन्ने बुझाइ हो। मेमोरी सीमा पुग्दा सामान्य रूपमा काम गर्ने क्षमताको लागि रेडिसको प्रशंसा गर्न सकिन्छ।

RDB र AOF समस्याहरू

यद्यपि Redis आफैंले RAM मा सबै जानकारी भण्डारण गर्दछ, त्यहाँ डिस्कमा डाटा बचत गर्ने एक संयन्त्र पनि छ। थप स्पष्ट रूपमा, तीन संयन्त्रहरू:

• RDB-स्न्यापसट - सबै डेटाको पूर्ण स्न्यापसट। SAVE XY कन्फिगरेसन प्रयोग गरेर सेट गर्नुहोस् र "कम्तीमा Y कुञ्जीहरू परिवर्तन भएमा प्रत्येक X सेकेन्डमा सबै डेटाको पूर्ण स्न्यापसट बचत गर्नुहोस्।"
• संलग्न-मात्र फाइल - कार्यहरूको सूची तिनीहरूले प्रदर्शन गरेका छन्। फाइलमा प्रत्येक X सेकेन्ड वा प्रत्येक Y अपरेसनहरूमा नयाँ आगमन कार्यहरू थप्छ।
• RDB र AOF अघिल्लो दुई को संयोजन हो।

सबै विधिहरूसँग तिनीहरूको फाइदा र बेफाइदाहरू छन्, म ती सबैलाई सूचीबद्ध गर्नेछैन, म केवल बिन्दुहरूमा ध्यान आकर्षित गर्नेछु जुन मेरो विचारमा, स्पष्ट छैन।

पहिलो, RDB स्न्यापसट बचत गर्न फोर्कलाई कल गर्न आवश्यक छ। यदि त्यहाँ धेरै डेटा छ भने, यसले केहि मिलिसेकेन्ड देखि एक सेकेन्डको अवधिको लागि सबै Redis ह्याङ्ग गर्न सक्छ। थप रूपमा, प्रणालीले यस्तो स्न्यापसटको लागि मेमोरी आवंटित गर्न आवश्यक छ, जसले तार्किक मेसिनमा RAM को दोहोरो आपूर्ति राख्न आवश्यक हुन्छ: यदि 8 GB Redis को लागि आवंटित गरिएको छ भने, 16 GB भर्चुअल मेसिनमा उपलब्ध हुनुपर्छ। यो।

दोस्रो, आंशिक सिंक्रोनाइजेसनमा समस्याहरू छन्। AOF मोडमा, जब दास पुन: जडान हुन्छ, आंशिक सिंक्रोनाइजेसनको सट्टा, पूर्ण सिंक्रोनाइजेसन गर्न सकिन्छ। यो किन हुन्छ, मैले बुझ्न सकिन। तर यो सम्झना लायक छ।

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

निष्कर्षमा

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

स्रोत: www.habr.com