我是 akka 演员的新手。我已经阅读了 akka 官方文档，但仍然不明白 actor 与线程模型相比是如何工作的。
让我们举一个这样的简单例子。我有一个传统的 HttpServer，它在线程池中有 10 个线程。当有 20 个请求同时到来时，HttpServer 将委托线程池中的所有 10 个线程来处理前 10 个请求，其余的将在网络接口中排队等待线程接起。
基于 actor 的 HttpServer 将如何应对同样的问题？是否所有请求都在委托的参与者面前排队，以按顺序处理它们并将消息发送给其他参与者？如果是这样，这就是我不明白actor如何提供比线程模型更好的性能的一点，因为只有1个actor按顺序处理20个请求不能比10个线程同时处理20个请求快。
我想了解的是，当多个请求同时聚集在一起时，演员如何反应？ ，而不是actor如何处理和排队邮箱中的消息，它已经在文档中出现了很多。有人可以模拟此示例中演员的工作步骤吗？
【问题讨论】：
标签： multithreading akka actor
让我试着给出一个有点笼统的答案，希望能在高层次上为你澄清一些事情。
请求被分配给一个线程，直到请求得到满足。线程可能会阻塞，但不一定要释放以处理另一个请求。高性能的 http 服务器可以复制参与者模型中的行为类型（通过多个线程的基于消息的流），直到通常调用用户代码为止。
请求的消化通过参与者处理路由解析、处理请求和呈现响应来进行（例如，结果可能会有所不同）。在这个流程的各个点，可以分配一个线程来处理不同的请求。理论上，所有 20 个请求都可以通过 Actor 模型移动，尽管任何时候只有 10 个处于活动状态。
使用诸如 akka-http（基于 akka-streams，基于 akka-actors）之类的框架的一个好处是用户代码可以作为流式元素参与整个流程，从而允许可能在线程模型中阻塞的操作利用非阻塞 I/O，允许线程被释放到另一个请求的 I/O 待决解决方案。例如，http 服务可以充当 RESTful 客户端并与其他（可能是多个并行的，通过参与者）服务联系 - 线程将被释放以处理其他请求，等待对此类传出 HTTP 流量的响应。
参与者模型形式化了一组（可以说是最佳）围绕有效管理线程的实践。
【讨论】：
这在很大程度上取决于您的参与者（系统）配置，但很有可能您将有 20 个参与者坐在一个普通的 router（例如 RoundRobin 路由器或 SmallestMailbox 路由器）和 10 ThreadPoolExecutor 调度程序中的线程，在这种情况下，您的 Akka 服务器的行为将与您的传统服务器类似 - Actor 的实现方式与 Runnable 或 Callable 在传统服务器中的实现方式将有所不同服务器，但在任何一种情况下，您都会有一个由 20 个工作人员组成的池在一个由 10 个线程组成的池上运行。
【讨论】：