मुझे प्रसंस्करण के लिए एक कतार बनाने की आवश्यकता है। कतार अपने आप में अपेक्षाकृत कम आयतन है। हो सकता है कि प्रति घंटे इसमें लगभग 1,000 लिखा जाए। प्रत्येक कार्य के निष्पादन में लगभग एक मिनट लग सकता है, और जैसे ही आइटम कतार में जोड़ा जाता है, लगभग संसाधित हो जाते हैं।
क्या ऐसा कोई कारण है कि मैं Amazon SQS की तरह ऑफ-द-शेल्फ के बजाय RabbitMQ को लागू करना चाह सकता हूं? SQS जैसी किसी चीज के बजाय किसी अनुप्रयोग को अपनी स्वयं की कतार प्रणाली की आवश्यकता क्यों होगी, इसके कुछ कारण हैं?
जवाबों:
एक शुरुआत के लिए, अमेज़ॅन एसक्यूएस एक छद्म कतार है जिसका अर्थ है कि हर संदेश का वितरण (यदि यह कतार तक पहुंचता है) की गारंटी है लेकिन एक एफआईएफओ फैशन में नहीं जो आमतौर पर एक कतार में होता है।
यदि संदेशों का क्रम आपके लिए महत्वपूर्ण है और आप चाहते हैं कि कतार FIFO फैशन में काम करे, तो Amazon SQS प्रलेखन आपके आवेदन तर्क में इसे संभालने के लिए कहता है क्योंकि Amazon SQS से संदेश आपको अनुक्रम से बाहर पहुंच जाएगा।
इसकी तुलना में, जहाँ तक मुझे पता है, आप RabbitMQ में मजदूर कतारों को लागू कर सकते हैं। यदि वह आपको आवेदन स्तर पर कतार संदेश अनुक्रमण को लागू करने के लिए छापता है तो यह एक अधिक बेहतर विकल्प होगा।
यहाँ कुछ कारक हैं जो आपको यह तय करने में मदद करते हैं:
उपरोक्त के रूप में कतार संदेश अनुक्रम।
आप अपने स्वयं के सर्वर को RabbitMQ के साथ सेटअप कर सकते हैं, लेकिन अमेज़न SQS के मामले में नहीं, इसलिए लागत यहाँ शामिल हो जाती है।
अपने स्वयं के सर्वर को स्थापित करने से विषय का अच्छा ज्ञान प्राप्त करना होगा ताकि आप किसी भी कोने को अछूता न छोड़ें। अमेज़न SQS के साथ ऐसा नहीं है क्योंकि इसके साथ शुरुआत करना बहुत जल्दी है।
आपके अपने RabbitMQ सर्वर का मतलब है कि रखरखाव की लागत उस रेखा से कम है जो Amazon SQS के मामले में नहीं है।
अपडेट:
SQS RabbitMQ पर मेरी प्राथमिकता होगी, इसीलिए यहाँ है।
हालाँकि, RabbitMQ पुट और मिल के लिए तेजी से प्रतिक्रिया समय प्रदान कर सकता है, आम तौर पर मेरे परीक्षण से 10 से हजारों टीपीएस में। SQS के लिए उस तरह के थ्रूपुट प्रदान करने के लिए, आपको कई उदाहरणों के साथ क्षैतिज रूप से स्केल करना होगा। इसलिए यदि आप 5ms के तहत देख रहे हैं, तो RabbitMQ विचार करने का एक विकल्प हो सकता है क्योंकि मैंने अपने SQS परीक्षण से लगभग 20ms-30ms का समय टीपीएस के स्तर पर रखा है, जो RabbitMQ से थोड़ा अधिक है।
हमने अभी अपना मैसेजिंग इन्फ्रास्ट्रक्चर ActiveMQ से SQS में स्थानांतरित किया है और इससे अधिक खुशहाल नहीं हो सकते। हमने पाया है कि यह क्लाउड में हमारे अपने ActiveMQ क्लस्टर को बनाए रखने की तुलना में सस्ता है।
उम्मीद है की यह मदद करेगा! आईये जानते हैं कि यह कैसा रहेगा..
मैंने वास्तव में उचित के साथ वाणिज्यिक वातावरण में दोनों का उपयोग किया।
संक्षिप्त उत्तर तब तक है जब तक कि विशिष्ट कोने के मामले नहीं हैं, AWS SQS के साथ जाना बेहतर है। (आप सरल सारांश के लिए नीचे की ओर छोड़ सकते हैं)
कोडिंग (टाई): रैबिटएमक्यू और एडब्ल्यूएस एसक्यूएस दोनों ने पुस्तकालय और बहुत सारे उदाहरण स्थापित किए हैं।
विजिबिलिटी टाइमआउट (SQS): एक चीज जो रैबिटक्यू पर SQS प्रदान करता है वह दृश्यता टाइमआउट की एक व्यापक धारणा है। RabbitMQ में, यदि कोई उपभोक्ता इससे पहले मर जाता है, तो संदेश वापस कतार में रख दिया जाता है। लेकिन एसक्यूएस में दृश्यता समय की एक व्यापक धारणा है जो एक विशिष्ट कॉलर से बंधी नहीं है। तो आप काम की एक इकाई शुरू कर सकते हैं, बड़े समय (12 घंटे तक) के साथ दृश्यता सेट कर सकते हैं, डिस्कनेक्ट कर सकते हैं, एक और श्रमिक खत्म कर सकते हैं और इसे लगा सकते हैं। मेरे डिजाइन में, हम इस बड़े पैमाने पर लाभ उठाते हैं और अतिरिक्त सेवा / भंडारण को समाप्त करते हैं ताकि संभावित 'पेलोड' में संभावित बड़े का प्रबंधन किया जा सके।
डेड लेटर हैंडलिंग (RabbitMQ - एक 'हरे' द्वारा) SQS डेड लेटर क्यू (सिर्फ एक अन्य कतार) में संदेशों को डंप करने वाली "री-ड्राइव पॉलिसी" को मूल रूप से डेड लेटर प्रदान करता है। यह मूल है और केवल संदेश की एक धारणा है। RabbitMQ में डेड लेटर एक्सचेंज होते हैं जो एक्सपायर होने पर मैसेज को int DLE धकेलते हैं। लेकिन यह "आप अपनी सेवाओं और संदेशों को समाप्त नहीं देख रहे हैं, तो यह DLE में उतर जाएगा" के विचार के रूप में एक प्रकार की लूट है। यह RabbitMQ के लिए एक मामूली जीत है क्योंकि मुझे लगता है कि तर्क काउंटर सहज ज्ञान युक्त है। आप अपनी कतार की निगरानी क्यों करेंगे और अपनी सेवाओं की नहीं? (यदि कुछ भी हो, यह दूसरा तरीका है)
प्रशासन (SQS): SQS में कोई प्रशासन नहीं है। आप बस एपीआई कॉल के लिए भुगतान करते हैं। सभी सामान्य सिरदर्द जैसे ओएस / ऐप सुरक्षा पैच, स्केल (अधिक नोड्स जोड़ें), डिस्क को एडब्ल्यूएस टीमों द्वारा नियंत्रित किया जाता है। यह FedRamp अनुपालन (सरकारी उपयोग के लिए) भी है। यह वास्तव में एक 'सेटअप और भूल' प्रणाली है। जहाँ RabbitMQ को सामान्य OS / सर्विस पैच, AMI, क्लस्टरिंग, सिक्योरिटी हार्डनिंग आदि की आवश्यकता होती है, जबकि यह अत्यंत दुर्लभ है, AMIs नीचे जा सकते हैं, या कभी-कभी इसे स्थानांतरित करने की आवश्यकता होती है, इसलिए बॉक्स से बाहर क्लस्टरिंग की आवश्यकता होती है। SQS उन सभी सिरदर्द को समाप्त करता है।
COST (SQS): एक एकल SQS API कॉल में '10 संदेश / 256k आकार तक के बैच' और 'लंबे समय तक मतदान' शामिल हो सकते हैं, जिससे लागत में भारी कटौती हो सकती है। इसके अलावा, संदेश संपीड़न जैसी दर्जनों (कुछ सैकड़ों या अधिक का दावा करने के लिए) संदेश संप्रेषण की तरह कर रहे हैं लागत को कम करने के लिए एक एकल पेलोड में भेजा जा सकता है। और इससे पहले कि हम समय पर विचार करें कि लोग निगरानी / पैचिंग / फिक्सिंग मुद्दों पर खर्च करते हैं। SQS 'पोक प्रोजेक्ट्स' के लिए भी बहुत अच्छा है क्योंकि अगर यह बेकार है, तो इसकी कोई कीमत नहीं है।
FIFO (TIE): 2016 में, AWS ने ~ $ 0.01 / मिलियन एपीआई कॉल ($ 0.05 बनाम $ 0.04 प्रति मिलियन एपीआई ऑल - डिस्काउंट से पहले -) की अतिरिक्त लागत पर FIFO समर्थन पेश किया। आप एफआईएफओ का उपयोग करना चुन सकते हैं या नहीं। गैर-फीफो के लिए हम शायद ही कभी डुप्लिकेट संदेश देखते हैं।
स्टोरेज (SQS): AWS स्टोरेज के लिए चार्ज नहीं करता है लेकिन आपके पास 14 दिनों की सीमा है। RabbitMQ पर, आपको डिस्क स्थान आवंटित करना, विस्तार करना और प्रबंधित करना होगा, जिसमें चरम भंडारण क्षमता और अतिरिक्त बफ़र्स की आवश्यकता होती है। यह सिर्फ अधिक सिरदर्द है।
मेट्रिक्स (SQS): SQS आउट ऑफ बॉक्स मेट्रिक्स प्रदान करता है। और जब आप उन्हें AWS में जोड़ सकते हैं, तो यह सिर्फ अधिक काम है।
स्थानीय देव (टाई): अधिकांश आधुनिक दुकानें स्थानीय वातावरण को पसंद करती हैं। कई विकल्प हैं जो अब RabbitMQ और SQS के डॉकर्स की अनुमति देते हैं।
उच्च थ्रूपुट / बहुत बड़ा संदेश (RabbitMQ - सॉर्ट) जैसे ही आप SQS> 1000 अनुरोध / सेकंड धकेलते हैं, SQS की विलंबता बढ़ जाएगी। इसके आसपास पाने के लिए कई रणनीतियां हैं। लेकिन मुझे लगता है कि ये मामले अत्यंत दुर्लभ हैं क्योंकि अधिकांश कार्य कई कतारों में विभाजित किए जा सकते हैं। लेकिन इस प्रकार के मामलों के लिए जहां 100k / sec की आवश्यकता होती है, मुझे लगता है कि काफ्का बेहतर है। (हम अपने काम पर काफ्का का भी उपयोग करते हैं) काम की एक इकाई होना दुर्लभ है जिसमें कम विलंबता के साथ 1000+ अनुरोध / सेकंड की आवश्यकता होती है। * इस स्पष्टीकरण के लिए और नीचे देखें
सारांश: यदि आप AWS में जा रहे हैं और SQS के साथ विवाह करने के इच्छुक हैं, तो SQS एक नहीं दिमाग है। लेकिन आपको पढ़ना चाहिए क्योंकि विचार करने के लिए महत्वपूर्ण चीजें हैं।
RabbitMQ (और अन्य कतारों) के लिए क्लासिक रणनीति कुछ प्रकार के कार्यों के लिए अनुकूलित कई प्रकार की कतारें बनाना है। फिर इन कतारों में से प्रत्येक को ठीक से ट्यून करें और समान संख्या में इनमें से एक छोटी संख्या में (अक्सर आकार में बहुत बड़ी) कतारों में काम करें। चूंकि SQS का कोई प्रशासनिक ओवरहेड नहीं है, इसलिए वास्तव में प्रत्येक कार्य के लिए समर्पित कतार आवंटित करना बेहतर है। ऐसा करने से, यह पैमाने के लिए अनुमति देता है, लेकिन कतार संतृप्ति को भी समाप्त कर देता है (कतार में काम करना बंद कर देता है और अन्य श्रमिकों को डुबो देता है), काम में बेहतर दृश्य (डिफ़ॉल्ट मैट्रिक्स), और ऐसे।
नई रणनीति ने मेरी टीमों को यह देखने की अनुमति दी है कि काम कैसे वितरित किया जाता है। चला गया 'और अधिक लोड के लिए उदाहरण उन्नयन' के दिन हैं। अतीत में, हम एक बड़ी अस्पष्टीकृत स्पाइक देखेंगे जो अन्य सेवाओं पर दुष्प्रभाव डालती है या बस अनुमान लगाया जाता है कि संचयी संख्या सही लगती है। ' अब वह ट्रैफ़िक अलग हो गया है, हमने वास्तव में कई मुद्दों को उजागर किया है जो पहले किसी का ध्यान नहीं गया और स्पष्ट रूप से समझा सकता है कि ट्रैफ़िक कितना चल रहा है। और जबकि मैट्रिक्स और टूलिंग को लागू करना बहुत संभव है, SQS इन सभी को बॉक्स से बाहर प्रदान करता है।
अभी भी बहुत अच्छे मामले हैं RabbitMQ पर गंभीरता से विचार किया जाना चाहिए
- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.
यदि आप लागत के प्रति संवेदनशील हैं, तो अमेज़ॅन एसक्यूएस शायद अधिक महंगा काम करता है। मैं शायद इसलिए कहता हूँ क्योंकि आपको अभी भी कहीं न कहीं अपने RabbitMQ सर्वर को होस्ट करने की आवश्यकता है। SQS आपको अपने पहले मिलियन अनुरोध मुफ्त देता है और फिर प्रति मिलियन अनुरोधों के बाद $ 0.4 का शुल्क लेता है। SQS के साथ अपनी लागतों को कम करने के लिए एक चाल है, हालांकि लंबे मतदान को सक्षम करने के लिए यानी अपने प्राप्त_message_wait_time को 20 में सेट करना। इसका मतलब यह नहीं है कि आपके संदेश केवल प्रत्येक 20s भेज देंगे, इसका मतलब यह है कि SQS आपसे 'अनुरोध' नहीं लेगा यदि आपकी कतार खाली है (प्रत्येक 20 सेकंड)।
यदि आप प्रति घंटे 1000 अनुरोधों का उपयोग करते हैं तो आप प्रति माह 744000 देख रहे हैं। फ्री टियर के भीतर और लगभग 0.74 * $ 0.4 = $ 0.2976 टियर से बाहर। जिसे शायद आप प्रतीक्षा समय को सक्षम करके और कम कर सकते हैं। तो आपके मामले में SQS वास्तव में सस्ता काम कर सकता है क्योंकि अधिकांश होस्टिंग न्यूनतम $ 5 + से शुरू होती है (जब तक कि आपके पास AWS से EC2 मुक्त टियर नहीं है)। आपको सबसे छोटे विकल्प के साथ ठीक होना चाहिए क्योंकि आरएमक्यू केवल 128 एमबी रैम शुरू करने की सिफारिश करता है।
मुझे लगता है कि SQS बहुत अधिक उपयोगकर्ता के अनुकूल और RabbitMQ अधिक तकनीकी है अगर आप इस तरह से इच्छुक हैं।
अपडेट करें:
मुझे वास्तव में AWS सरल अधिसूचना सेवा मिली जो मुझे https://stackoverflow.com/a/13692720/5403449 के लिए अधिक उपयुक्त थी क्योंकि यह मुख्य रूप से पुश आधारित है अर्थात मतदान नहीं