我正在开发两个应用程序，它们使用MSMQ作为消息总线机制，以便a将消息传输到B。这显然必须是稳健的，所以最初我们选择MSMQ来存储和传输消息。
在测试该应用程序时，我们注意到，在现实世界中，调用msmq每分钟处理大约50000条消息(我觉得这听起来很低(，然后我们很快就达到了msmq/storage目录的最大存储大小(我认为默认为1.2gb(。
我们可以增加，但我想知道是否有更好的方法来处理慢速接收器和快速发送器。在这种情况下，有更好的队列或更好的方法吗？
实际上，这并不是接收器速度慢的问题，因为msmq将在存储目录中维护(接收到的(消息大约6个小时，或者直到服务重新启动。因此，本质上，如果我们在5分钟内达到1gb的阈值，那么在几个小时内，我们将达到数据的地形！
请阅读此博客，了解MSMQ如何使用我在Microsoft支持MSMQ多年后整合的资源
它确实涵盖了你需要了解的所有领域。如果你听说了一些博客中没有的关于MSMQ的内容，那么它肯定是错误的，比如MSMQ的1.2GB存储限制。msmq\storage目录的最大大小是硬盘容量——它是一个NTFS文件夹！您应该能够拥有一个包含数百万条消息的队列(假设您有足够的内核内存，如博客中所述(
干杯
John Breakwell
您应该向订阅者应用SLA，他们必须在X时间内阅读消息，否则就会丢失消息。您可以扩展此SLA以匹配到达的邮件量。
简单地说，对于无法满足SLA要求的订户来说，他们并不真的在乎这么快收到消息(如果他们收到了，他们就可以使用(。对于这些订阅者，您可以提供一个较慢的通道，例如最后一小时的消息的XML转储(或者需要什么粒度(。您可能不会在这里存储每个单独的消息，而只是更改的集合(例如，可以从DB中查询的内容(。
对每种消息类型使用单独的队列，这样您就可以根据消息的重要性应用不同的优先级，如果一个队列已满，其他类型的消息就不会被阻止。它还可以通过查看队列中的第一条消息并查看它是何时添加的来确定它等待了多长时间，从而更简单地监控每条消息是否在其SLA内得到处理(请参阅NServiceBus(。
根据您的上述指标，即5分钟内1GB，每分钟50000条消息，我计算每条消息约为4kb。这对于消息来说是相当大的，因为消息通常只应包含有关正在发生的事情的顶级详细信息，主要是更改内容的ID和更改内容的意图。更大的数据可以更好地从其他一些带外通道传输，用于传输大的Blob(例如，文件共享、sftp等(。
此外，由于服务应该封装自己的数据，因此不需要在服务之间共享太多数据。因此，使用消息来说明发生了什么的服务中的大数据并不罕见，使用消息的单独服务之间的大数据表明一些边界可能正在泄漏。