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

Question

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

1. 我可以拥有一台所有机器都使用的集群代理 - 每台机器都没有本地队列
2. 我可以在每台机器上本地安装代理，并使用存储转发功能将消息传递到远程机器

不同的技术似乎强制执行不同的配置 - 例如，MSMQ要求每台机器都有自己的本地队列，而Tibco EMS似乎经常在群集中使用，而每个消费者没有本地队列。

没有本地队列的缺点是什么，以及影响决策的因素是什么？

Answer 1

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

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

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

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

Answer 2

在大多数情况下，我都会冒险使用本地队列。

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

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

您可能希望查看NServiceBus distributor model，它将是您的两种方案的混合：每台计算机上的本地队列，以转发到远程代理/分发服务器群集。

Answer 3

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

MSMQ支持这两种方案。

在方案1中，客户端将使用事务远程接收（MSMQ 4.0及更高版本）。 作为事务性，接收是可靠的并且消息持久（与早期版本的MSMQ不同，因为中止接收在服务器上留下消息）。

在方案2中，存储转发传出队列将发送到客户端上的本地事务队列（再次可靠且持久）。

可靠性和持久性不应成为使用本地和远程队列的决策点。绩效是MSMQ的差异化因素。