Yandex.Mail के लिए एक गारंटीकृत वितरण प्रणाली के रूप में चिड़ियाघर कीपर

हर दिन, यैंडेक्स लाखों अक्षरों और फ़ाइलों की आने वाली धारा को संसाधित करता है। उनकी संख्या लगातार और लगातार बढ़ रही है। इसी समय, आने वाले भार का स्तर असमान है, यह दृढ़ता से सप्ताह के दिन और दिन के समय पर निर्भर करता है। इसके अलावा, कभी-कभी बॉटनेट हमले होते हैं।



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







प्रसंस्करण में अलग-अलग समय लग सकता है: पत्र को कई सेकंड तक खर्च करने के लिए आवश्यक मिलीसेकंड से, उदाहरण के लिए, तस्वीरों से पाठ निकालने के लिए।



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



इन मामलों में, कतारें हमारी मदद करती हैं। वे आपको इनपुट लोड के फटने को रोकने की अनुमति देते हैं: प्रसंस्करण पत्र के क्लस्टर उपलब्ध होने तक समय और प्रतीक्षा करने के लिए।

कतार क्या है?

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



एक नियम के रूप में, दो प्रोग्राम एक कतार के साथ काम करते हैं: एक इसे डेटा लिखता है, दूसरा इसे पढ़ता है और उपभोक्ता को भेजता है।



कतार रिकॉर्डिंग कार्यक्रम जितना संभव हो उतना सरल होना चाहिए ताकि कार्य को स्वीकार करने में किसी भी अतिरिक्त देरी का परिचय न हो, लेकिन हम इसे मुख्य में डालने के लिए एक और कतार नहीं करना चाहते हैं। और कतार रीडर पहले से ही सेवाओं के विभिन्न कार्यात्मक तत्वों के साथ बातचीत करता है: मेल / डिस्क या अन्य उत्पाद।



कई डेटा रीडर हो सकते हैं, जिनमें से प्रत्येक विशिष्ट डेटा प्रोसेसिंग के लिए कार्य करता है। रीडिंग प्रोग्राम लेखन प्रोग्राम की तुलना में अधिक समय तक काम कर सकता है, क्योंकि इसमें अतिरिक्त कार्यक्षमता है। इसलिए, कतार को अपने स्रोतों द्वारा पत्र / फाइलों को संसाधित करने के लिए पर्याप्त समय के लिए डेटा संग्रहीत करने में सक्षम होना चाहिए।



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



कतारों का उपयोग करते समय, निम्नलिखित नियमों पर विचार करना महत्वपूर्ण है:

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

मेल में पत्र प्राप्त करने के लिए प्रणाली की वास्तुकला:

पत्र मेल में उड़ते हैं और एमएक्स-फ्रंट क्लस्टर में समाप्त होते हैं, जिनके कार्यक्रम पत्रों को संसाधित करते हैं और उन्हें मेल स्टोर में संग्रहीत करते हैं।







यदि पत्र बेमेल विफल हो जाता है, तो पत्र Mx-Back क्लस्टर में गिर जाता है, जिसमें PostFix के लिए एक कतार और कई अक्षर marshalling और विश्लेषण कार्यक्रम होते हैं। एमएक्स-बैक क्लस्टर के कार्यक्रम लंबे समय तक पत्र को रिपॉजिटरी में डालने के कई प्रयास करते हैं, लेकिन अगर कोई विफलता होती है, तो पत्र को पूर्ववत माना जाता है। यदि अक्षर स्टैक सफल होता है, तो पत्र सेवा समूह को भेज दिया जाता है, जहां से यह पहले से ही खोज में दिया जाता है।

डाकघर में डेटा रिसेप्शन सिस्टम की वास्तुकला:

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

डिस्क को फाइल प्राप्त करने के लिए सिस्टम का आर्किटेक्चर:

फ़ाइलें जोकर में उड़ती हैं, जो फाइलों को रिपॉजिटरी (मुल्का) में डालती हैं और इसे mpfs क्लस्टर में भेजती हैं। MPFS मेटाडाटा रिपॉजिटरी (मोंगो डीबी) में फाइलों के बारे में मेटा-जानकारी संग्रहीत करता है और एक खोज में फाइलों के वितरण के लिए इसे कतार में खड़ा करता है। फिर कतार से फाइलें खोज में निकलती हैं।

क्या कतारें हैं

PostFix - मेल के प्रवेश द्वार पर तीन स्थानों पर एक कतार: mxfront, mxback, सेवाएं

इस लाइन का लाभ केवल एक है, इसका उपयोग करना बहुत आसान है।

नुकसान बहुत अधिक हैं:

• यह केवल मेल कार्यों और smtp प्रोटोकॉल के माध्यम से काम करने के लिए डिज़ाइन किया गया है;
• यह केवल एक ही सर्वर के भीतर काम करता है, इसलिए सर्वर विफलता की स्थिति में, सभी डेटा गायब हो जाते हैं और विभिन्न सर्वरों के अनुक्रम का कोई सिंक्रनाइज़ेशन नहीं होता है;
• कतार में एक मनमाने स्थान से नहीं पढ़ा जा सकता, केवल अनुक्रमिक पढ़ना संभव है;
• कार्य को कतार में लौटाना शुरुआत से ही संभव है।

RabbitMQ - मेलबॉक्स से अक्षरों को हटाने के बारे में मेल खोज को सूचित करने के लिए उपयोग किया जाता है। इस कतार का मुख्य लाभ डेटा को मनमाने ढंग से पढ़ने की क्षमता है। नुकसान में ऊपर सूचीबद्ध गैर-नेटवर्क कतार के सभी नुकसान शामिल हैं।



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

लाभ - नेटवर्क कतार। यदि एक सर्वर से बाहर निकलता है, तो डेटा सहेजा जाता है।

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

चिड़ियाघर संचालक

मौजूदा समाधान हल किए जाने वाले कार्यों के संदर्भ में सीमित हैं या प्राप्तकर्ता को डिलीवरी की गारंटी नहीं देते हैं। इसलिए, हमने अपाचे ज़ूकिपर - एक डिलीवरी गारंटी कतार का परीक्षण करने का निर्णय लिया। गारंटीकृत डिलीवरी के अलावा, इसके दो और महत्वपूर्ण लाभ हैं:

• जब कतार सर्वर में से एक अनुपलब्ध है, तो डेटा सुरक्षा और संचालन क्षमता;
• विभिन्न डेटा केंद्रों के लिए कतार के लक्ष्यों को वितरित करने की क्षमता।

बेशक, नुकसान हैं, लेकिन वे इतने महत्वपूर्ण नहीं हैं:

• सर्वर की अत्यधिक संख्या की आवश्यकता है - कम से कम तीन, और अधिमानतः पांच;
• कतार के सभी प्रमुखों में डेटा को सिंक्रनाइज़ करने में समय लगता है।

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



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

Zookeeper पहली बार शुरू नहीं करता है

हमने कई प्रयोग किए, उनमें से कुछ इस प्रकार हैं:

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

हमने जो किया, वह कार्यात्मक और तनावपूर्ण तरीके से परीक्षण करने के लिए आवश्यक था। यहां हमने यह कैसे किया ...

परीक्षण किया वास्तुकला

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



सबसे पहले, गारंटीकृत वितरण प्रोटोकॉल के लिए गारंटीकृत वितरण प्रणाली के काम करने वाले उदाहरणों की एक विषम संख्या की आवश्यकता होती है - ये कम से कम तीन एक साथ चलने वाले कार्यक्रम हैं, और अधिमानतः पाँच हैं।



दूसरे, यांडेक्स में, मानक विभिन्न डेटा केंद्रों में किसी भी सिस्टम का एक साथ प्लेसमेंट है - यह आपको डेटा सेंटर में पावर आउटेज या इस डेटा सेंटर में अन्य असामान्य घटनाओं की स्थिति में सेवा को बनाए रखने की अनुमति देता है।



तीसरा, हमने जानबूझकर अपने जीवन को जटिल बना दिया है और वितरण प्रणाली की आवश्यकताओं और यांडेक्स की आवश्यकताओं को संयोजित करने का निर्णय लिया है, परिणामस्वरूप, हमने तीन अलग-अलग डेटा केंद्रों में स्थित तीन अलग-अलग सर्वरों पर वितरण प्रणाली कार्यक्रम रखा।



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



निम्नलिखित आर्किटेक्चर निकला: प्रॉक्सी प्राप्त डेटा, कतार, भंडारण।

प्रॉक्सी दस सर्वरों पर पांच डेटा केंद्रों में स्थित हैं। कतार तीन सर्वरों पर तीन डेटा केंद्रों में स्थित है। किसी भी SQL और noSQL स्टोरेज को स्टोरेज के रूप में चुना जा सकता है, और किसी भी संख्या में स्टोरेज स्वयं हो सकते हैं। हमारे मामले में, हमने ल्यूसिन पर आधारित noSQL स्टोरेज को स्टोरेज के रूप में चुना, और इसे 2 अलग-अलग डेटा केंद्रों में दो सर्वरों पर रखा।

कार्यात्मक और लोड परीक्षण

कमीशन देने से पहले, हमने गारंटीकृत वितरण प्रणाली के कार्यात्मक और लोड परीक्षण का संचालन किया।

क्रमिक रूप से चार मोड में परीक्षण किया गया:

1. सामान्य ऑपरेशन: सभी सर्वर उपलब्ध हैं। हम दिन के दौरान 500 आरपीएस के लोड के साथ एक कतार के माध्यम से डेटा भेजते हैं, जांचें कि सभी डेटा बैकएंड पर वितरित किए गए हैं।
2. एक कतार सर्वर उपलब्ध नहीं है। हम कतार से डेटा भेजना शुरू करते हैं। हम कतार के एक लक्ष्य को एक घंटे के लिए बंद कर देते हैं। हम पत्र भेजते रहते हैं और यह सत्यापित करते हैं कि डेटा बैकएंड पर दिया गया है।
3. बैकएंड सर्वर में से एक उपलब्ध नहीं है। हम कतार से डेटा भेजना शुरू करते हैं। हम एक घंटे के लिए बैकएंड में से एक को बंद कर देते हैं, फिर इसे चालू करते हैं और एक निश्चित समय के बाद हम जांचते हैं कि डेटा बैकएंड तक पहुंच गया है।
4. कतार सर्वरों में से एक और बैकएंड सर्वरों में से एक उपलब्ध नहीं है। हम कतार से डेटा भेजना शुरू करते हैं। कतार में एक लक्ष्य और एक घंटे के लिए बैकएंड लक्ष्यों में से एक को अक्षम करें। हम डेटा भेजना बंद नहीं करते हैं। जांचें कि डेटा कार्यशील बैकेंड को दिया गया है। एक घंटे के बाद, हम डिस्कनेक्ट की गई कतार को बंद कर देते हैं और हेड बैक करते हैं। हम जांचते हैं कि डेटा चालू करने के बाद दोनों बैकएंड में आते हैं और उनमें से प्रत्येक में डेटा समान है।

की शुरूआत

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



एक शब्द में, ऑपरेशन के दौरान अधिक से अधिक परिस्थितियां उत्पन्न होती हैं जिन्हें हम सफलतापूर्वक ठीक कर देते हैं, और नवंबर में लॉन्च किया गया हमारा मोड़, धीरे-धीरे प्रयोगात्मक प्रौद्योगिकी से एक अच्छा स्टैंड-अलोन उत्पाद में बदल रहा है।