एका दशकाहून अधिक काळ विकसित होत असलेल्या उत्पादनाकडे येत असताना, त्यात कालबाह्य तंत्रज्ञान शोधणे अजिबात आश्चर्यकारक नाही. परंतु सहा महिन्यांत तुम्हाला 10 पट जास्त भार ठेवावा लागला आणि फॉल्सची किंमत शेकडो पटीने वाढली तर काय? या प्रकरणात, आपल्याला थंड हायलोड अभियंता आवश्यक आहे. पण मोलकरीण नसताना त्यांनी माझ्यावर प्रश्न सोडवण्याची जबाबदारी सोपवली. लेखाच्या पहिल्या भागात मी तुम्हाला सांगेन की आम्ही रेडिसमधून रेडिस-क्लस्टरमध्ये कसे गेलो आणि दुसऱ्या भागात मी क्लस्टर वापरणे कसे सुरू करावे आणि ते वापरताना काय लक्ष द्यावे याबद्दल सल्ला देईन.

तंत्रज्ञानाची निवड

ते वाईट आहे का? स्वतंत्र रेडिस (स्टँडअलोन रेडिस) 1 मास्टर आणि एन स्लेव्हच्या कॉन्फिगरेशनमध्ये? मी त्याला अप्रचलित तंत्रज्ञान का म्हणू?

नाही, रेडिस इतके वाईट नाही... तथापि, काही कमतरता आहेत ज्याकडे दुर्लक्ष केले जाऊ शकत नाही.

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

• दुसरे म्हणजे, फक्त एक मास्टर असल्यामुळे शार्डिंगची समस्या उद्भवली. आम्हाला "1 मास्टर आणि एन स्लेव्ह" असे अनेक स्वतंत्र क्लस्टर तयार करावे लागले, त्यानंतर या मशीन्समध्ये डेटाबेसेस व्यक्तिचलितपणे वितरीत करा आणि आशा करा की उद्या डेटाबेसपैकी एक एवढा वाढणार नाही की त्याला वेगळ्या उदाहरणावर हलवावे लागेल.

पर्याय काय आहेत?

• सर्वात महाग आणि श्रीमंत उपाय म्हणजे रेडिस-एंटरप्राइज. हे संपूर्ण तांत्रिक समर्थनासह बॉक्स केलेले समाधान आहे. तांत्रिक दृष्टिकोनातून ते आदर्श दिसत असूनही, वैचारिक कारणांमुळे ते आम्हाला अनुकूल नव्हते.
• रेडिस-क्लस्टर. बॉक्सच्या बाहेर मास्टर फेलओव्हर आणि शार्डिंगसाठी समर्थन आहे. इंटरफेस नियमित आवृत्तीपेक्षा जवळजवळ भिन्न नाही. हे आश्वासक दिसत आहे, आम्ही नंतर तोट्यांबद्दल बोलू.
• Tarantool, Memcache, Aerospike आणि इतर. ही सर्व साधने जवळजवळ समान गोष्ट करतात. परंतु प्रत्येकाची स्वतःची कमतरता आहे. आम्ही आमची सर्व अंडी एका टोपलीत न ठेवण्याचा निर्णय घेतला. आम्ही इतर कामांसाठी Memcache आणि Tarantool वापरतो, आणि पुढे पाहताना, मी म्हणेन की आमच्या सरावात त्यांच्याबरोबर अधिक समस्या होत्या.

वापराची वैशिष्ट्ये

रेडिससह आम्ही ऐतिहासिकदृष्ट्या कोणत्या समस्यांचे निराकरण केले आहे आणि आम्ही कोणती कार्यक्षमता वापरली आहे यावर एक नजर टाकूया:

• 2GIS सारख्या रिमोट सेवांच्या विनंतीपूर्वी कॅशे | गोलंग
  

  MGET MSET "सिलेक्ट डीबी" मिळवा

• MYSQL आधी कॅशे | PHP
  

  सेट करा एमजीईटी एमएसईटी स्कॅन "की बाय पॅटर्न" "डीबी निवडा"

• सत्र आणि ड्रायव्हर निर्देशांकांसह कार्य करण्याच्या सेवेसाठी मुख्य स्टोरेज | गोलंग
  

  एमजीईटी एमएसईटी सेट करा "डीबी निवडा" "जियो की जोडा" "जियो की मिळवा" स्कॅन करा

जसे आपण पाहू शकता, उच्च गणित नाही. मग अडचण काय आहे? चला प्रत्येक पद्धतीचा स्वतंत्रपणे विचार करूया.

पद्धत
वर्णन
रेडिस-क्लस्टरची वैशिष्ट्ये
निर्णय

सेट मिळवा
की लिहा/वाचा

एमजीईटी एमएसईटी
एकाधिक की लिहा/वाचा
की वेगवेगळ्या नोड्सवर असतील. रेडीमेड लायब्ररी केवळ एका नोडमध्ये मल्टी-ऑपरेशन करू शकतात
MGET ला N GET ऑपरेशन्सच्या पाइपलाइनने बदला

DB निवडा
आम्ही ज्या बेसवर काम करू तो निवडा
एकाधिक डेटाबेसला समर्थन देत नाही
सर्वकाही एका डेटाबेसमध्ये ठेवा. की मध्ये उपसर्ग जोडा

स्कॅन
डेटाबेसमधील सर्व की द्वारे जा
आमच्याकडे एक डेटाबेस असल्याने, क्लस्टरमधील सर्व की मधून जाणे खूप महाग आहे
एका कीमध्ये अपरिवर्तनीय ठेवा आणि या कीवर HSCAN करा. किंवा पूर्णपणे नकार द्या

जीईओ
जिओकीसह ऑपरेशन्स
जिओकी शार्ड केलेला नाही

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

रेडिस वि रेडिस-क्लस्टर

क्लस्टरवर स्विच करताना आपण काय गमावतो आणि काय मिळवतो?

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

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

हलवण्याची तयारी करत आहे

चला हलविण्याच्या आवश्यकतांसह प्रारंभ करूया:

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

क्लस्टर देखभाल

हलवण्यापूर्वी, आम्ही क्लस्टरला समर्थन देऊ शकतो की नाही याचा विचार केला पाहिजे:

• तक्ते. आम्ही CPU लोड, मेमरी वापर, क्लायंटची संख्या, GET, SET, AUTH ऑपरेशन्स इत्यादींचा आलेख करण्यासाठी प्रोमिथियस आणि ग्राफाना वापरतो.
• निपुणता. कल्पना करा की उद्या तुमच्या जबाबदारीखाली एक मोठा क्लस्टर असेल. जर ते तुटले, तर तुम्ही ते दुरुस्त करू शकत नाही. जर तो कमी होऊ लागला तर प्रत्येकजण तुमच्याकडे धावेल. तुम्हाला संसाधने जोडायची किंवा लोडचे पुनर्वितरण करायचे असल्यास, तुमच्याकडे परत या. 25 व्या वर्षी राखाडी होऊ नये म्हणून, या प्रकरणांची तरतूद करणे आणि विशिष्ट कृती अंतर्गत तंत्रज्ञान कसे वागेल हे आगाऊ तपासणे उचित आहे. चला याबद्दल अधिक तपशीलवार "तज्ञ" विभागात बोलूया.
• देखरेख आणि सूचना. जेव्हा एखादे क्लस्टर खंडित होते, तेव्हा तुम्हाला त्याबद्दल प्रथम जाणून घ्यायचे असते. येथे आम्ही स्वतःला एका सूचनेपुरते मर्यादित केले आहे की सर्व नोड्स क्लस्टरच्या स्थितीबद्दल समान माहिती परत करतात (होय, ते वेगळ्या प्रकारे होते). आणि इतर समस्या रेडिस क्लायंट सेवांकडून अलर्टद्वारे अधिक त्वरीत लक्षात येऊ शकतात.

पुनर्वास

आम्ही कसे हलवू:

• सर्व प्रथम, आपल्याला क्लस्टरसह कार्य करण्यासाठी लायब्ररी तयार करणे आवश्यक आहे. आम्ही गो आवृत्तीसाठी आधार म्हणून गो-रेडीस घेतले आणि स्वतःला अनुरूप असे थोडेसे बदलले. आम्ही पाइपलाइनद्वारे बहु-पद्धती लागू केल्या आणि विनंत्या पुनरावृत्ती करण्याच्या नियमांमध्ये किंचित सुधारणा केली. PHP आवृत्तीमध्ये अधिक समस्या होत्या, परंतु आम्ही अखेरीस php-redis वर सेटल झालो. त्यांनी अलीकडेच क्लस्टर सपोर्ट सादर केला आणि आमच्या मते ते चांगले दिसते.
• पुढे तुम्हाला क्लस्टर स्वतः तैनात करणे आवश्यक आहे. हे कॉन्फिगरेशन फाइलवर आधारित दोन कमांडमध्ये अक्षरशः केले जाते. आम्ही खाली सेटिंगबद्दल अधिक तपशीलवार चर्चा करू.
• हळूहळू हलविण्यासाठी आम्ही ड्राय-मोड वापरतो. आमच्याकडे एकाच इंटरफेससह लायब्ररीच्या दोन आवृत्त्या असल्याने (एक नियमित आवृत्तीसाठी, दुसरी क्लस्टरसाठी), वेगळ्या आवृत्तीसह कार्य करेल असे रॅपर तयार करण्यासाठी आणि क्लस्टरच्या सर्व विनंत्या समांतर डुप्लिकेट करण्यासाठी, यासाठी काहीही खर्च येत नाही. प्रतिसादांची तुलना करा आणि नोंदींमध्ये विसंगती लिहा (आमच्या बाबतीत न्यूरेलिकमध्ये). अशा प्रकारे, रोलआउट दरम्यान क्लस्टर आवृत्ती खंडित झाली तरीही, आमच्या उत्पादनावर परिणाम होणार नाही.
• क्लस्टर ड्राय मोडमध्ये आणल्यानंतर, आम्ही शांतपणे प्रतिसादातील विसंगतींचा आलेख पाहू शकतो. जर त्रुटी दर हळूहळू परंतु निश्चितपणे काही लहान स्थिरांकाकडे सरकत असेल तर सर्वकाही ठीक आहे. अजूनही विसंगती का आहेत? कारण वेगळ्या आवृत्तीमध्ये रेकॉर्डिंग क्लस्टरच्या तुलनेत थोडे आधी होते आणि मायक्रोलॅगमुळे, डेटा भिन्न होऊ शकतो. फक्त विसंगती नोंदी पाहणे बाकी आहे आणि जर ते सर्व रेकॉर्डच्या गैर-अणुत्वाद्वारे स्पष्ट केले गेले तर आपण पुढे जाऊ शकतो.
• आता तुम्ही ड्राय मोड विरुद्ध दिशेने स्विच करू शकता. आम्ही क्लस्टरमधून लिहू आणि वाचू आणि वेगळ्या आवृत्तीमध्ये डुप्लिकेट करू. कशासाठी? पुढील आठवड्यात मला क्लस्टरच्या कामाचे निरीक्षण करायचे आहे. जर अचानक असे दिसून आले की पीक लोडमध्ये समस्या आहेत किंवा आम्ही काही विचारात घेतले नाही, तर आमच्याकडे नेहमी जुन्या कोडवर आणीबाणीचा रोलबॅक आणि ड्राय-मोडमुळे वर्तमान डेटा असतो.
• ड्राय-मोड अक्षम करणे आणि स्वतंत्र आवृत्ती काढून टाकणे बाकी आहे.

निपुणता

प्रथम, क्लस्टर डिझाइनबद्दल थोडक्यात.

सर्व प्रथम, रेडिस हे की-व्हॅल्यू स्टोअर आहे. अनियंत्रित स्ट्रिंग की म्हणून वापरल्या जातात. संख्या, स्ट्रिंग आणि संपूर्ण संरचना मूल्ये म्हणून वापरली जाऊ शकतात. नंतरचे बरेच आहेत, परंतु सामान्य रचना समजून घेण्यासाठी हे आपल्यासाठी महत्त्वाचे नाही.
की नंतर अॅब्स्ट्रॅक्शनची पुढील पातळी स्लॉट्स (SLOTS) आहे. प्रत्येक की 16 स्लॉटपैकी एकाशी संबंधित आहे. प्रत्येक स्लॉटमध्ये कितीही की असू शकतात. अशा प्रकारे, सर्व की 383 डिसजॉइंट सेटमध्ये विभागल्या जातात.

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

सर्व की स्लॉट्समध्ये वितरीत केल्यानंतर आणि स्लॉट मास्टर नोड्समध्ये विखुरल्यानंतर, प्रत्येक मास्टर नोडमध्ये स्लेव्ह नोड्सची अनियंत्रित संख्या जोडली जाऊ शकते. अशा प्रत्येक मास्टर-स्लेव्ह लिंकमध्ये, सामान्य प्रतिकृती कार्य करेल. वाचन विनंत्या मोजण्यासाठी आणि मास्टर अयशस्वी झाल्यास फेलओव्हरसाठी स्लेव्ह्स आवश्यक आहेत.

आता ऑपरेशन्सबद्दल बोलूया जे करण्यास सक्षम असणे चांगले होईल.

आम्ही Redis-CLI द्वारे प्रणालीमध्ये प्रवेश करू. Redis मध्ये एकच एंट्री पॉइंट नसल्यामुळे, तुम्ही कोणत्याही नोड्सवर खालील ऑपरेशन्स करू शकता. प्रत्येक टप्प्यावर मी लोड अंतर्गत ऑपरेशन करण्याच्या शक्यतेकडे स्वतंत्रपणे लक्ष वेधतो.

• आपल्याला आवश्यक असलेली पहिली आणि सर्वात महत्वाची गोष्ट म्हणजे क्लस्टर नोड्स ऑपरेशन. हे क्लस्टरची स्थिती परत करते, नोड्सची सूची, त्यांची भूमिका, स्लॉट वितरण इ. दाखवते. क्लस्टर माहिती आणि क्लस्टर स्लॉट वापरून अधिक माहिती मिळवता येते.
• नोड्स जोडण्यास आणि काढण्यास सक्षम असणे चांगले होईल. या उद्देशासाठी क्लस्टर मीट आणि क्लस्टर विसरणे ऑपरेशन्स आहेत. कृपया लक्षात ठेवा की क्लस्टर विसरणे प्रत्येक नोडवर लागू करणे आवश्यक आहे, दोन्ही मास्टर्स आणि प्रतिकृती. आणि क्लस्टर मीट फक्त एका नोडवर कॉल करणे आवश्यक आहे. हा फरक अस्वस्थ करणारा असू शकतो, त्यामुळे तुम्ही तुमच्या क्लस्टरसह थेट जाण्यापूर्वी त्याबद्दल जाणून घेणे उत्तम. नोड जोडणे युद्धात सुरक्षितपणे केले जाते आणि कोणत्याही प्रकारे क्लस्टरच्या ऑपरेशनवर परिणाम करत नाही (जे तार्किक आहे). जर तुम्ही क्लस्टरमधून नोड काढणार असाल, तर तुम्ही खात्री करून घ्या की त्यावर कोणतेही स्लॉट शिल्लक नाहीत (अन्यथा तुम्हाला या नोडवरील सर्व कीचा प्रवेश गमावण्याचा धोका आहे). तसेच, गुलाम असलेल्या मालकाला हटवू नका, अन्यथा नवीन मालकासाठी अनावश्यक मत दिले जाईल. जर नोड्समध्ये यापुढे स्लॉट नसतील, तर ही एक छोटी समस्या आहे, परंतु जर आपण प्रथम स्लेव्ह हटवू शकलो तर आम्हाला अतिरिक्त पर्यायांची आवश्यकता का आहे.
• तुम्हाला मास्टर आणि स्लेव्ह पोझिशन्स जबरदस्तीने स्वॅप करायचे असल्यास, क्लस्टर फेलओव्हर कमांड करेल. युद्धात कॉल करताना, आपल्याला हे समजून घेणे आवश्यक आहे की ऑपरेशन दरम्यान मास्टर उपलब्ध होणार नाही. सामान्यत: स्विच एका सेकंदापेक्षा कमी वेळात होतो, परंतु अणू नसतो. आपण अपेक्षा करू शकता की या काळात मास्टरला काही विनंत्या अयशस्वी होतील.
• क्लस्टरमधून नोड काढण्यापूर्वी, त्यावर कोणतेही स्लॉट शिल्लक नसावेत. क्लस्टर reshard कमांड वापरून त्यांचे पुनर्वितरण करणे चांगले आहे. स्लॉट एका मास्टरकडून दुसऱ्या मास्टरकडे हस्तांतरित केले जातील. संपूर्ण ऑपरेशनला काही मिनिटे लागू शकतात, ते हस्तांतरित केल्या जाणार्‍या डेटाच्या व्हॉल्यूमवर अवलंबून असते, परंतु हस्तांतरण प्रक्रिया सुरक्षित आहे आणि क्लस्टरच्या ऑपरेशनवर कोणत्याही प्रकारे परिणाम करत नाही. अशा प्रकारे, सर्व डेटा एका नोडमधून थेट लोड अंतर्गत आणि त्याच्या उपलब्धतेबद्दल चिंता न करता हस्तांतरित केला जाऊ शकतो. तथापि, सूक्ष्मता देखील आहेत. प्रथम, डेटा ट्रान्सफर प्राप्तकर्ता आणि प्रेषक नोड्सवरील विशिष्ट लोडशी संबंधित आहे. जर प्राप्तकर्ता नोड आधीच प्रोसेसरवर खूप लोड झाला असेल, तर तुम्ही नवीन डेटा प्राप्त करून तो लोड करू नये. दुसरे म्हणजे, पाठवणाऱ्या मास्टरवर एकही स्लॉट शिल्लक नसल्यामुळे, त्याचे सर्व गुलाम ताबडतोब ज्या मास्टरकडे हे स्लॉट हस्तांतरित केले गेले होते त्याच्याकडे जातील. आणि समस्या अशी आहे की हे सर्व गुलाम एकाच वेळी डेटा सिंक्रोनाइझ करू इच्छितात. आणि पूर्ण सिंक्रोनाइझेशन ऐवजी आंशिक असल्यास आपण भाग्यवान असाल. हे विचारात घ्या आणि स्लॅट्सचे हस्तांतरण आणि गुलामांना अक्षम/हस्तांतरित करण्याच्या ऑपरेशन्स एकत्र करा. किंवा आशा आहे की तुमच्याकडे सुरक्षिततेचे पुरेसे मार्जिन आहे.
• हस्तांतरणादरम्यान, आपण कुठेतरी आपले स्लॉट गमावले असल्याचे आपल्याला आढळल्यास आपण काय करावे? मला आशा आहे की या समस्येचा तुमच्यावर परिणाम होणार नाही, परंतु असे झाल्यास, क्लस्टर फिक्स ऑपरेशन आहे. कमीतकमी, ती यादृच्छिक क्रमाने नोड्सवर स्लॉट विखुरेल. मी प्रथम क्लस्टरमधून वितरित स्लॉटसह नोड काढून त्याचे ऑपरेशन तपासण्याची शिफारस करतो. वाटप न केलेल्या स्लॉटमधील डेटा आधीपासूनच अनुपलब्ध असल्याने, या स्लॉटच्या उपलब्धतेसह समस्यांबद्दल काळजी करण्यास उशीर झाला आहे. या बदल्यात, ऑपरेशन वितरित स्लॉटवर परिणाम करणार नाही.
• आणखी एक उपयुक्त ऑपरेशन मॉनिटर आहे. हे तुम्हाला नोडवर जाणाऱ्या विनंत्यांची संपूर्ण यादी रिअल टाइममध्ये पाहण्याची परवानगी देते. शिवाय, आपण ते शोधू शकता आणि आवश्यक रहदारी आहे का ते शोधू शकता.

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

कॉन्फिगरेशन

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

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

RDB आणि AOF समस्या

जरी रेडिस स्वतः सर्व माहिती RAM मध्ये संग्रहित करते, परंतु डिस्कवर डेटा जतन करण्याची एक यंत्रणा देखील आहे. अधिक तंतोतंत, तीन यंत्रणा:

• RDB-स्नॅपशॉट - सर्व डेटाचा संपूर्ण स्नॅपशॉट. सेव्ह XY कॉन्फिगरेशन वापरून सेट करा आणि "किमान Y की बदलल्या असल्यास प्रत्येक X सेकंदांनी सर्व डेटाचा संपूर्ण स्नॅपशॉट जतन करा" असे वाचले.
• फक्त-जोडलेली फाइल - ऑपरेशन्सची सूची ज्या क्रमाने केली जाते. प्रत्येक X सेकंद किंवा प्रत्येक Y ऑपरेशन्स फाइलमध्ये नवीन इनकमिंग ऑपरेशन्स जोडते.
• RDB आणि AOF हे मागील दोनचे संयोजन आहे.

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

प्रथम, RDB स्नॅपशॉट सेव्ह करण्यासाठी FORK ला कॉल करणे आवश्यक आहे. भरपूर डेटा असल्यास, हे काही मिलिसेकंद ते एका सेकंदाच्या कालावधीसाठी सर्व Redis हँग करू शकते. याव्यतिरिक्त, अशा स्नॅपशॉटसाठी सिस्टमला मेमरी वाटप करणे आवश्यक आहे, ज्यामुळे लॉजिकल मशीनवर रॅमचा दुहेरी पुरवठा ठेवणे आवश्यक आहे: जर रेडिससाठी 8 जीबी वाटप केले असेल, तर व्हर्च्युअल मशीनवर 16 जीबी उपलब्ध असणे आवश्यक आहे. ते

दुसरे म्हणजे, आंशिक सिंक्रोनाइझेशनमध्ये समस्या आहेत. AOF मोडमध्ये, जेव्हा स्लेव्ह पुन्हा कनेक्ट केला जातो, तेव्हा आंशिक सिंक्रोनाइझेशनऐवजी, पूर्ण सिंक्रोनाइझेशन केले जाऊ शकते. असे का होते, मला समजले नाही. पण हे लक्षात ठेवण्यासारखे आहे.

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

निष्कर्ष

शेवटी, मला आशा आहे की ज्यांनी हे ऐकले नाही त्यांच्यासाठी रेडिस-क्लस्टर कसे कार्य करते याबद्दल मी सामान्य कल्पना देऊ शकलो आणि जे वापरत आहेत त्यांच्यासाठी काही गैर-स्पष्ट मुद्द्यांकडे लक्ष वेधले. बर्याच काळासाठी.
आपल्या वेळेबद्दल धन्यवाद आणि, नेहमीप्रमाणे, विषयावरील टिप्पण्यांचे स्वागत आहे.

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