本文讲述了 Nsb 主节点用于控制消息负载的控制队列，但对我来说，仍然不清楚如何解释此队列中消息数量的不均衡：https ://docs.particular.net/nservicebus/msmq/distributor/
我观察到我的 Nsb 服务速度很慢，这是以前从未经历过的。由于某种原因，与过去相比，每个主节点创建的并行线程更少，并且工作节点或主节点配置没有变化，例如要分配的最大线程数。我试图弄清楚它是不想养活工人的主节点，还是工人不想承担更多工作。
我看到控制队列中的消息数量从 15 条跃升至 40 条，而存储只有 5-8 条。我是否应该将其解释为准备工作的工人，而分销商无法向他们发送更多信息？谢谢
storage queue只要分发者在分发消息，控件中的数字就会上下跳跃。进入 的消息control queue将立即从该队列中弹出并进入storage queue. 进入primary queue分发器的消息将立即导致storage queue弹出的第一条消息。很难解释正在运行的分发服务器队列中的消息数量，因为当您使用计算机管理或队列资源管理器查看这些数字时，它们已经发生了变化。
极端情况是这样的：
1. 分发器的主输入队列中没有消息，并且任何工作人员都没有工作。
2.所有工人都在满负荷工作。没有人能够承担更多的工作。
control在一个正在运行的系统中，它可以是这两个极端之间的任何东西，因此，不幸的是，仅从and的快照很难说太多storage queue。
一些故障排除提示：
如果storage queue为空，则分发者不能分发更多的工作。它不知道将其发送到哪里。如果所有工作人员都被完全占用，就会发生这种情况，因为在control queue他们完成处理消息之前，他们不会将任何就绪消息发送回。
如果与storage queue所有工作线程的工作线程总数相比始终较小，则您正在接近工作人员的总最大容量。
我建议您开始查看工人的日志，看看他们正在做的工作是否比平时花费更长的时间。较慢的数据库/第三方集成？
要检查的另一件事是，是否有任何 IO 重的东西添加到托管分发服务器的机器上。如果分发器已经以接近最大容量运行，添加额外的 IO 可能会减慢机器上的 MSMQ，从而降低吞吐量。