मैंने वास्तव में उचित के साथ वाणिज्यिक वातावरण में दोनों का उपयोग किया।
संक्षिप्त उत्तर तब तक है जब तक कि विशिष्ट कोने के मामले नहीं हैं, 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.