Actor 服务结构参与者模型是否允许节流？如果没有，如何制作？

下面是我使用service fabric群集的场景：

每1个客户一个参与者实例

参与者实例id是客户id。所以这个参与者是我的客户参与者

customer actor实现了一个具有n个步骤的工作流

比方说，在步骤m（共n个步骤），该参与者需要与外部系统（E）对话

系统E在任何给定时间不允许超过x个客户端

我在任何给定时间都有100000个客户参与者实例

由于外部系统（E），我需要在步骤m将我的客户参与者限制为x

在步骤m（节流设置为x）之后，我想再次回到actor模型的全部潜能

以下是我的问题：

服务结构集群参与者模型是否提供任何节流机制？有了这种节流机制，我的情况会发生什么变化

若在actor模型中并没有现成的节流解决方案，我将如何创建一个呢

---

不，没有什么是内置的。如果您的系统E只能处理x个客户端，并且您有y>x个参与者，那么您的参与者可以在步骤m尝试与E对话，如果E已满负荷，请退出，稍后再试。你还希望有什么其他的节流方式

通常您会使用某种队列来处理负载突发。您可以（例如）在Actor和systeme之间添加一个服务，该服务将来自Actor的消息排队，然后在后台使用节流进行处理

---

演员和他们的来电者不需要知道任何节流。它将参与者与系统E分离。

我曾想过将步骤m提取到它自己的参与者（比如SystemEActor）中，后者将负责与系统E通信。当客户参与者在步骤m创建SystemEActor时，我希望找到一种方法来限制SystemEActor，而无需额外编码。但是，似乎SystemEActor可以通过保持在任何时刻执行的并发请求数量的状态而成为限制参与者。如果容量已满，则只需等待。否则，它可以像往常一样与系统E通信。下一个问题是如何让对象在等待时内存不足。可能会使用提醒？请查看我对Vaclav的评论，让我知道这是否是一个可行的选项。由于基于回合的访问模式和RPC风格的通信，在参与者内部等待也会导致呼叫者等待（降低整个系统的速度）。在等待期间，其他操作不会执行。（包括计时器和提醒）此外，当从多个并发线程访问时，Actor中的Statemanager也不能正常工作。因此，维护执行的并发请求数量是很困难的。我认为服务更适合于此目的。请看（）以获得有关如何排队和后台处理传入消息的灵感。我计划使用提醒功能将控件快速释放回调用方，以实现可伸缩性。随着service fabric 5.2.207的发布，出现了新的ReliableCcurrentQueue。这不解决并发性问题吗？