游戏线程架构

Question

游戏线程架构

architectureplayframework-2.0

6

Play被描述为一种“反应式”框架，适用于异步编程。我想更多地了解Play的架构，主要有：

它是否具有事件循环？
它是否有许多Akka Actor系统？它们是否由多个线程池支持？
如果是这样，那么有多少个线程池以及它们的目标是什么（路由、请求处理、Promise兑现、Anorm等）
我们可以在哪个执行线程上阻塞（在哪里可以进行一些昂贵的计算）？我们绝对不应该阻塞哪个执行线程？

任何关于此的资源/ wiki/建议都非常有帮助。谢谢。

- Pablo Fernandez

2个回答

1

请查看Akka默认配置和Play! wiki上的演员列表。

- ndeverge

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Julien Richard-Foy · Accepted Answer

注意：以下内容适用于Play！2.1.x。有关Play！2.0.4，请参见nico_ekito的答案。

与客户端的交互可以总结如下图表：

（注：原文中的chart可能指的是图表或者流程图，具体含义需要根据上下文来理解）

Play!’s architecture

Play的HTTP处理程序（构建在Netty之上）位于其自己的执行上下文中。当它接收到请求时，它会尝试根据URL（使用应用程序的conf/routes文件）找到要调用的应用程序入口点。此时，仅HTTP请求的标头加载在内存中。

然后，调用入口点。通常情况下，它是一个操作，如果有余下的正文，则会加载它。这发生在不同的执行上下文中，即Play！“用户”执行上下文，定义为可以在应用程序的conf/application.conf文件中配置的Akka actor调度程序。

最后，在一个操作内部，您可以执行异步调用（例如调用Web服务）。所有这些异步调用都使用Scala的Future API，因此它们使用在调用站点范围内可用的执行上下文。因此，您可以使用Play！“用户”执行上下文（定义在play.api.libs.concurrent.Execution.defaultContext中）。

总之，Play！为以下任务使用不同的执行上下文：

接收请求（Netty HTTP处理程序）；
调用操作（“用户”执行上下文）。

您可以自由地为异步计算使用任何执行上下文（包括Play！“用户”执行上下文）。

这个想法是所有用户代码默认使用Play！“用户”执行上下文。如果您阻塞它，您将无法运行更多的用户代码，但可以继续做其他事情。

如果您正在进行大量计算，我建议您使用专用的执行上下文。