NServiceBus Timeoutsdispatcher 队列在压力测试期间被消息淹没

Question

我正在对一个使用 2 次超时的 saga 进行压力测试。在测试期间，大约创建了 21K saga。所以这意味着 42K 超时，但我注意到 saga 的 timeoutsdispatcher 队列被成千上万条消息淹没，直到它崩溃，因为达到了 MSMQ 存储限制。

自从我将持久性机制从 RavenDB 切换到 SQL Server 后，我看到了这种行为。

有谁知道可能出了什么问题？

传输：MSMQ
持久性：NHibernate 使用的包：

NHibernate version 4.0.4.4000  
NServiceBus version 5.2.14  
NServiceBus.Host version 6.0.0  
NServiceBus.Log4Net version 1.0.0  
NServiceBus.NHibernate version 6.2.7  

测试设置：
* 端点 1 正在向端点 2 发送 22000 条消息。
* 端点 2 托管由该消息启动的 saga。
* 每个 saga 发布一个事件，然后请求 2 次超时：1 次在 4 分钟，1 次在 10 分钟。

观察到的行为：
* 端点 1 在一分钟内发送了 22K 条消息。
* 端点 2（传奇）每秒处理 5 到 10 条消息。
* 4 分钟后第一次超时被触发，而端点 2 仍在处理来自其队列的消息，因此仍在创建新的 saga 实例。
* 从那一刻起，saga 端点的 timeoutsdispatcher 队列中就充满了消息。
* 大约 10 分钟后，timeoutsdispatcher 队列已经包含超过 170K 条消息，并且仍在填满。
* 这种情况一直持续到端点 2 崩溃，因为达到了 MSMQ 存储限制，或者输入队列中的所有消息都已处理。如果后者先发生，则 timeoutsdispatcher 队列消息计数开始减少，直到最终达到 0。

Answer 1

您是否对 RavenDB 进行了相同的压力测试？ SQL Server 是否在一台功能或多或少同样强大且具有快速驱动器的机器上？

更新

对你的传奇进行一些检查

• 是否使用了 [Unique] 属性，是否正确使用？换句话说，您是否为每条传入消息使用唯一的 ID？这样每条产生 2 次超时的传入消息都会创建一个唯一的 saga 实例吗？如果每个传入的消息都访问同一个 Saga，这将是极大限制吞吐量的一个很好的例子。想象一下 Saga 实例已经创建过一次，否则解释会变得很复杂。于是 Message1 进来了，试图在数据库中找到行，找到并锁定它。第二条消息同时进来，找到了行但它被锁定了。它将进入重试。 Message3 直到 Message100 进来（如果并发设置为 100）并且都尝试做同样的事情，立即失败。你可以看到这会限制吞吐量一段时间:)
• 您的 Saga 表和超时表上的索引是否正确？
• 您的最大并发级别设置为多少？

根据消息的数量，您说您发送了 22k 条消息，导致 44k 条超时消息。图片所有这些超时都在 MSMQ 中。想象一下消息非常非常小，比如 1Kb。 NServiceBus 添加的头信息可能会占用 2Kb。 3Kb 大约是 135 兆字节的 44.000 倍。因此，无法填满默认配额为 1GB 的默认 MSMQ 安装。

这可能意味着您的死信队列已完全填满。 Find more information on MSMQ connectionstrings 并设置适当的连接字符串。例如

<connectionStrings>
  <add name="NServiceBus/Transport"
    connectionString="deadLetter=false;journal=false;"/>
</connectionStrings>

带有TimeToBeReceived 属性集(link) 的消息最终进入死信队列。此外，清除队列将使所有消息进入死信队列。除非你设置了正确的连接字符串。