क्या रेडिस मुख्य भंडार है? ये क्या!?

Redis एक मेमोरी-आधारित की-वैल्यू स्टोरेज है जो आमतौर पर कैश और समान नेटवर्क एप्लिकेशन त्वरण तंत्र के लिए उपयोग किया जाता है। फिर भी, हम अपने सभी डेटा को रेडिस - हमारे मुख्य डेटाबेस में संग्रहीत करते हैं।

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

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

डेटा वेयरहाउस के रूप में रेडिस

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

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

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

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

मेरा मानना ​​है कि आप Redis के लिए एक लिखित अनुरोध निष्पादित कर सकते हैं और फिर इसे रिलेशनल स्टोरेज का उपयोग करके सहेज सकते हैं, लेकिन फिर Redis के खराब होने और लिखने की कतार के डेटा हानि के समान जोखिम बने रहते हैं।

हमें क्या चाहिए?

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

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

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

उपरोक्त सभी को ध्यान में रखते हुए, इंजीनियरिंग कठिनाइयों के बावजूद, पोस्टिंग और पढ़ने के लिए नायाब प्रदर्शन हासिल करना आवश्यक है। यह हमारी कार्य करने की क्षमता का आधार है। हमारे पास सभी API कॉल का मूल लक्ष्य 10ms से कम, यहां तक ​​कि उच्च भार के तहत संसाधित किया जाना था, और तब भी जब बड़ी जटिल सूची या खोज संसाधित होती हैं। रेडिस, जाहिर है, हमें इस तरह के प्रदर्शन के साथ प्रदान कर सकता है, लेकिन दो बड़ी समस्याएं दूर नहीं हुई हैं: कैसे, यह लानत है, हम रेडिस का उपयोग कर सकते हैं, अगर हमारे पास सैकड़ों गीगाबाइट डेटा हो सकते हैं, और सर्वर क्रैश के साथ क्या करना है?

अब क्या करें?

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

मेमोरी में सभी डेटा। अरे।

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

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

डेटा को विभाजित करने के लिए, हम इस तरह से हैश और एड्रेस टेबल को स्टोर करते हैं:

  shards.map = हैश: {
                 'शार्क हैश': [शार्क आईडी]
             }
 
 shards। [शार्क आईडी] = हैश: {
                 मास्टर: [मास्टर आईपी / पोर्ट],
                 slave0: [दास 0 आईपी / पोर्ट],
                 slave1: [दास 0 आईपी / पोर्ट],
                 ...
             }
 
 shards.list = zset: {
                 shard1: [वजन],
                 shard2: [वजन],
                 ...
             }

जब डेटा आता है, तो हम अपने डेटा कनेक्टिविटी आवश्यकताओं के आधार पर हैश की गणना करते हैं, फिर हम shards.map में जांचते हैं कि क्या यह किसी भी ब्लॉक को सौंपा गया था, और यदि ऐसा है, तो हम उस ब्लॉक में कॉल भेज सकते हैं।

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

 redis.call ('zadd', 'shards.list', 1, 'shard1')
 redis.call ('zadd', 'shards.list', 2, 'shard2')
 redis.call ('zadd', 'shards.list', 1, 'shard3')

सूची कुछ इस तरह दिखाई देगी:

 [shard1, shard2, shard2, shard3]

उसके बाद, हम सूची से एक यादृच्छिक ब्लॉक असाइन करते हैं, इसे वितरण मानचित्र पर सहेजते हैं और चलते हैं।

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

दरअसल, हमने सैकड़ों ब्लॉक से शुरुआत की, इसलिए सर्वर लोड और मेमोरी लिमिट के बारे में चिंता करने की कोई बात नहीं है।
व्यक्तिगत ब्लॉक बहुत छोटे रहते हैं। एक सर्वर में Redis डेटाबेस में कई ब्लॉक होते हैं, और यदि ये ब्लॉक आकार में बढ़ते हैं, तो हम आसानी से Redis डेटाबेस को स्वतंत्र उदाहरणों में विभाजित कर सकते हैं। मान लीजिए कि हमारे पास 100 ब्लॉक के साथ एक Redis उदाहरण है, हम देखते हैं कि कुछ ब्लॉक आकार में बढ़ रहे हैं और हम Redis को 50 ब्लॉक प्रत्येक के दो उदाहरणों में विभाजित करते हैं। हम ब्लॉकों के बीच वास्तविक समय वितरण को बनाए रखने के लिए वजन को ठीक कर सकते हैं।

सबसे कठिन हिस्सा यह निर्धारित कर रहा है कि आप अपने डेटा को कैसे विभाजित करते हैं। यह बहुत विशिष्ट है और हमारे विभाजन का संस्करण है, शायद एक अलग पोस्ट के लिए एक विषय।

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

सर्वर क्रैश हो गया

असफलता से, असफलताओं से निपटना आसान हो गया। रेडिस क्लस्टर के लिए हमारी 3 अलग-अलग भूमिकाएँ थीं:
- मास्टर, जहां लगभग सभी रिकॉर्डिंग ऑपरेशन हुए,
- अधीनस्थ, जहां लगभग सभी रीडिंग हुईं,
- डेटा बचाने के लिए आवंटित एक कीपर।

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

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

हमारे पास इनमें से दो सर्वर विभिन्न एक्सेसिबिलिटी ज़ोन में स्थित हैं, इसलिए भले ही ज़ोन में से कोई भी विफल हो, हमारे पास एक कार्यशील वास्तविक सर्वर-कीपर है।

इस प्रकार, डेटा खोने के लिए, हमें EC2 में एक बड़ी विफलता की आवश्यकता है, और फिर भी, हम केवल एक सेकंड के डेटा के बारे में खो देंगे।

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

अंतिम परिणाम

अंत में, हम एक ऐसी प्रणाली का निर्माण करने में सक्षम थे जो लोड के तहत लगभग 2 एमएस में एपीआई कॉल करती है।

2 एमएस का मूल्य हमारे सबसे भारी एपीआई कॉल, आरंभीकरण एपीआई कॉल की सेवा है।
हमारे कई अनुरोध बहुत तेजी से परोसे जाते हैं (उदाहरण के लिए, अक्सर 0.6-0.7 एमएस में)। हम एक एपीआई सर्वर पर प्रति सेकंड 1000 एपीआई अनुरोधों को निष्पादित कर सकते हैं। और पेज बनाने के लिए एक एपीआई कॉल की आवश्यकता होती है। हमारे सभी डेटा जांच, ब्लॉक प्रबंधन, प्रमाणीकरण, सत्र प्रबंधन, कनेक्शन प्रबंधन, JSON क्रमांकन और इसी तरह पैमाइश में शामिल हैं।

एपीआई सर्वर जो आपको इस तरह की लोड लागत के साथ प्रति माह केवल $ 90 का काम करने की अनुमति देते हैं, ताकि हम बहुत कम लागत पर काफी बड़े भार का समर्थन और पैमाने कर सकें। भारी विभाजन वाले डेटा का एक और लाभ यह है कि क्षैतिज स्केलिंग तुच्छ है।

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

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

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

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

tl; डॉ
आपकी हार्ड ड्राइव पर मुख्य भंडारण के रूप में रेडिस का उपयोग नहीं करने के कई कारण हैं, लेकिन यदि, किसी कारण से, आपके उपयोग के मामले में इसकी आवश्यकता है, तो आपको शुरुआत से शुरू करने की आवश्यकता है। आपको अपना डेटा अलग से डिज़ाइन करना चाहिए और समर्पित स्टोरेज सर्वर की अतिरिक्त लागत को याद रखना चाहिए।

संशोधन
मुझे बस एहसास हुआ कि मैंने एक अलग सर्वर की लागत की गणना की और आरक्षित उदाहरणों की एक बार की लागत को जोड़ना भूल गया। यह 213 डॉलर होना चाहिए।