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

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

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

该总线与队列确实有些遗留的概念，最近从像IBM MQ和Tibco集合系统而产生。MQ最初是1：1的系统，实际上是将各种系统分离的队列。

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

但是，这两天（以及较新的竞争产品）现在可以在彼此的空间中玩耍。两者都可以设置为中断以及轮询新消息。两者都调解了各种系统之间的相互作用。

然而，短语消息队列也用于内部线程内消息泵等，并且在这种情况下，用法的确不同。如果您想到经典的Windows消息泵，这确实是您所描述的拉模型，但实际上，它比应用程序间或应用程序间更适合应用程序内。

消息总线

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

资料来源：EIP

消息队列

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

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

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

资料来源：戴夫·马歇尔

图片来源

区别

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

结论

这两种LOOK喜欢做同一种工作-两者之间传递消息的应用程序 或 模块 或 接口 或 系统 或 进程，只是FIFO的差别很小

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

队列

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

总线

消息总线或服务总线为一个（或多个）应用程序提供了一种将消息传递到一个或多个其他应用程序的方式。可能无法保证先进先出的顺序，并且总线的订户可以在消息发送者不知情的情况下来来往往。因此，可以编写应用程序A以通过消息总线将状态更新传递给应用程序B。后来，编写了应用程序C，它也可以从这些更新中受益。可以将应用程序C配置为侦听消息总线并基于这些更新采取操作，而无需对应用程序A进行任何更新。与队列不同，在队列中，发送应用程序将消息显式添加到每个队列中，消息总线使用发布/订阅模型。消息被发布到总线上，任何订阅了这种消息的应用程序都会收到消息。

资源

在其他答案中并未真正明确提及的主要区别是，消息总线允许多个订户，而队列将一个接一个的队列逐项从侦听队列的任何队列中分离出来。如果您希望多个侦听器看到相同的项目脱离队列，则您必须自己处理，服务总线将为您提供开箱即用的服务。

我看到的是消息队列创建消息总线。客户端（即节点）然后可以侦听消息总线。对于具有通过UDP广播消息的MQ的情况尤其如此，换言之，它正在将消息发送到广播/多播地址，而又不知道或关心谁会得到它们。有关此方案的更深入描述，请查看本文。

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

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

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

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

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