MSMQ是否已损坏？

Question

我刚开始与一家拥有本土云解决方案的公司合作。他们围绕SQL Server建立了他们的中央排队机制。在与技术总监交谈时，他告诉我他们过去曾尝试过MSMQ，但遇到了大量队列被破坏的问题。我一直在互联网上搜索，但找不到任何关于这个问题的信息。

有没有人听说过这样的事情？有没有关于此的好文章？

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

Answer 1

不，MSMQ不会被破坏。

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

无论消息大小如何，MSMQ都以4MB块为单位工作。发送5kb消息 - 获得4MB块。发送另一条5kb消息 - 使用相同的块。最终块填满，MSMQ开始新的。当读取和使用块中的所有消息（而不是仅查看）时，将删除该文件。 MSMQ会在删除之前等待几个小时，以防万一新邮件到达并需要一个主页 - 当有一个空闲的文件时，没有任何一点可以创建一个新文件。

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

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

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

注释

1. Disk writes in 4kb chunks
2. Messages require contiguous space
3. Writing to disk

Answer 2

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

当承受重负载时，msmq服务可能会出现内存泄漏行为，它永远不会释放内存。因此，最终可能会运行更高和更高工作内存占用的msmq，这将影响性能。

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

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

请注意，这与磁盘碎片不同。

详细了解here，其中我还概述了解决方法here。

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