कतार - यह क्या है, इसका उपयोग क्यों और कैसे करें? AWS SQS सुविधाओं पर एक नज़र डालें

सबसे पहले, "कतार" की अवधारणा को परिभाषित करते हैं।

कतार के प्रकार "FIFO" (पहले में, पहले बाहर) पर विचार करें। यदि आप विकिपीडिया से मूल्य लेते हैं - "यह एक सार डेटा प्रकार है जो तत्वों तक पहुंच के अनुशासन के साथ है।" संक्षेप में, इसका मतलब है कि हम इसे यादृच्छिक क्रम में डेटा नहीं प्राप्त कर सकते हैं, लेकिन केवल वही चुनें जो पहले आया था।

अगला, आपको यह तय करने की आवश्यकता है कि उनकी आवश्यकता क्यों है?

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

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

3. स्केलेबिलिटी। और शायद सबसे महत्वपूर्ण कारण, कतार इसे संभव बनाती है
पैमाना। इसका मतलब है कि आप समानांतर में प्रसंस्करण के लिए कई सेवाओं को ला सकते हैं, जिससे उत्पादकता बढ़ जाएगी।

आइए अब उन समस्याओं को देखें, जिनका सामना हम स्वयं करेंगे यदि हम स्वयं कतार बनाएँ:

1. समानांतर पहुँच। केवल एक हैंडलर एक कतार से एक संदेश ले सकता है। यही है, अगर एक ही समय में दो सेवाएं संदेशों के लिए पूछती हैं, तो उनमें से प्रत्येक को संदेशों का एक अनूठा सेट वापस करना होगा। अन्यथा, यह पता चला है कि एक संदेश दो बार संसाधित होता है। भला क्या हो सकता है।

2. कटौती का तंत्र। सेवा में एक सिस्टम होना चाहिए जो कतार को डुप्लिकेट से बचाता है। ऐसी स्थिति हो सकती है जिसमें एक और एक ही डाटासेट को दो बार संयोग से कतार में भेजा जाएगा। परिणामस्वरूप, हम एक ही चीज को दो बार प्रोसेस करेंगे। जो फिर से भयावह है।

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

अमेज़न वेब सेवाएँ - सरल कतार सेवा

अब देखते हैं कि SQS इन समस्याओं को कैसे हल करता है और यह क्या कर सकता है।

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

छोटा सा किन्नर काम

सूचना: सावधान रहें। कुछ मामलों में SQS एक डुप्लिकेट संदेश भेज सकता है (आइटम "एट-कम से कम-एक बार डिलीवरी")। इसलिए, आपकी सेवा को प्रसंस्करण के लिए उदासीन होना चाहिए।

2. त्रुटि हैंडलिंग तंत्र। SQS में, आप "मृत" संदेश (डेड लेटर क्यू) के लिए दूसरी बारी को कॉन्फ़िगर कर सकते हैं। यही है, जो लोग हमारी सेवा को संसाधित नहीं कर सकते हैं उन्हें एक अलग कतार में भेजा जाएगा, जिसे आप अपने विवेक पर निपटान कर सकते हैं। आप यह भी सेट कर सकते हैं जिसके बाद संदेश के असफल प्रयासों की संख्या "मृत" कतार में चली जाएगी। एक असफल प्रयास "दृश्यता समय समाप्त" की समाप्ति है। यही है, अगर इस समय के दौरान कोई विलोपन अनुरोध नहीं भेजा गया है, तो इस तरह के संदेश को अप्रमाणित माना जाएगा और मुख्य कतार में वापस आ जाएगा या "मृत" पर जाएगा।

3. संदेशों का डुप्लीकेशन। SQS में डुप्लिकेट प्रोटेक्शन सिस्टम भी है। प्रत्येक संदेश में एक "Deduplication Id" है , SQS एक संदेश को कतार में नहीं रखेगा
5 मिनट के लिए "Deduplication Id" दोहराया। आपको प्रत्येक संदेश में एक "Deduplication Id" निर्दिष्ट करना होगा या सामग्री-आधारित आईडी पीढ़ी को सक्षम करना होगा। इसका मतलब है कि आपकी सामग्री के आधार पर उत्पन्न एक हैश "डेडुप्लीकेशन आईडी" में मिल जाएगा। पैरामीटर "सामग्री-आधारित डेडुप्लिकेशन"। Deduplication के बारे में अधिक जानकारी

सूचना: यदि आप 5 मिनट के भीतर दो समान संदेश भेजते हैं तो सावधान रहें और आपके पास "सामग्री-आधारित समर्पण" चालू है। SQS कतार में दूसरा संदेश नहीं जोड़ेगा।

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

4. लंबा मतदान। लंबा सर्वेक्षण । SQS इस प्रकार के कनेक्शन का अधिकतम 20 सेकंड के समय के साथ समर्थन करता है। क्या हमें यातायात और सेवा के "मरोड़ते" पर बचाने की अनुमति देता है।

5. मेट्रिक्स। अमेज़न विस्तृत कतार मैट्रिक्स भी प्रदान करता है। जैसे कि प्राप्त / भेजे / हटाए गए संदेशों की संख्या, इन संदेशों के KB में आकार और इसी तरह। आप SQS को CloudWatch लॉग सेवा से भी जोड़ सकते हैं। वहां आप और भी देख सकते हैं। इसके अलावा, आप तथाकथित "अलार्म" को कॉन्फ़िगर कर सकते हैं और आप किसी भी घटना के लिए कार्यों को कॉन्फ़िगर कर सकते हैं। SQS से कनेक्ट करने के बारे में और जानें। और CloudWatch प्रलेखन

अब कतार सेटिंग्स को देखते हैं:

मुख्य हैं:

डिफ़ॉल्ट दृश्यता समय - सेकंड / मिनट / घंटे की संख्या जिसके लिए संदेश प्राप्त करने के बाद प्राप्त करने के लिए दिखाई नहीं देगा। अधिकतम प्रसंस्करण समय 12 घंटे है।

संदेश अवधारण अवधि - सेकंड / मिनट / घंटे / दिन की संख्या, जिसका अर्थ है कि कतार में कितने समय तक अप्रमाणित संदेश संग्रहीत किए जाएंगे। अधिकतम - 14 दिन।

अधिकतम संदेश आकार - KB में अधिकतम संदेश आकार। मान 1KB से 256KB तक है।

डिलीवरी देरी - आप कतार में एक संदेश देने के लिए विलंब समय निर्धारित कर सकते हैं। 0 सेकंड से 15 मिनट तक (वास्तव में, संदेश कतार में होंगे, लेकिन प्राप्त करने के लिए दिखाई नहीं देंगे)।

संदेश प्रतीक्षा समय प्राप्त करें - समय, जब हम नए संदेश प्राप्त करने के लिए "लॉन्ग पोल" का उपयोग करते हैं, तो कनेक्शन कितने समय तक रहेगा।

सामग्री-आधारित समर्पण - ध्वज, यदि सही पर सेट है, तो सामग्री से उत्पन्न SHA-256 हैश के रूप में प्रत्येक संदेश में एक "Deduplication Id" जोड़ा जाएगा।

मृत कतार सेटिंग्स

Redrive Policy - एक ध्वज का उपयोग करें , यदि सेट किया जाता है, तो संदेशों को कई प्रयासों के बाद पुनर्निर्देशित किया जाएगा।

डेड लेटर कतार - "मृत" कतार का नाम जिससे कच्चे संदेश भेजे जाएंगे।

अधिकतम प्राप्तियां - असफल प्रसंस्करण प्रयासों की संख्या, जिसके बाद संदेश "मृत" कतार में भेज दिया जाएगा

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

अब संदेश स्वयं और उनके गुणों के बारे में थोड़ा:

एक संदेश में कई पैरामीटर हैं:

1. संदेश शरीर - कोई भी पाठ
2. संदेश समूह आईडी एक टैग, चैनल की तरह कुछ है, जो सभी संदेशों के लिए आवश्यक है। ऐसे प्रत्येक समूह को फीफो मोड में संसाधित करने की गारंटी है।
संदेश डुप्लिकेटेशन आईडी - डुप्लिकेट की पहचान करने के लिए स्ट्रिंग। यदि "सामग्री-आधारित समर्पण" मोड सेट है, तो पैरामीटर वैकल्पिक है।

संदेश विशेषताएँ भी हैं

विशेषताएँ एक नाम, प्रकार और मूल्य से मिलकर बनती हैं।

1. नाम - तार
2. प्रकार - कई प्रकार हैं: स्ट्रिंग, संख्या, बाइनरी। प्रकार केवल एक स्ट्रिंग के रूप में आता है, और प्रकार के लिए पोस्टफ़िक्स जोड़ना संभव है। इस स्थिति में, प्रकार डॉट के माध्यम से इस पोस्टफिक्स के साथ आएगा, उदाहरण के लिए string.example_postfix
3. मान - तार

सूचना: कृपया ध्यान दें कि विशेषताओं की अधिकतम संख्या १० विवरण है

पुनश्च: यह लेख कतार का एक संक्षिप्त विवरण, साथ ही साथ SQS की क्षमताओं और यांत्रिकी के बारे में थोड़ा जानकारी प्रदान करता है। निम्नलिखित लेख AWS लैम्ब्डा के लिए समर्पित होगा, और फिर उनका व्यावहारिक साझाकरण होगा।