संदेश भ्रम: पब/बनाम फैन आउट

Question

मैं अपनी कंपनी के लिए संदेश सेवा प्रौद्योगिकियों का मूल्यांकन किया गया है उप बनाम मल्टीकास्ट लेकिन मैं बहुत कुछ शब्दों के बीच वैचारिक मतभेद से भ्रमित हो गया है:

पब/उप बनाम मल्टीकास्ट बनाम फैन आउट मैं निम्नलिखित परिभाषा के साथ काम कर रहा हूँ:

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

क्या ये परिभाषाएं सही हैं? या पब/सब पैटर्न और मल्टीकास्ट, प्रत्यक्ष, fanout आदि पैटर्न पैटर्न को स्वीकार करने के तरीके हैं?

मैं अपने आर्किटेक्चर में आउट-ऑफ-द-बॉक्स खरगोश एमक्यू परिभाषाओं को काम करने की कोशिश कर रहा हूं लेकिन मैं इस समय सर्कल में अपने ऐप के लिए चश्मा लिखने की कोशिश कर रहा हूं।

कृपया कोई मुझे सलाह दे सकता है कि मैं सही हूं या नहीं?

Answer 1

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

पब-सब को आम तौर पर एक पैटर्न के रूप में समझा जाता है जिसमें एक एप्लिकेशन कई ग्राहकों द्वारा उपभोग किए जाने वाले संदेशों को प्रकाशित करता है।

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

RabbitMQ संदेशों के वितरण की गारंटी नहीं है एक हेडर विनिमय प्रकार का उपयोग done based on the content of message headers हो सकता है, लेकिन आप में (वितरण मोड = 2 लगातार msgs के लिए) सही विकल्प चुनने, और घोषणा की आदान-प्रदान और कतारों की गारंटी वितरण प्राप्त कर सकते हैं अपने आवेदन को चलाने का अग्रिम ताकि संदेशों को त्याग दिया न जाए।

Answer 2

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

और मैसेजिंग पैटर्न हैं जो आपको उपयोगी मिल सकते हैं। अधिक जानकारी के लिए Enterprise Integration Patterns पर एक नज़र डालें।

Answer 3

इलेक्ट्रॉनिक एक्सचेंज बिंदु से "मल्टीकास्ट" शब्द का अर्थ है "संदेश तार पर एक बार रखा गया है" और सभी क्लाइंट एप्लिकेशन जो सुन रहे हैं, वे "तार" से संदेश पढ़ सकते हैं। एन समाधान के लिए संदेश की एन प्रतियां बनाने वाला कोई भी समाधान मल्टीकास्ट नहीं है। स्रोत कोड की जांच करने के अलावा, यह निर्धारित करने के लिए कि "मैसेजिंग सिस्टम से वायर पर संदेश की कितनी प्रतियां भेजी जाती हैं, यह निर्धारित करने के लिए" स्नफ़फर "का भी उपयोग कर सकते हैं। और हां, मल्टीकास्ट संदेश यूडीपी प्रोटोकॉल संदेश का एक रूप है। सामान्य विवरण के लिए देखें: http://en.wikipedia.org/wiki/Multicast। लगभग दस साल पहले, हमने टीआईबीसीओ से मैसेजिंग सिस्टम का इस्तेमाल किया जो मल्टीकास्ट का समर्थन करता था। देखें: https://docs.tibco.com/pub/ems_openvms_c_client/8.0.0-june-2013/docs/html/tib_ems_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_ems_users_guide&file=EMS.5.091.htm