【问题标题】：Message Queue vs Message Bus -- what are the differences?消息队列与消息总线——有什么区别？
【发布时间】：2011-12-09 06:50:36
【问题描述】：

还有吗？对我来说，MB 了解订阅者和发布者，并充当调解者，通知订阅者有新消息（实际上是“推送”模型）。另一方面，MQ 更像是一种“拉”模型，消费者从队列中拉出消息。

我在这里完全偏离轨道了吗？

【问题讨论】：

标签： message-queue message-bus

【解决方案1】：

消息总线

消息总线是一种消息传递基础架构，允许不同系统通过一组共享接口（消息总线）进行通信。 p>

来源：EIP

消息队列

消息队列的基本思想很简单：

两个（或更多）进程可以通过访问一个通用系统消息队列。
发送进程通过一些（OS）消息传递模块放置一个消息放到可以被另一个进程读取的队列中

来源：Dave Marshall

Image source

区别

消息队列包含FIFO（先进先出）规则，而在消息总线中则没有。

结论

LOOK 都喜欢做同样的工作——在两个应用程序 或模块 之间传递消息或 接口或系统或进程，除了小的差异先进先出

【讨论】：

不一定正确，有些队列可以让你跳过消息。虽然一般来说，这是区分两者的好方法。
当您从某个地方获取文本和图像时，您通常会添加学分。我已经添加了来源。

【解决方案2】：

总的来说，当涉及到供应商软件产品时，它们可以互换使用，并且在推送或拉取方面没有您所描述的明显区别。

BUS 与 QUEUE 确实有点旧概念，最近源于 IBM MQ 和 Tibco Rendezvous 等系统。 MQ 原本是一个 1:1 的系统，确实是一个解耦各个系统的队列。

相比之下，Tibco 是（作为一个）消息传递主干，您可以在同一主题上拥有多个发布者和订阅者。

不过，如今两者（以及较新的竞争产品）都可以在彼此的空间中发挥作用。两者都可以设置为中断以及轮询新消息。两者都调解各种系统之间的交互。

然而短语message-queue也用于内部线程内消息泵等，在这种情况下，用法确实不同。如果你想到经典的 Windows 消息泵，这确实更像是你描述的拉模型，但它确实更像是应用内而不是应用间或盒子间。

【讨论】：

【解决方案3】：

这两个概念之间的界限有些模糊，因为一些产品现在支持以前只属于一个或另一个类别的功能（例如 Azure 服务总线支持这两种方法）。

队列

消息队列从应用程序接收消息，并以先进先出 (FIFO) 的方式将它们提供给一个或多个其他应用程序。在许多架构场景中，如果应用程序 A 需要向应用程序 B 和 C 发送更新或命令，则可以为 B 和 C 设置单独的消息队列。A 会将单独的消息写入每个队列，每个依赖的应用程序将从其读取自己的队列（消息在出队时被删除）。为了让 A 发送更新，B 和 C 都不需要可用。每个消息队列都是持久的，因此如果应用程序重新启动，一旦重新联机，它将开始从其队列中拉取。这有助于打破依赖系统之间的依赖关系，并可以为应用程序提供更高的可扩展性和容错能力。

总线

消息总线或服务总线为一个（或多个）应用程序提供一种将消息传递给一个或多个其他应用程序的方式。可能无法保证先进先出的顺序，并且总线的订阅者可以在消息发送者不知情的情况下进出。因此，可以编写应用程序 A 以通过消息总线将状态更新传递给应用程序 B。稍后，编写的应用程序 C 也可以从这些更新中受益。应用程序 C 可以配置为监听消息总线并根据这些更新采取行动，而不需要对应用程序 A 进行任何更新。与队列不同，发送应用程序显式将消息添加到每个队列，消息总线使用发布/订阅模型。消息被发布到总线上，任何订阅了这种消息的应用程序都会收到它。这种方法允许应用程序遵循开放/封闭原则，因为它们对未来的更改开放，同时对其他修改保持封闭。

SOURCE

【讨论】：

【解决方案4】：

在其他答案中没有真正明确提到的主要区别是消息总线允许多个订阅者，而队列会将项目一个接一个地出列到任何侦听队列的对象。如果您希望多个侦听器看到相同的项目从队列中出来，您必须自己处理，服务总线会为您开箱即用。

【讨论】：

不完全正确，至少现在是这样。像 Amazon SQS 这样的服务将允许多个阅读器读取相同的消息。 “隐形”的时间是可配置的。许多队列系统都有这样的特性——以及重试和死信队列。
@Tom OP 没有提到任何具体的产品，所以我认为他正在尝试理解术语和概念——为此，我发现这个答案是有用且真实的；即使供应商基于这两个概念创建混合产品也是事实，我认为这些术语仍然有效且有用。

【解决方案5】：

我的看法是消息队列创建了消息总线。客户端（即节点）然后可以监听消息总线。对于您有一个通过 UDP 广播消息的 MQ 的情况尤其如此，换句话说，它将消息发送到广播/多播地址而不知道或关心谁将获得它们。有关此场景的更深入描述，您可以查看this article。

【讨论】：

【解决方案6】：

消息总线是一对多的分发模型。此模型中的目的地通常称为主题或主题。所有消费订阅者都会收到相同的发布消息。您也可以将其称为“广播”模型。您可以将主题视为分布式计算的观察者设计模式中的主题等价物。一些消息总线提供者有效地选择将其实现为 UDP 而不是 TCP。对于主题，消息传递是“即发即弃”——如果没有人听，消息就会消失。如果这不是您想要的，您可以使用“持久订阅”。

消息队列是一对一的消息目的地。该消息仅由一个消费接收者接收（请注意：始终将订阅者用于“主题客户端”，将接收者用于队列客户端可避免混淆）。发送到队列的消息将存储在磁盘或内存中，直到有人捡起它或它过期。所以队列（和持久订阅）需要一些主动的存储管理，你需要考虑慢消费者。

我认为，在大多数环境中，主题是更好的选择，因为您始终可以添加其他组件而无需更改架构。添加的组件可能是监控、日志记录、分析等。在项目开始时，您永远不知道 1 年、5 年、10 年的需求会是什么样。改变是不可避免的，拥抱它:-)

【讨论】：

【解决方案7】：

服务总线是比消息队列更通用的术语。

MQ 是一个简单的 FIFO，但有更复杂的方法来实现服务总线，即事件中心，它是处理消息的巨大“中心”。除了 MQ 提供的功能外，它还允许存储消息（因此使用多个订阅者）等

【讨论】：