रैबिटएमक्यू

Question

में टॉपिक एक्सचेंज बनाम डायरेक्ट एक्सचेंज हमारे पास एक ऐसा एप्लीकेशन है जो खरगोश एमक्यू का उपयोग करेगा और टायर के बीच संदेशों को पारित करने के लिए कई अलग-अलग कतार हैं।

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

एक एकल एक्सचेंज होने के नाते ऐसा लगता है कि इसे बनाए रखना थोड़ा आसान होगा, लेकिन मैं सोच रहा था कि क्या कोई लाभ (यदि कोई है) इसे दूसरे तरीके से करने का कोई तरीका है?

विकल्प 1, का उपयोग कर कई प्रत्यक्ष आदान-प्रदान:

ExchangeA (type: direct) 
-QueueA 

ExchangeB (type: direct) 
-QueueB 

ExchangeC (type: direct) 
-QueueC 

विकल्प 2, एक विषय के विनिमय का उपयोग:

Exchange (type: topic) 
-QueueA (receives messages from exchange with routing key of "TypeA") 
-QueueB (receives messages from exchange with routing key of "TypeB") 
-QueueC (receives messages from exchange with routing key of "TypeC") 

Answer 1

दोनों मॉडल मान लिया जाये कि एक दलाल चल रहा का उपयोग कर लागू किया जाना माना जा रहा है, वहाँ बहुत कम है अंतर जो मैं देख सकता हूं।

विकल्प 2 इस तरह की रूटिंग समस्या को हल करने के लिए वास्तविक दुनिया में अधिक आम लगता है (कम से कम मेरे अजीब अनुभव में) और यह बिल्कुल चुनौती है कि विषय एक्सचेंज हल करने के लिए मौजूद हैं।

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

अंत में, यदि आप विकल्प 1 के साथ कई कतारों के साथ समाप्त होते हैं तो आपके पास एक्सचेंजों का आनुपातिक प्रसार होगा। यह एक रखरखाव सिरदर्द की तरह लगता है। यदि आपके पास केवल कुछ हद तक कतारें होंगी तो यह किसी भी मुद्दे का अधिक नहीं होगा।

Answer 2

छोटे लोड वाले एक छोटे नोड के लिए थोड़ा अंतर होता है। उपरोक्त कारणों के लिए अधिकांश लोग विकल्प दो के साथ जाते हैं।

सिस्टम को डिज़ाइन करते समय आपको अपने आप से पूछना चाहिए कि भविष्य में यह कैसे विस्तार हो सकता है।

यह कैसे स्केल करने जा रहा है?
क्या मुझे इसे स्केल करने की आवश्यकता है? क्या मैं भविष्य में उच्च उपलब्धता क्लस्टर जोड़ना चाहता हूं? क्या मेरा मार्ग बदलने जा रहा है ...

विकल्प 2 ज्यादातर मामलों में बहुत अधिक लचीलापन प्रदान करता है।

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

यदि आपकी बाधा प्रसंस्करण पक्ष पर है, तो आप अपने संदेश विषयों को और भी विभाजित कर सकते हैं और अपने प्रकाशकों को बदलने के साथ कुछ प्राथमिकताएं कर सकते हैं। उदाहरण: ToppicA.urgent, समर्पित उपभोक्ता द्वारा संसाधित, TopicA.log अंततः संसाधित।

संक्षिप्त उत्तर विकल्प 2 के साथ जाता है जब तक कि आपके पास बहुत विशिष्ट प्रदर्शन आवश्यकताएं न हों, उदाहरण के लिए आपको 50k से अधिक संदेश की निरंतर दर कहने की आवश्यकता है, तो आप समर्पित नोड्स पर विकल्प 1 के बारे में सोचना चाहेंगे, लेकिन सामान्य प्रवाह विकल्प 2 के लिए स्केल और बनाए रखना आसान होगा। के रूप में यह आप एक से अधिक रूटिंग कुंजियों के लिए एक एकल पंक्ति उपयोग करने के लिए लचीलापन प्रदान करता है

Answer 3

दरअसल दृष्टिकोण 2 बेहतर है।

एक्सचेंज विषय

QueueA-- binding key = India.Karnataka.* 

आप India.Karnataka.bangalore, India.Karnataka.Mysore के रूप में रूटिंग कुंजी के साथ विषय विनिमय के लिए एक संदेश मार्ग ले सकते हैं।

उपरोक्त सभी संदेशों QueueA को जाता है।

डायरेक्ट एक्सचेंज

लेकिन मैं समझ में नहीं आया आप एकल प्रत्यक्ष विनिमय है और प्रत्येक पंक्ति एक अद्वितीय कुंजी के साथ बंधन के साथ कई कतारों हो सकता है कारण है कि आप दृष्टिकोण 1. में एक से अधिक प्रत्यक्ष आदान-प्रदान का निर्माण कर रहे हैं।

QueueA-- binding key = Key1 
QueueB-- binding Key = Key2 
QueueC-- binding Key = Key3 

सभी कुंजी 1 संदेश QueueA.Key2 पर जाता है QueueB पर जाता है ... आप अभी भी एकल प्रत्यक्ष विनिमय बनाए रख सकते हैं।