绑定到群集 MSMQ 实例的 MSMQ 消息卡在传出队列中

Question

我们为一组 NServiceBus 服务聚集了 MSMQ，一切都运行良好，直到出现问题为止。一台服务器上的传出队列开始填满，很快整个系统就会挂起。

更多详细信息：

我们在服务器 N1 和 N2 之间有一个集群 MSMQ。其他集群资源只是作为本地直接在集群队列上操作的服务，即NServiceBus分配器。

所有工作进程都位于单独的服务器（Services3 和 Services4）上。

对于那些不熟悉 NServiceBus 的人来说，工作进入由分发器管理的集群工作队列中。 Service3 和 Services4 上的工作应用程序将“我已准备好工作”消息发送到由同一分发器管理的集群控制队列，分发器通过将工作单元发送到工作进程的输入队列进行响应。

在某些时候，这个进程可能会完全挂起。以下是系统挂起时群集 MSMQ 实例上的传出队列的图片：

如果我将集群故障转移到另一个节点，就好像整个系统都受到了打击。以下是故障转移后不久的同一群集 MSMQ 实例的图片：

任何人都可以解释此行为，以及我可以做些什么来避免它，以保持系统平稳运行？

Answer 1

一年多过去了，我们的问题似乎已经解决了。关键要点似乎是：

• 确保您拥有可靠的 DNS 系统，以便当 MSMQ 需要解析主机时，它可以。
• 仅在 Windows 故障转移群集上创建一个 MSMQ 群集实例。

当我们设置Windows故障转移集群时，我们假设在非活动节点上“浪费”资源是不好的，因此，当时有两个准相关的NServiceBus集群，我们为Project1创建了一个集群MSMQ实例，以及 Project2 的另一个群集 MSMQ 实例。我们认为，大多数时候，我们会在单独的节点上运行它们，并且在维护时段期间它们会共同位于同一节点上。毕竟，这是我们为 SQL Server 2008 的主实例和开发实例所采用的设置，而且一直运行良好。

在某些时候，我开始对这种方法产生怀疑，特别是因为对每个 MSMQ 实例进行一次或两次故障似乎总是能让消息再次移动。

我向Udi Dahan（NServiceBus的作者）询问了这个集群托管策略，他一脸疑惑地问我“你为什么要做那样的事？”实际上，分发器非常轻量，因此实际上没有太多理由将它们均匀地分布在可用节点之间。

之后，我们决定利用我们所学到的一切仅使用一个 MSMQ 实例重新创建一个新的故障转移群集。从那以后我们就没有看到这个问题了。当然，确保这个问题得到解决将被证明是消极的，因此是不可能的。至少 6 个月以来，这都不是问题，但谁知道呢，我想明天可能就会失败！我们希望不会。

Answer 2

也许您的服务器已被克隆，因此共享相同的队列管理器 ID (QMId)。

MSMQ 使用 QMId 作为哈希来缓存远程计算机的地址。如果网络中有多于一台计算机具有相同的 QMId，您最终可能会出现消息卡住或丢失的情况。

查看此博客文章中的解释和解决方案：链接

Answer 3

您的端点如何配置以保留其订阅？

如果您的一个（或多个）服务遇到错误并由故障转移集群管理器重新启动怎么办？在这种情况下，该服务将永远不会再从其他服务接收到“我已准备好工作”消息之一。

当您故障转移到另一个节点时，我猜您的所有服务都会再次发送这些消息，因此，一切都会恢复正常。

要测试此行为，请执行以下操作。

1. 停止并重新启动所有服务。
2. 仅停止其中一项服务。
3. 重新启动停止的服务。
4. 如果您的系统没有挂起，请对每个服务重复此操作。

如果您的系统现在再次挂起，请检查您的配置。在这种情况下，您的至少一个（如果不是全部）服务会在重新启动之间丢失订阅。如果您还没有这样做，请将订阅保留在数据库中。