您可以为每个要管理的可变状态示例创建一个Actor。
在您的示例中，如果my-resource是单个对象，并且您希望串行处理每个请求，则可能只有一个参与者-这很容易确保在修改之间只返回一致的状态。
如果（更有可能）您管理多个资源，每个资源示例一个参与者通常是理想的，除非您遇到成千上万的资源。虽然您也可以运行每个请求的参与者，但如果您不考虑这些请求正在访问的状态，您最终将得到一个奇怪的设计--例如，如果您只为每个POST请求创建一个参与者，您会发现自己在担心如何防止它们并发地修改同一资源，这清楚地表明您错误地定义了参与者。
我通常有一些相当琐碎的请求/应答参与者，它们的主要目的是抽象与外部系统的通信。它们与“示例”参与者的通信通常被限制在一个请求/响应对中，以执行实际的操作。

如果你使用Akka，你可以为每个请求创建一个参与者。Akka的资源非常少，你可以在一个相当普通的JVM堆上创建数百万个参与者。而且，它们只会在实际执行某件事时消耗cpu/堆栈/线程。
一年前，我在基于线程和基于事件的标准参与者的资源消耗之间做了一个comparison，Akka甚至比基于事件的更好。
在我看来，Akka的一大优点是，它 * 允许 * 您将系统设计为“每次使用一个参与者”，而早期的参与者系统由于资源开销而经常迫使您“仅将参与者用于共享服务”。
我建议您选择选项1。

选项1）或2）都有缺点。因此，让我们使用选项3）Routing（Akka 2.0+）
路由器是充当负载平衡器的元素，将请求路由到将执行所需任务的其他执行元。
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中有详细说明。

1.这是一个相当合理的选择，但它是否合适取决于您的请求处理的具体情况。
1.是的，当然可以。
1.在许多情况下，最好的做法是让一个参与者响应每个请求（或者每种类型的请求一个参与者），但是这个参与者所做的唯一事情是将任务转发给另一个参与者（或者产生一个Future），后者将实际执行该工作。

要扩大串行请求处理，请添加一个主执行元（Supervisor），该主执行元将依次委托给工作执行元（子执行元）（round-robin fashion）。