Yandex.Cloud में वितरित संदेश कतार सेवा की वास्तुकला

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

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

वितरित स्थिर संदेश कतार क्या है?

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

हम शब्दों को थोड़ा स्पष्ट करेंगे।

एक संदेश कतार एक रिपॉजिटरी है जो एक विशिष्ट क्रम में डेटा के प्लेसमेंट और रीडिंग प्रदान करती है।

दो प्रकार की संस्थाएं आमतौर पर एक कतार के साथ बातचीत करती हैं:

• लेखक (निर्माता) - कतार में संदेश भेजते हैं;
• पाठक (उपभोक्ता) - कतार से संदेश प्राप्त करते हैं (पढ़ें)।

कतार का उपयोग करते समय, पाठक और लेखक एक-दूसरे से स्वतंत्र होते हैं। वे विभिन्न प्रदर्शन, विश्वसनीयता, उपलब्धता के साथ काम कर सकते हैं और यहां तक ​​कि विभिन्न प्रोग्रामिंग भाषाओं में भी लिखा जा सकता है।

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

हमने कतार की अवधारणा का पता लगाया, "वितरण" और "दृढ़ता" पर जाएं।

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

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

संदेश कतार क्या है?

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

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

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



संदेश कतार निम्नलिखित समस्याओं को हल करती है:

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

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

संदेश के साथ Yandex Message Queue कैसे काम करता है

तीन मुख्य चरणों को यहां प्रतिष्ठित किया जा सकता है:

• कतार को संदेश लिखना ;
• कतार से एक संदेश पढ़ना ;
• कतार से एक संदेश निकाल रहा है ।

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

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

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

सफल पढ़ने के बाद, ग्राहक को पहचानकर्ता ReceiptHandle के साथ संदेश प्रेषित किया जाता है। एक पहचानकर्ता विशिष्ट डेटा को इंगित करता है जिसे संदेश कतार से हटा दिया जाना चाहिए।

यैंडेक्स संदेश कतार में कतार प्रकार

पहला और सबसे अधिक इस्तेमाल किया जाने वाला प्रकार मानक कतार है। यह उच्च थ्रूपुट (प्रति सेकंड हजारों संदेश), उत्कृष्ट प्रदर्शन और बुनियादी संचालन के कम निष्पादन समय की विशेषता है। मानक कतार में तार्किक शार्क होती हैं और लगभग रैखिक बैंडविड्थ स्केलिंग का समर्थन करती हैं।


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

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

यैंडेक्स संदेश कतार एपीआई

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

यदि सिस्टम में ऐसा एपीआई है, तो यह जल्दी से वफादार उपयोगकर्ता प्राप्त करता है और विभिन्न प्लेटफार्मों और प्रोग्रामिंग भाषाओं के लिए सुविधाजनक "रैपर" से घिरा हुआ है।

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

ज्यादातर मामलों में, यह SQS उपयोगकर्ता के लिए समापन बिंदु (सेवा पता), क्षेत्र (फिलहाल हम केवल "आरयू-सेंट्रल 1" का उपयोग करते हैं) को बदलने और Yandex.Cloud के भीतर नए क्रेडेंशियल्स प्राप्त करने के लिए पर्याप्त है। बाकी सब कुछ, उदाहरण के लिए, AWS कमांड लाइन का उपयोग करने वाली स्क्रिप्ट, AWS SDK का उपयोग कर कोड या सेलेरी या बोटो पर तैयार सेवा, सबसे अधिक संभावना है, को छूना नहीं होगा। कतार सेवा का तर्क और कार्यक्षमता समान रहेगी।


सेवा दस्तावेज में यांडेक्स संदेश कतार एपीआई विधियों का विस्तृत विवरण है।

सुविधा के बारे में थोड़ा

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

कतारों के संचालन को नियंत्रित करने के लिए इसे और अधिक सुविधाजनक बनाने के लिए, हमने YMQ में बड़ी संख्या में विज़ुअल ग्राफ़ जोड़े हैं, उनमें से केवल एक छोटा सा हिस्सा यहाँ दिखाया गया है। चार्ट Yandex.Cloud कंसोल में, "सांख्यिकी" खंड में स्थित हैं।


हम आपको हमारी राय में चार सबसे उपयोगी रेखांकन के बारे में बताएंगे:

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

रेखांकन तुरंत कतार की गतिशीलता और लॉग देखने की आवश्यकता के बिना विफलताओं की उपस्थिति का मूल्यांकन करने में मदद करते हैं।

हमने कमोबेश सामान्य बिंदुओं पर चर्चा की, अब विवरण पर चलते हैं।

कैसे Yandex डेटाबेस कतार Yandex डेटाबेस का उपयोग करता है

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


YMQ में एक कतार तार्किक शार्क की होती है, जिसे YDB तालिकाओं के कुछ निश्चित सेट द्वारा दर्शाया जाता है। प्रत्येक तालिका अपनी जानकारी का एक टुकड़ा संग्रहीत करती है। उदाहरण के लिए, एक सामान्य राज्य तालिका है जिसे स्टेट कहा जाता है, जो ऑफ और स्टोर करता है वास्तविक संदेशों की संख्या। डेटा और संदेश मेटाडेटा के साथ एक तालिका है। संबंधित विशेषताओं के साथ एक तालिका है।

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

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

यांडेक्स संदेश कतार वास्तुकला का पहला संस्करण

वाईएमक्यू वास्तुकला का पहला संस्करण, जिसे हम खुद को भोला कहते हैं, इस तरह दिखता था।


आरेख YMQ क्लाइंट से YDB रिपॉजिटरी में HTTPS अनुरोध का मार्ग दिखाता है। आइए मुख्य घटकों को देखें:

1. L3-balancer, Yandex डेटा सेंटर को उपयोगकर्ता के निकटतम अनुरोध भेजता है। यह नेटवर्क विलंबता को कम करता है, हालांकि लोड असमान रूप से वितरित किया जाता है।
2. Yandex.Noud वर्चुअल मशीन पर Nginx HTTPS कनेक्शन को समाप्त कर देता है, नेटवर्क हमलों से सुरक्षा प्रदान करता है, और YMQ सर्वर के आगे अनुरोध को पहले ही HTTP में कर देता है।
3. YMQ HTTP सर्वर SQS HTTP API लॉजिक को लागू करता है, अनुरोध को जोरदार टाइप किए गए प्रोटॉफ फॉर्मेट में वैरिफाई करता है और ट्रांसलेट करता है।
4. YMQ अभिनेता प्रणाली - अभिनेता प्रणाली । इसने सूचनाओं के आदान-प्रदान के हजारों अलग-अलग अभिनेताओं को एक साथ लॉन्च किया। प्रत्येक मेजबान की अभिनेता प्रणाली एक क्लस्टर का हिस्सा है। क्लस्टर में सभी कलाकार रहते हैं और एक पूरे के रूप में कार्य करते हैं। YMQ व्यापार तर्क YDB के लिए लेनदेन अनुरोधों में शामिल विभिन्न अभिनेताओं में लागू किया गया है।
5. YDB टैबलेट ("टैबलेट") - कोर YDB का हिस्सा, जो प्रश्नों और लेनदेन में तालिकाओं के साथ काम करने के लिए जिम्मेदार है। टेबलेट स्वयं डेटा संग्रहीत नहीं करते हैं। ये स्मृति में नियंत्रण संरचनाएं हैं जो हार्डवेयर विफलता की स्थिति में राज्य को पुनर्स्थापित कर सकते हैं।
6. भंडारण एक विश्वसनीय, वितरित, दोष-सहिष्णु भंडारण है।

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

Yandex संदेश कतार स्वामी के साथ कतार वास्तुकला

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


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

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

सिद्धांत रूप में, इस तरह की वास्तुकला में केंद्रीकरण से जुड़े कुछ नुकसान हैं:

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

क्वेरी विज़ार्ड पंक्तिबद्ध करना

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


परिचालन के दौरान बैचिंग थोड़ा विलंबता बढ़ाती है। इसके बजाय, बैंडविड्थ में काफी वृद्धि हुई है। बैचिंग के साथ, एकल-शार्क कतार प्रति सेकंड 30,000 अनुरोधों को संसाधित कर सकती है।

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


यहां, जब कोई नया संदेश आता है, तो तीन में से एक परिदृश्य संभव है:

1. यदि इस प्रकार का कोई अन्य लेनदेन नहीं चल रहा है, तो लेनदेन तुरंत शुरू होता है।
2. यदि पहले से ही लेनदेन चल रहे हैं, तो संदेश को बफर में जोड़ा जाता है और लेनदेन के पूरा होने का इंतजार करता है।
3. यदि बफ़र का आकार थ्रेशोल्ड मान से अधिक है, तो एक अन्य समानांतर लेन-देन लॉन्च किया गया है। समवर्ती लेनदेन की संख्या सीमित है।

अनुकूली बैचिंग का विचार टीसीपी / आईपी के लिए नागल एल्गोरिथ्म जैसा दिखता है । : , latency . , . .

Yandex Message Queue, , . , , -.

YDB . YMQ .

, , , .


YMQ . . «» .

YDB . , , , «». , . .


: . , «» . -, «» , «», .

« » . , , .

Yandex Message Queue

Yandex Message Queue – - . . , . .

• - , , . .
• API , . , .
• , : , . , . . boto, 24/7, - .
• , , . .

. - . . .

:

• 5, ;
• YDB;
• , , , ;
• , ;
• . .

.

निष्कर्ष में

– , , , . ., ., ., . .

. . , Yandex Message Queue .