我们有一个使用 Akka.net 处理消息的 Windows 服务。具体来说，我们有 10 个相同的私有 MSMQ 队列和 10 个协调参与者。我们分配每个参与者处理一个队列并将结果消息发送给 10 个子工作参与者参与者（使用循环路由器）以插入数据库。随着私有队列中消息数量的增加，子角色无法跟上。内存消耗的增长速度与发送的消息数量一样快。我们有两个问题：
如何限制内存增长？我们能否监控子演员收件箱以确保我们不会超载它。
1 个协调演员创建 10 个工人演员，所以我们总共有 100 个童工演员。它是否正确？
【问题讨论】：
标签： akka.net
我认为这里的问题不是内存消耗，而是工作流程本身的方法。
根据您所说的，我可以假设您正在从 MSMQ 中提取消息，立即将它们转发给工作人员，然后提取更多数据，而无需等待工作人员真正完成他们的工作。这是没有附加背压机制的基于推送的数据流的传统问题。
解决这个问题最简单的方法是将数据流更改为基于拉取的模型 - 在这种情况下，协调者参与者不会尝试从 MSMQ 中提取数据，除非其中一名工作人员通知他们完成了他们的工作并正在等待更多数据（在这种情况下，您也不需要将它们放在路由器后面）。通知可以表示为从工作人员发送的消息，当它完成处理当前消息时。该模型的缺点是您将有空闲的工作人员等待选择 MSMQ 消息。
更高级的概念包括需求驱动模型（背压），它可以利用消息缓冲 - 因此您可以提前预取一些数据，然后在处理时重新填充它。同样这样，在等待协调器从队列中选择下一条消息时，没有工作人员会保持空闲状态。你可以阅读更多关于背压概念背后的想法here。
PS：一旦 Akka.Streams 模块问世，您将获得与内置背压原理配合使用的内置机制。
【讨论】：