消息传递混乱：Pub/Sub vs Multicast vs Fan Out答案

【问题标题】：Messaging Confusion: Pub/Sub vs Multicast vs Fan Out消息传递混乱：Pub/Sub vs Multicast vs Fan Out
【发布时间】：2012-01-05 21:27:23
【问题描述】：

我一直在为我的公司评估消息传递技术，但我对几个术语之间的概念差异感到非常困惑：

Pub/Sub vs Multicast vs Fan Out 我正在使用以下定义：

Pub/Sub 让发布者将每条消息的单独副本交付给每个订阅者，这意味着存在保证交付的机会
Fan Out 有一个队列推送到所有收听者客户。
多播只是发送垃圾数据，如果有人在收听那么好吧，如果没有，也没关系。无法保证客户一定会收到消息。

这些定义正确吗？还是 Pub/Sub 模式和多播、直接、扇出等方式来实现该模式？

我正在尝试将开箱即用的 RabbitMQ 定义应用到我们的架构中，但目前我只是在绕圈子尝试为我们的应用编写规范。

请有人告诉我我是否正确？

【问题讨论】：

标签： message-queue messaging rabbitmq publish-subscribe amqp

【解决方案1】：

从电子交换的角度来看，“多播”一词的意思是“将消息放在网络上一次”，并且所有正在侦听的客户端应用程序都可以从“网络”中读取消息。为 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

【讨论】：

【解决方案2】：

我对您选择要比较的三个术语感到困惑。在 RabbitMQ 中，Fanout 和 Direct 是交换类型。 Pub-Sub 是一种通用的消息传递模式，但不是交换类型。你甚至没有提到第三种也是最重要的交换类型，即主题。事实上，您可以通过声明具有相同绑定键的多个队列来在主题交换上实现扇出行为。您可以通过声明一个以* 作为通配符绑定键的队列来定义主题交换上的直接行为。

Pub-Sub 通常被理解为一种应用程序发布消息并被多个订阅者消费的模式。

对于 RabbitMQ/AMQP，重要的是要记住消息总是发布到交易所。然后交换路线到队列。队列将消息传递给订阅者。交易所的行为很重要。在主题交换中，来自发布者的路由键与来自订阅者的绑定键相匹配，以做出路由决策。绑定键可以具有进一步影响路由决策的通配符模式。更复杂的路由可以是done based on the content of message headers，使用headers交换类型

RabbitMQ 不保证消息的传递，但您可以通过选择正确的选项（传递模式 = 2 用于持久性消息）来保证传递，并在运行应用程序之前声明交换和队列，这样消息就不会被丢弃。

【讨论】：

这是我希望得到的答案。不知道主题可以模拟其他交换类型，所以很有用。
注意：使用主题交换来模拟扇出或直接比使用任一特定交换类型稍微慢。这是经典的性能/灵活性权衡。
这不是真的。您无法使用任务队列模拟扇出。因为第一次消费后故事就结束了。
@iddqd：我不明白你在说什么。 AMQP 中没有任务队列之类的东西。您使用主题交换模拟扇出交换。您的消费者使用相同的绑定键声明不同的队列名称，并且该主题交换具有与绑定键匹配的路由键的消息，被扇出（复制）到每个队列。在消息被路由到队列之后使用消息。有关更多信息，请参阅此问题*.com/questions/5253557/…
对不起，我的错误是我在搜索 AMQP+celery 时发现它的答案。

【解决方案3】：

您的定义非常正确。请注意，保证交付不仅限于发布/订阅，也可以通过扇出来完成。是的，pub/sub 是一个非常基本的描述，可以通过 fanout、direct 等特定的方法来实现。

还有更多您可能会发现有用的消息传递模式。请查看Enterprise Integration Patterns 了解更多详情。

【讨论】：