在 Heroku 上使用 Play Framework 的后台作业答案

【问题标题】：Background jobs with Play Framework on Heroku在 Heroku 上使用 Play Framework 的后台作业
【发布时间】：2023-03-26 10:50:01
【问题描述】：

在 Heroku 上并使用 Play Framework，是否需要设置后台作业处理器（使用 Akka/RabbitMQ/等）才能执行繁重的任务*？

我知道 Play 提供了在请求中异步执行任务的能力，但这是否足以避免需要后台作业处理器？在非 Heroku 部署的独立 Play 应用程序上，异步功能可以在一个进程中完成所有操作，但在 Heroku 应用程序上，这似乎还不够：根据书 Professional Heroku Programming，（第 254 页，在使用 Ruby 开发部分中），Web dyno 在收到请求和传递响应之间被阻塞，并且在此期间所有其他请求都排队。

如果需要后台作业处理器，是否有任何示例？我见过 Play 和 Akka、Play 和 Heroku 的例子，但不是所有三个都在一起。

*（对于繁重的任务，我通常是指需要回答的可能长时间运行的任务，例如复杂数据库查询的结果或提供给最终用户的 Web 服务调用，而不是触发和-忘记发送电子邮件之类的事情。

【问题讨论】：

在当前运行 Play 应用程序的 Cedar (*.herokuapp.com) 堆栈上，simultaneous connections are supported。您提到的网络测功机阻止仅在较旧的 Bamboo 堆栈上。

标签： scala heroku playframework-2.0 rabbitmq akka

【解决方案1】：

在使用 Play 时，您不需要明确的工作人员。 Play 2 的常见模式是在控制器中使用Async response，并在运行时间更长的进程中使用Akka。 Play Framework 网站上的所有示例都应该在 Heroku 上开箱即用。

【讨论】：

使用异步响应是否适合需要超过 30 秒才能完成的任务（即 web dyno 超时的时间）？
抱歉，刚刚看到您的回复。如果请求花费的时间超过 30 秒，那么您可以做几件事： * 每 20 秒左右发送一次 keep-alive。这将在路由器层保持连接打开。 * 使用队列并让客户端轮询。我们使用 Redis 来实现这一点。我们立即用 UUID 响应，Redis 中的内容，返回 202 带有 Location 标头，其中包含客户端可以轮询的位置，然后当工作完成时，Future 更新 Redis 并将结果发送回客户端下一次投票。