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

Question

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

我完全偏离了这里吗？

Answer 1

  

消息总线

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

来源：EIP

  

消息队列

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

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

• 发送过程通过一些（OS）消息传递模块a放置 消息到队列中，可由另一个进程读取

来源：Dave Marshall

Image source

  

<强>差分

消息队列包含 FIFO （先出先出）规则，而消息总线则不包含。< / p>

  

<强>结论

LOOK 喜欢做同样的工作 - 在两个应用 或 模块 之间传递消息或 接口 或 系统 或 流程，但差别很小的 FIFO

Answer 2

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

BUS 与 QUEUE 确实是一个传统概念，最近源于IBM MQ和Tibco Rendezvous等系统。 MQ最初是一个1：1系统，实际上是一个解耦各种系统的队列。

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

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

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

Answer 3

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

QUEUE

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

BUS

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

SOURCE

Answer 4

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

Answer 5

我看到的方式是 Message Queue创建消息总线。然后，客户端（即节点）可以监听消息总线。对于通过UDP有MQ广播消息的情况尤其如此，换句话说，它正在向广播/多播地址发送消息而不知道或关心谁将获得它们。有关此方案的更深入说明，您可以查看this article。

Answer 6

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

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

Answer 7

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

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

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