Architecture 发布/订阅消息中的本地队列与远程队列

如果我正在构建一个包含数十个使用消息队列的发布者/订阅者的系统，那么我似乎有几个网络配置选项：

我可以有一个所有机器都使用的集群代理——每台机器不会有本地队列

我可以在每台机器上本地安装代理，并使用store和forward将消息传递到远程机器

不同的技术似乎实施了不同的配置——例如，MSMQ要求每台机器都有自己的本地队列，而Tibco EMS似乎经常在集群中使用，每个消费者上都没有本地队列

---

没有本地队列的缺点是什么？哪些因素会影响决策

没有提供持久消息存储的本地队列意味着您无法保证消息传递。在集群中使用类似RabbitMQ的东西，并在本地使用代理实例，可以为您提供一种持久的机制来存储要传递的消息。如果必须通过网络连接到远程代理以发送持久消息，则网络故障的风险更高

MSMQ也支持存储转发，但它不提供任何群集路由功能。这意味着应用程序必须完成这项工作（或者在上面有一个层，例如MassTransit或NServiceBus为您完成这项工作）

当我想到TIBCO时，我想到的是一个集中的EMS服务器集群，应用服务器与之通信，而不是在本地运行代理实例。围绕EMS和BusinessWorks应用程序服务器的GUI工具在这个世界上真正推动了一个模型

---

在本地存储消息的任何分布式情况下，重要的是确保机器本身配备了适当的消息存储设备，具有快速磁盘和足够的磁盘，以满足预期的消息积压/容量。

我敢说，在大多数情况下，本地队列是必要的

如果消息需要持久，则需要本地队列。换句话说，如果到远程队列的连接不可靠，并且您希望消息最终到达其订户，那么您需要本地队列的存储和转发功能

如果消息不需要持久（可能在触发事件后丢失），那么远程共享队列将是一个选项

---

您可能想看看，这将是两种方案的混合：每台机器上的本地队列转发到远程代理/分发服务器群集。

我不确定是否同意MSMQ上的评论，因为它们似乎过时了。也许我错过了什么

MSMQ支持这两种方案

在场景1中，客户端将使用事务性远程接收（MSMQ 4.0及更高版本）。 由于是事务性的，接收是可靠的，消息是持久的（与MSMQ早期版本不同，中止的接收将消息留在服务器上）

在场景2中，存储转发传出队列将发送到客户端上的本地事务队列（同样可靠且持久）

---

可靠性和耐久性不应成为使用本地队列和远程队列的决策点。性能是MSMQ的独特之处。

TIBCO EMS支持代理之间的路由，这将允许本地和集中服务器。但是，最常见的设置是集中式集群。此外，本地实例可能会产生更高的许可费。