Play Framework:Jobs对无状态模型的影响

Question

Play框架的一大优点是它完全无状态,只有面向请求/响应.这非常好,因为它允许我将我的应用程序部署到云端并扩展负载均衡器后面的播放实例数量,而不必担心状态(会话)复制......

但是,最近,我需要在HTTP请求之外执行一些应用程序逻辑,并发现Play可以定义完全由框架管理的作业.听起来很棒,但它提出了一个问题:这些工作如何适应Play使用的无状态模型？

假设我有一个需要每小时运行一次的维护任务,我为此定义了一个预定的作业.如果我然后在负载均衡器后面部署多个Play实例,那么该作业是否会在每个实例上同时启动？如果是这样,那么处理需要"专门"运营的工作的好方法是什么？

我正在考虑在非集群服务器上创建一个新的播放实例,重新使用现有(集群)实例的JPA模型(从而连接到同一个数据库).此新实例仅包含维护作业,并且由于它托管在非群集服务器上,因此不存在同时运行作业的风险.同时,这将允许我保持现有的群集实例完全无状态且易于托管/负载平衡.这会是一个好方法吗？

Answer 1

我也建议将工作分组.您可以在数据库中设置信号量以确保只有一个作业正在运行.另一个想法是看看Akka-Framework,它将包含在Play 2.0中.我认为它已经建立了处理这个问题的机制,但我不确定.我没有akka的经验.

Answer 2

正如neils所提到的,在DB中保留一个标志有助于找出作业是否已经在运行.我使用带有其他标志的db信号量来给我工作状态和额外信息.

您可以做的另一件事是使用Play.id来计算并定义应该运行作业的实例.我们使用"play start - %prod","play start - %prod1"...来启动我的doJob()方法中的应用程序和以下内容:

doJob(){
   if ("prod".equalsIgnoreCase(Play.id)) {
   ...
   }
}