NServiceBus：MSMQ交易不是很糟糕吗？

Question

我正在学习NServiceBus和MSMQ。有人告诉我，MSMQ中的事务队列很糟糕，使用它们对性能非常不利。有谁知道为什么？我猜这是来自它使用DTC的概念，每个人都知道DTC不是真正的可扩展解决方案。在我看来，MSMQ与NServiceBus并没有那么糟糕有几个原因，但我不知道我是否理解它是如何完全运作的。从逻辑上看，我可以想到NServiceBus可能使用交易的3个地方，以确保交付：

1. 通过网络发送邮件时，您可能希望使用事务来确保邮件在丢弃之前已到达远程队列。
2. 从本地队列中读取邮件时，您可能希望确保在丢弃邮件之前成功处理该邮件。
3. 向多个订阅者发布消息时，您可能希望在丢弃消息之前确保它到达所有订阅者。 （我真的希望这不是NServiceBus所做的）

任何人都可以直接告诉我NServiceBus如何做到这一点吗？

Answer 1

Msmq事务不保证接收方已收到消息。事务保证您的计算机上的msmq基础结构已收到消息，并且如果消息是持久的（NSB中的默认值），则表示它已保留在磁盘上并将在重新启动后继续存在。然后，消息将由msmq传递，而不会阻止调用方。这更好地称为“存储和转发”

1. 默认情况下，MSMQ仅保证您的本地msmq基础结构已收到该消息。不要求接收服务器在线。这可以启用（参见下面John的回答）

2. 这是国际海事组织NSB的主要卖点之一。使用跨本地队列和数据存储（即分布式事务）的事务的能力对于保证一致性至关重要。即如果出现故障，则数据存储中不会保留任何内容，并且无需用户执行任何操作即可回滚并重试消息。

3. 与＃1相同。唯一的保证是每个订户最终都会收到已发布的消息。没有阻塞调用，只要你有可用的磁盘空间，发布服务器就会立即返回。

希望这有帮助！

Answer 2

第2点是正确的。您不希望消息导致错误然后崩溃。您希望消息处理程序成功，在这种情况下，它将从队列中删除，或者失败并回滚，以便在达到可配置的重试次数后，可以重试它或将其发送到错误队列进行分析

Answer 3

第1点 - 不完整。如果您使用负信号和负信源队列和TTRQ / TTBR计时器，则交易消息会为您提供此信息。然后，您可以确切地确定消息发生了什么 - 如果它被拒绝，它是否已被传递，是否已被处理。