Question

我们在使用NServiceBus的负载均衡，高容量环境中遇到MSMQ问题。

我们的环境如下所示：1 F5通过循环将网络流量分配到6个应用服务器。这6台服务器中的每台服务器在驻留在集群上的远程计算机上使用Bus.Send到1队列。

正常使用期间的事件吞吐量大约为每服务器每秒5-10个。因此，整个环境中每秒30-60个事件，具体取决于负载。

我们看到的问题是，其中一个应用程序框能够将消息发送到集群队列，但其他5个不是。查看遇到故障的5个框，群集的传出队列处于非活动状态。

事务死信队列中还有大量事件。当我们清除该队列时，传出队列连接到群集，但是，传出队列中的消息会以未确认的方式增长。这将持续增长，直到它们再次进入事务死信队列，并且传出队列将状态更改为非活动状态。

有趣的是，当我们执行此清除操作时，另一个框将成为“好框”。所以我们非常肯定问题不是一个坏盒子，而是一次只有一个盒子可以可靠地保持与集群队列的连接。

以前有人遇到过这个吗？

Answer 1

我们有，这是因为此处描述的问题：http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

简短版本：安装MSMQ时，每个MSMQ安装都会为其分配一个唯一ID。它被称为QMId，位于

下的注册表中

HKLM \ Software \ Microsoft \ MSMQ \ Parameters \ Machine Cache \ QMid

它在发送到远程接收器时用作标识符，远程接收器又使用它将ACK发送回正确的发送器。在您的情况下，接收器维护一个缓存，将QMIds映射到IP。我们的问题是我们的几个工人有相同的QMId。这个集群将所有机器的所有消息的所有ACK发送到发送消息的第一台机器。在某些时候，对于某些操作，如MSMQ Windows服务重新启动，缓存过期，另一台机器神奇地“工作”。

请检查您的6台服务器，确保它们都没有相同的QMid。我们有相同的价值，因为它们都是从安装MSMQ后拍摄的Windows图像中隐藏的。

修复很简单，只需在每台机器上重新安装MSMQ功能即可生成新的唯一QMId。

Answer 2

如果您的计算机是从同一图像创建的，则可能具有非唯一的MachineCache ID。您可以通过在每台计算机上运行以下powershell脚本来解决此问题。

这可以在创建图像之前完成，也可以在每台计算机启动后完成。

Remove-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\MSMQ\Parameters\MachineCache' -name 'QMId'
Set-ItemProperty -Path  'Registry::HKLM\Software\Microsoft\MSMQ\Parameters' -Name SysPrep -Value 1

Restart-Service -Name 'MSMQ'

在负载平衡环境中将消息发送到msmq集群队列时，NServicebus失败

2 个答案: