消息队列与消息总线 – 有什么区别？

还有吗？ 对我而言，MB知道用户和发布者，并作为中介，通知用户新消息（实际上是“推”模式）。 另一方面，MQ更像是一种“拉”式模式，消费者将消息从队列中拉出。

我完全偏离这里吗？

Answer 1

总的来说，当涉及到供应商软件产品时，它们可以互换使用，而且在你所描述的推拉方面没有很强的区别。

BUS vs. QUEUE确实是一个遗留的概念，最近来自IBM MQ和Tibco Rendezvous等系统。 MQ最初是一个1：1的系统，确实是一个解耦各种系统的队列。

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

无论如何（和更新的竞争产品）最近都可以在对方的空间里玩。 两者都可以设置为中断以及轮询新消息。 两者都介于各种系统之间的交互。

然而 ，短语消息队列也用于内部线程内消息泵等，在这种情况下，使用确实是不同的。 如果您想到经典的Windows消息泵，那么确实更多的是您所描述的拉式模型，但实际上它比应用程序之间或机器人之间的内部应用程序更加内部。

Answer 2

消息总线

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

来源： EIP

消息队列

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

• 两个（或更多）进程可以通过访问公用系统消息队列来交换信息。

• 发送过程通过某个（OS）消息传递模块将一个消息放置到一个队列中，这个队列可以被另一个进程读取

来源： 戴夫马歇尔

图像源

区别

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

结论

两者都像做同样的工作 – 在两个应用程序 或 模块 或 接口 或 系统 或 进程之间传递消息，除了FIFO的小差异

Answer 3

其他答案中没有明确提到的主要区别在于，消息总线允许多个订阅者，而队列将逐个列出项目到收听队列的任何内容。 如果你想要多个听众看到相同的物品从队列中排队，你必须自己处理，服务总线会为你提供这种开箱即用的function。

Answer 4

我看到它的方式是消息队列创build消息总线 。 然后客户端（即节点）可以收听消息总线。 对于通过UDP广播MQ消息的情况尤其如此，换句话说，它将消息发送到广播/多播地址，而不知道或关心将要获取它们的消息。 有关这种情况的更深入的描述，您可以查看这篇文章 。

Answer 5

这两个概念之间存在一些模糊的界线，因为有些产品现在支持以前仅属于一个或另一个类别的function（例如，Azure Service Bus支持这两种方法）。

队列

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

总线

消息总线或服务总线为一个（或多个）应用程序提供了将消息传递给一个或多个其他应用程序的途径。 可能不能保证先进先出的订购，并且公共汽车的订户可以在不知道消息发送者的情况下来来去去。 因此，应用程序A可以被写入以通过消息总线将状态更新传送给应用程序B. 之后，编写的应用程序C也可以从这些更新中受益。 应用程序C可以configuration为侦听消息总线，并根据这些更新采取操作，而不需要对应用程序A进行任何更新。与队列不同，发送应用程序明确将消息添加到每个队列，消息总线使用发布/订阅模式。 消息被发布到总线，任何订阅了这种消息的应用程序都会收到它。 这种方法允许应用程序遵循开放/closures的原则，因为它们对未来的变化开放，同时保持封闭以进行额外的修改。

资源