消息混亂：發佈/訂閱VS組播VS扇出

我一直在評估通訊技術爲我的公司，但我已經成爲一些術語之間的概念上的差異很困惑：消息混亂：發佈/訂閱VS組播VS扇出

的Pub/Sub VS 組播 VS 扇出我以下定義工作：

的Pub/Sub有出版商提供每個我的單獨副本這意味着有保證遞送的機會存在
扇出有一個單一的隊列推送到所有聽客戶端。
多播剛剛發送數據，如果有人正在收聽那麼罰款，如果沒有，沒關係。沒有可能保證客戶肯定收到信息。

這些定義是正確的？或者是Pub/Sub模式和組播，直接，扇出等方式來獲得模式？

我正試圖將開箱即用的RabbitMQ定義加入到我們的架構中，但我現在只是在嘗試爲我們的應用程序編寫規範時環顧四周。

請有人告訴我我是否正確？

2011-11-24 ghostJago

我很困惑你選擇的三個術語進行比較。在RabbitMQ中，Fanout和Direct是交換類型。 Pub-Sub是一種通用消息模式，但不是交換類型。而且你甚至沒有提及第三種也是最重要的Exchange類型，即Topic。實際上，只需通過使用相同的綁定鍵聲明多個隊列，就可以在Topic交換中實現Fanout行爲。您可以通過聲明一個隊列爲*作爲通配符綁定密鑰來定義主題交換上的直接行爲。

Pub-Sub通常被理解爲應用程序發佈由多個訂閱者使用的消息的模式。

使用RabbitMQ/AMQP時，務必記住郵件始終發佈給交易所。然後交換路由到隊列。隊列將消息傳遞給訂閱者。交易所的行爲很重要。在主題交換中，來自發布者的路由密鑰與用戶的綁定密鑰相匹配，以便作出路由決定。綁定密鑰可以具有通配符模式，這進一步影響了路由決策。更復雜的路由可以done based on the content of message headers使用頭文件交換型

的RabbitMQ不保證信息的傳送，但你可以通過選擇正確的選項（傳送模式= 2持久性消息），並宣佈交流和隊列中得到保證的交付提前運行您的應用程序，以便不會丟棄消息。

來源

2011-11-26 07:17:31

這是我所希望的那種答案。不知道這些話題可以模擬其他交換類型，因此很有用。 – ghostJago

注意：使用Topic交換來模擬扇出或直接比使用任一特定交換類型慢_slightly_慢。這是經典的性能/靈活性折衷。 – cdeszaq

這不是真的。你不能用任務隊列模擬扇出。這是因爲在第一次消費故事結束後。 – iddqd

你的定義非常正確。請注意，有保證的交付不僅限於pub/sub，也可以通過fanout完成。是的，pub/sub是一個非常基本的描述，可以用扇出，直接等特定方法來實現。

還有更多的消息傳遞模式，你可能會覺得有用。有關更多詳細信息，請參閱Enterprise Integration Patterns。

來源

2011-11-25 04:31:22

+1用於提示EIP書籍。 –

是的，很棒的書。 –

從電子交換的角度來看，術語「多播」意味着「消息被放置在電線上一次」，所有正在監聽的客戶端應用程序都可以從「電線」上讀取消息。任何爲N個客戶端創建N個消息副本的解決方案都不是多播。除了檢查源代碼之外，人們還可以使用「嗅探器」來確定通過消息傳遞系統發送的消息有多少副本。是的，多播消息是UDP協議消息的一種形式。有關一般描述，請參閱：http://en.wikipedia.org/wiki/Multicast。大約十年前，我們使用TIBCO支持多播的消息系統。請參閱：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

來源

2014-10-22 22:41:15

消息混亂：發佈/訂閱VS組播VS扇出

回答

相關問題