Akka - 你应该创建多少个actor实例？

Posted 2023-02-16

【中文标题】Akka - 你应该创建多少个actor实例？

【英文标题】：Akka - How many instances of an actor should you create?

【发布时间】：2011-12-28 03:31:35

【问题描述】：

我是 Akka 框架的新手，我正在 Netty + Akka 之上构建一个 HTTP 服务器应用程序。

到目前为止，我的想法是为每种类型的请求创建一个参与者。例如。我将有一个演员用于 POST 到 /my-resource，另一个演员用于 GET 到 /my-resource。

我很困惑的是我应该如何进行演员创作？我应该：

为每个请求创建一个新的参与者（我的意思是对于每个请求，我是否应该为相应的参与者执行 TypedActor.newInstance()）？创造一个新演员有多贵？

在服务器启动时为每个参与者创建一个实例，并为每个请求使用该参与者实例？我读过一个演员一次只能处理一条消息，所以这不是瓶颈吗？

做点别的吗？

感谢您的任何反馈。

【参考方案1】：

这是一个相当合理的选择，但是否合适取决于您的请求处理细节。

是的，当然可以。

在许多情况下，最好的办法是让一个参与者响应每个请求（或者每个类型的请求可能只有一个参与者），但这个参与者唯一要做的就是将任务转发给另一个参与者演员（或产生一个Future），它将真正完成这项工作。

【讨论】：

On 3)，这不是说如果执行actor的机器有多个核心，就不能正常使用吗？

@Diego 不，因为它转发到的演员/期货可能适用于这些核心。

【参考方案2】：

好吧，您为每个要管理的可变状态实例创建一个 Actor。

在您的情况下，如果 my-resource 是单个对象并且您希望按顺序处理每个请求，那么这可能只是一个参与者 - 这很容易确保您只在修改之间返回一致的状态。

如果（更有可能）您管理多个资源，那么每个资源实例一个参与者通常是理想的，除非您遇到数千个资源。虽然您也可以按请求运行参与者，但如果您不考虑这些请求正在访问的状态，您最终会得到一个奇怪的设计 - 例如。如果您只为每个 POST 请求创建一个 Actor，您会发现自己担心如何防止它们同时修改相同的资源，这清楚地表明您错误地定义了您的 Actor。

我通常有相当琐碎的请求/回复参与者，其主要目的是抽象与外部系统的通信。他们与“实例”参与者的通信通常仅限于一对请求/响应来执行实际操作。

【参考方案3】：

为了扩大串行请求的处理，添加一个主actor (Supervisor)，该主actor将委托给工作actor (Children) (round-robin fashion)。

【参考方案4】：

如果您使用 Akka，您可以为每个请求创建一个演员。 Akka 的资源非常少，你可以在一个非常普通的 JVM 堆上创建数百万个演员。此外，它们只会在实际执行某些操作时消耗 cpu/stack/threads。

一年前，我在基于线程和基于事件的标准参与者的资源消耗之间做了一个comparison。而且 Akka 甚至比 event-base 还要好。

在我看来，Akka 的一大优点是它允许您将系统设计为“每次使用一个参与者”，而早期的参与者系统通常会强制您“仅使用参与者共享服务”，因为资源开销。

我建议您选择选项 1。

【参考方案5】：

选项 1) 或 2) 都有其缺点。那么，让我们使用选项 3) Routing (Akka 2.0+)

Router 是一个充当负载平衡器的元素，将请求路由到将执行所需任务的其他 Actor。

Akka 提供了不同的路由器实现，具有不同的逻辑来路由消息（例如 SmallestMailboxPool 或 RoundRobinPool）。

每个路由器可能有几个孩子，它的任务是监督他们的邮箱以进一步决定将收到的消息路由到哪里。

//This will create 5 instances of the actor ExampleActor
//managed and supervised by a RoundRobinRouter
ActorRef roundRobinRouter = getContext().actorOf(
Props.create(ExampleActor.class).withRouter(new RoundRobinRouter(5)),"router");

这个过程在this blog中有很好的解释。

【讨论】：

当你说将请求路由到