ジョブのスケジューリングに Quartz を使用するアプリケーションに取り組んでいます。スケジュールされるジョブは、プロパティ ファイルを読み取ることによってプログラムで作成されます。私の質問は次のとおりです。複数のノードのクラスターがある場合、これらのうちどれがプログラムでスケジュールを作成する必要がありますか? これらのうちの1つだけですか?それとも全部?
3 に答える
私は、特にユーザーが特定のタスクを実行する Quartz ジョブを作成できる Web アプリで Quartz を使用しました。
少なくともジョブ名がジョブごとに異なる場合、そのアプリで問題は発生していません。異なるグループ名を持つこともできます。私の記憶が正しければ、ジョブグループとジョブ名の組み合わせがジョブ キーを形成します。
いずれにせよ、異なるノードから実行するジョブを作成することに問題はありませんでしたが、当時のクォーツ (約 6 か月前、これが変更されたとは思いませんが、確かではありません) は、クラスター内のジョブを停止する可能性を提供しませんでした。 、停止コマンドが実行されたノードでのみジョブを停止できました。
代わりに、アプリケーションの起動時に一定数のジョブを作成するだけの場合は、ジョブ名/グループが各ノードの同じプロパティ ファイルから読み取られ、競合が発生するため、そのジョブをノードの 1 つに委任することをお勧めします。
それらすべてで作成してみましたか?名前が重複しているため、競合が発生すると思います。ですから、メンバーの一人が起動時にスケジュールを作成する必要があると思います。
あなたが言うように、それらがプロパティで事前定義されている場合、クラスターのシステムスケジューリングジョブは1つだけにする必要があります。すべてのシステムがそれを行った場合、不必要にジョブを再作成し、すべてのサーバーが同じジョブとトリガーを作成または削除すると、ジョブを奇妙な状態にする可能性があります。
ジョブのプロパティを 1 つのサーバーに展開するだけで、1 つのサーバーだけがそれらを作成しようとします。
ジョブをスケジュールする目的で別のアプリを作成し、一度だけ実行することができます。
これらが Web サーバーの場合は、スケジューリング プロセスをトリガーする単純な安全な REST API を作成できます。次に、自動化されたスクリプトを記述して API にアクセスし、デプロイの一部として、または必要なときにいつでもジョブのスケジューリングを開始できます。ロード バランサーの背後に複数のサーバーがある場合は、1 つのサーバーのみに移動し、クォーツがデータベースにバックアップされたジョブストアに保存するジョブをスケジュールする必要があります。クラスタ内の他のノードは、次回データベースから更新するときにそれらを受け取ります。