🧤 ⛑️ 🤽🏿 भंडारण विफलता प्रदान करना 🈯️ 🕊️ 🚵🏻

सभी को नमस्कार! हाल ही में, एक खुला वेबिनार "प्रदान करने वाला दोष-सहिष्णु भंडारण" आयोजित किया गया था । इसने जांच की कि आर्किटेक्चर के डिजाइन में क्या समस्याएं हैं, सर्वर फेल होने का कारण सर्वर का खराब होना और डाउनटाइम को कम से कम कैसे करना है। वेबिनार की मेजबानी सिटीमोबिल में सर्वर डेवलपमेंट के प्रमुख इवान रेमेन और "हाई लोड आर्किटेक्ट" पाठ्यक्रम में एक शिक्षक ने की।

स्टोरेज रिसीबिलिटी से क्यों परेशान?

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

हम पढ़ने के लिए आधार के खिलाफ आराम करते हैं

यह पहला परिदृश्य है। कल्पना करें कि हमारे पास 1 सर्वर है, प्रोसेसर या हार्ड ड्राइव पर लोड 99% है। इस मामले में:

90% अनुरोधों को पढ़ा जाता है;
10% अनुरोध एक रिकॉर्ड है।

इस स्थिति में सबसे अच्छा समाधान प्रतिकृतियों के बारे में सोचना है। क्यों? यह सबसे सस्ता और आसान उपाय है।

प्रतिकृति वर्गीकृत किया गया है:

1. सिंक्रनाइज़ेशन द्वारा:

तुल्यकालिक;
अतुल्यकालिक;
semisynchronous।

2. पोर्टेबल डेटा के अनुसार:

तार्किक (पंक्ति-आधारित, कथन-आधारित, मिश्रित);
शारीरिक।

3. प्रति रिकॉर्ड नोड्स की संख्या से:

गुरु / दास;
गुरु / गुरु।

4. सर्जक द्वारा:

खींच;
धक्का।

और अब कार्य एक बाल्टी पानी के बारे में है । कल्पना कीजिए कि हमारे पास MySQL और अतुल्यकालिक मास्टर-दास प्रतिकृति है। डीसी में सफाई चल रही है, जिसके परिणामस्वरूप क्लीनर ठोकर खाता है और मास्टर बेस के साथ सर्वर पर एक बाल्टी पानी डालता है। स्वचालन सफलतापूर्वक नवीनतम स्लेव में से एक को मास्टर मोड में बदल देता है। और सब कुछ काम करना जारी रखता है। पकड़ कहां है?

उत्तर सरल है - हम उन लेनदेन को खो देते हैं जिन्हें हमने दोहराने के लिए प्रबंधित नहीं किया था। नतीजतन, एसीआईडी की संपत्ति डी का उल्लंघन किया जाता है।

अब बात करते हैं कि अतुल्यकालिक प्रतिकृति (MySQL) कैसे काम करती है:

भंडारण इंजन (InnoDB) में लेनदेन रिकॉर्ड करना;
बाइनरी लॉग में लेनदेन रिकॉर्ड करना;
भंडारण इंजन में लेनदेन पूरा करना;
ग्राहक के लिए वापसी की पुष्टि;
प्रतिकृति में लॉग का हिस्सा स्थानांतरित करना;
एक प्रतिकृति पर लेनदेन का निष्पादन (पृष्ठ 1-3)।

और अब सवाल यह है कि उपरोक्त पैराग्राफ में क्या बदलाव करने की जरूरत है ताकि हम प्रतिकृति के साथ कभी खत्म न हों?

और केवल दो बिंदुओं को परस्पर जोड़ने की आवश्यकता है: 4 वें और 5 वें स्थान पर ("लॉग का प्रतिकृति में भाग" और "ग्राहक को पुष्टि की वापसी")। इस प्रकार, यदि मास्टर नोड बाहर निकलता है, तो हमारे पास हमेशा कहीं न कहीं लेनदेन लॉग होगा (बिंदु 2)। और अगर लेन-देन बाइनरी लॉग में दर्ज किया गया है, तो लेनदेन भी कुछ समय में होगा।

परिणामस्वरूप, हमें अर्ध-तुल्यकालिक प्रतिकृति (MySQL) मिलती है, जो निम्नानुसार काम करती है:

भंडारण इंजन (InnoDB) में लेनदेन रिकॉर्ड करना;
बाइनरी लॉग में लेनदेन रिकॉर्ड करना;
भंडारण इंजन में लेनदेन पूरा करना;
प्रतिकृति में लॉग का हिस्सा स्थानांतरित करना;
ग्राहक के लिए वापसी की पुष्टि;
एक प्रतिकृति पर लेनदेन का निष्पादन (पृष्ठ 1-3)।

सेमी बनाम सिंक और एसिंक्स बनाम सेमी-सिंक

किसी कारण से, रूस में, अधिकांश लोगों ने अर्ध-तुल्यकालिक प्रतिकृति के बारे में नहीं सुना है। वैसे, यह PostgreSQL में अच्छी तरह से लागू है और MySQL में बहुत नहीं है। इसके बारे में यहाँ और अधिक पढ़ें, लेकिन थीसिस को इस प्रकार तैयार किया जा सकता है:

अर्ध-समकालिक प्रतिकृति अभी भी पीछे है (लेकिन उतनी नहीं) जितनी अतुल्यकालिक है;
हम लेन-देन नहीं खोते हैं;
यह केवल एक दास के लिए डेटा लाने के लिए पर्याप्त है।

वैसे, फेसबुक पर अर्ध-समकालिक प्रतिकृति का उपयोग किया जाता है।

हम रिकॉर्ड बेस के खिलाफ आराम करते हैं

जब हमारे पास एक विषम समस्या के बारे में बात करते हैं:

90% अनुरोध - रिकॉर्ड;
अनुरोधों का 10% पढ़ा जाता है;
1 सर्वर;
लोड - 99% (प्रोसेसर या हार्ड डिस्क)।

प्रसिद्ध बचाव यहाँ बचाव के लिए आता है। लेकिन अब कुछ और बात करते हैं:

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

वास्तव में, निम्नलिखित स्थितियों में मास्टर-मास्टर का उपयोग करना समझ में आता है:

लिखने के माध्यम से गलती सहिष्णुता (विचार यह है कि आप हमेशा केवल एक मास्टर को लिखते हैं)। आप वर्चुअल आईपी पते का उपयोग करके लागू कर सकते हैं;
भू-वितरित प्रणाली।

हालांकि, याद रखें कि मास्टर-मास्टर प्रतिकृति हमेशा मुश्किल होती है। और अक्सर मास्टर-मास्टर इसे हल करने की तुलना में अधिक समस्याएं लाता है।

sharding

हमने पहले ही शार्किंग का उल्लेख किया है। संक्षेप में, एक रिकॉर्ड करने के लिए पैनापन एक निश्चित-आग तरीका है। विचार यह है कि हम डेटा को स्वतंत्र (लेकिन हमेशा नहीं) सर्वरों में वितरित करते हैं। प्रत्येक शार्क स्वतंत्र रूप से दोहरा सकती है।

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

इसे प्रदर्शित करने के लिए, आइए कल्पना करें कि हमारे पास दो मान हैं जिनमें प्रत्येक में तीन मान हैं: (1; 2; 3) (0; 0; 500;)। औसत मान (1 + 2 + 3 + 500) / 6 = 84.33333 के बराबर होगा।

अब कल्पना करें कि हमारे पास दो स्वतंत्र सर्वर हैं। और प्रत्येक शार्क के लिए अलग से औसत मूल्य को पुनर्गणना करते हैं। उनमें से पहले पर हमें 2 मिलते हैं, दूसरे पर - 166.66667। और फिर भी अगर हम इन मूल्यों को औसत करते हैं, तो हमें अभी भी एक संख्या मिलेगी जो कि सही एक से भिन्न होगी: (2 + 166.66667) / 2 = 86.33334।

अर्थात्, साधनों का औसत हर चीज के औसत के बराबर नहीं है:

 avg(a, b, c, d) != avg(avg(a, b) + (avg(c, d))

सरल गणित, लेकिन यह याद रखना महत्वपूर्ण है।

साझा करने का कार्य

मान लीजिए कि हमारे पास एक सामाजिक नेटवर्क में एक संवाद प्रणाली है। एक संवाद में केवल 2 लोग हो सकते हैं। सभी संदेश एक तालिका में हैं, जिसमें है:

मैसेज आई.डी.
प्रेषक आईडी
प्राप्तकर्ता आईडी
संदेश पाठ;
संदेश भेजा गया था;
कुछ झंडे।

इस तथ्य के आधार पर शार्डिंग कुंजी को चुना जाना चाहिए कि हमारे पास ऊपर वर्णित पहला शार्डिंग नियम है?

इस क्लासिक समस्या को हल करने के लिए कई विकल्प हैं:

crc32 (id_src // id_dst);
crc32 (1 // 2)! = crc32 (2 // 1);
crc32 (+ से)% n;
crc32 (न्यूनतम (से, से)। अधिकतम (से, से))% n।

केशी

और कैश के बारे में कुछ शब्द। हम कह सकते हैं कि कैश एक एंटीपैटर्न है , हालांकि कोई इस कथन के साथ बहस कर सकता है (कई लोग कैश का उपयोग करना पसंद करते हैं)। लेकिन बड़े और बड़े पैमाने पर, कैश को केवल प्रतिक्रिया दर बढ़ाने की आवश्यकता होती है। और उन्हें भार धारण करने के लिए सेट नहीं किया जा सकता है।

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

कैश समस्याएं थीसिस हैं:

एक ठंडा कैश के साथ शुरू करो;
कैश अमान्यकरण मुद्दा;
कैश की संगति।

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

खैर, देखने के लिए धन्यवाद! अंतिम व्याख्यान से कुछ भी याद नहीं करने के लिए, पूरे वेबिनार को देखना बेहतर है।

भंडारण विफलता प्रदान करना