消息混淆：Pub/Sub vs Multicast vs Fan Out

Question

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

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

• Pub/Sub是指发布者向每个订阅者分别发送消息的方式，这意味着存在保证交付的机会。
• Fan Out是指单个队列向所有监听客户端推送。
• Multicast只是广播数据，如果有人在收听，则很好，如果没有，则无所谓。 没有保证客户端肯定能收到消息的可能性。

这些定义正确吗？还是Pub/Sub模式，而Multicast、Direct、Fanout等是实现该模式的方式？

我正在尝试将RabbitMQ的开箱即用定义融入到我们的架构中，但目前我只是在写我们应用程序规范时打转。

请问是否有人可以给我建议，告诉我我是否正确？

- ghostJago

Answer 1

我对您选择的三个术语感到困惑。在RabbitMQ中，Fanout和Direct是交换机类型。Pub-Sub是通用的消息模式，但不是交换机类型。而且，您甚至没有提到第三种最重要的交换机类型，即Topic。实际上，您可以通过声明具有相同绑定键的多个队列，在Topic交换机上实现Fanout行为。并且您可以通过声明一个绑定键为*的队列来定义直连行为。

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

在RabbitMQ/AMQP中，重要的是要记住消息总是发布到交换机中。然后，交换机将路由到队列。队列将消息传递给订阅者。交换机的行为很重要。在Topic交换机中，发布者的路由键与订阅者的绑定键匹配，以便进行路由决策。绑定键可以有通配符模式，这进一步影响路由决策。更复杂的路由可以基于消息头内容使用标题交换机类型进行done RabbitMQ不能保证消息的传递，但是您可以通过选择正确的选项（持久化消息的传递模式=2）并预先声明交换机和队列来确保消息不会被丢弃。

- Michael Dillon

---

这是我所希望的答案。我不知道主题可以模拟其他交换类型，所以这很有用。 - ghostJago

注意：使用主题交换来模拟扇出或直接交换比使用任一特定类型的交换略慢。这是经典的性能/灵活性权衡。 - cdeszaq

这不是真的。你不能用任务队列模拟扇出。这是因为在第一次消费后，故事就结束了。 - baklarz2048

@iddqd：我不明白你在说什么。AMQP 中没有任务队列这样的东西。你可以使用主题交换机来模拟扇出交换机。消费者使用相同的绑定键声明不同的队列名称，并将消息发送到此主题交换机，具有与绑定键匹配的路由键的消息会被复制到每个队列中。消费消息发生在消息路由到队列之后。请参阅此问题以获取更多信息https://dev59.com/jlXTa4cB1Zd3GeqPyBGB - Michael Dillon

抱歉，我的错误。我在搜索 AMQP+celery 时找到了答案。 - baklarz2048

Answer 2

你的定义基本正确。请注意，保证交付不仅限于发布/订阅，也可以使用扇出实现。是的，发布/订阅是一种非常基本的描述，可以用特定的方法来实现，比如扇出、直接等等。

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

- Brian Kelly

Answer 3

从电子交换的角度来看，“组播”一词意味着“将消息仅放置在电线上一次”，所有正在侦听的客户端应用程序都可以从“电线”读取消息。任何使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。

- California-OldGuy