MSMQ是否已损坏？

Question

我刚从一家拥有本土云解决方案的公司起步。他们围绕Server构建了中心排队机制。在与技术总监交谈时，他告诉我，他们过去尝试过MSMQ，但是遇到了大量队列被破坏的问题。我一直在网上搜索，但是找不到关于这个问题的任何东西。

有人听说过这样的事吗？这方面有什么好文章吗？

此外，他们也没有为此目的使用WCF。WCF的交易性质会解决这些腐败问题吗？

Answer 1

不，MSMQ不会损坏。

Hugh所指的是存储文件到虚拟内存的内存映射以及这些文件的碎片化。

MSMQ工作在4MB块中，而不考虑消息大小。发送一条5kb的消息-得到一个4MB的块。发送另一条5kb的消息--使用相同的块。最终，块被填满，MSMQ启动了一个新的块。当一个块中的所有消息都被读取和使用时(而不是仅仅浏览)，文件就会被删除。MSMQ在删除之前等待几个小时，以防一条新消息到达并需要一个家--当有一个文件挂在空文件时，创建一个新文件是没有意义的。

如果消息大小相同，则块在到达和离开时很容易被填充和清空。

如果消息是可变大小的，并且没有读取FIFO，那么就会出现漏洞。例如，读取一条5kb消息并到达一条4kb消息，留下1kb的不可用空间。随着时间的推移，由于累积的死空间，分配的内存量将偏离实际的消息量。

这都很正常。MSMQ没有碎片整理。

备注

1. 磁盘写入以4kb块为单位
2. 消息需要相邻的空间。
3. 写入磁盘

Answer 2

我也有过类似的经历，虽然腐败不是我会用的术语。“碎片化”更好。我的经验仅限于使用事务性队列，因此我不确定是否可以通过使用非事务队列来避免此问题。

当受到沉重的负载时，msmq服务可能会表现出内存泄漏行为，在这种情况下，它永远不会释放内存。因此，您可以在越来越高的工作内存足迹中运行msmq，这将影响性能。

我并不真正理解其根本原因，但这与MSMQ将消息存储在磁盘上的方式有关，这些存储文件变得支离破碎。

仅仅因为我已经经历了这一点，并不一定意味着您也会这样做，这可能是我们设置msmq的方式所特有的。

注意，这与磁盘碎片是不同的现象。

阅读更多关于它的这里，在这里我还概述了一个解决这里的方法。

关于WCF，我假设您指的是WCF的msmq绑定。我已经使用了用于msmq的两种绑定，并且不认为这会改变这种行为，因为它与底层的msmq子系统有关。