11

Play フレームワークの優れた点の 1 つは、完全にステートレスであり、リクエスト/レスポンス指向のみであることです。状態 (セッション) のレプリケーションについて心配することなく、アプリをクラウドにデプロイし、ロード バランサーの背後でプレイ インスタンスの数をスケーリングできるため、これは非常に便利です...

しかし最近、HTTP リクエストの外部でいくつかのアプリケーション ロジックを実行する必要があり、Play にはフレームワークによって完全に管理されるジョブを定義できる可能性があることがわかりました。素晴らしいように聞こえますが、疑問が生じます: これらのジョブは、Play で使用されるステートレス モデルにどのように適合するのでしょうか?

1 時間ごとに実行する必要があるメンテナンス タスクがあり、そのためにスケジュールされたジョブを定義するとします。その後、複数の Play インスタンスをロードバランサーの背後にデプロイすると、そのジョブは各インスタンスで同時に開始されますか? もしそうなら、「排他的に」実行する必要があるジョブを処理するための良いアプローチは何でしょうか?

既存の (クラスター化された) インスタンスの JPA モデルを再利用して (したがって、同じデータベースに接続して)、クラスター化されていないサーバーに新しいプレイ インスタンスを作成することを考えていました。この新しいインスタンスにはメンテナンス ジョブのみが含まれ、クラスター化されていないサーバーでホストされているため、ジョブが同時に実行されるリスクはありません。同時に、これにより、既存のクラスター化されたインスタンスを完全にステートレスに保ち、ホスト/負荷分散を容易にすることができます。これは良いアプローチでしょうか？

4

3 に答える 3

5

ジョブもクラスター化することをお勧めします。データベースにセマフォを設定して、1 つのジョブのみが実行されるようにすることができます。もう 1 つのアイデアは、Play 2.0 に含まれる予定の Akka-Framework を調べることです。この問題を処理するメカニズムが組み込まれていると思いますが、よくわかりません。私はakkaの経験がありません。

于 2011-10-16T16:10:29.990 に答える
2

Play Frameworkのソースコード（クラスJobとJobsPlugin）をざっと見てきたので、ジョブが一定の時間間隔ごとに1回だけ実行されることが重要な場合（醜いハックを導入せずに）、これらをクラスター環境で使用するのは適切ではないと思います。

私は3つの可能な解決策を見ます：

  1. クラスタリングをサポートするジョブスケジューラを使用します。明らかな選択はクォーツです。PlayはQuartzの一部（CRON式を解析するため）も使用しますが、スケジューリングを行う部分は使用しません。

  2. Play 2を使用する場合は、スケジューラーを提供するAkkaを使用する可能性があります。

  3. 2回実行されても問題にならないようにジョブを変更します（一部のユースケースでは可能です）。

于 2012-11-19T16:05:51.370 に答える