MySQL をジョブ キューとして使用したいと考えています。複数のマシンがジョブを生成および消費します。ジョブをスケジュールする必要があります。毎時間実行されるものもあれば、毎日実行されるものもあります。
それはかなり簡単に思えます: 各ジョブに「nextFireTime」列があり、ワーカー マシンに nextFireTime でジョブを検索させ、レコードのステータスを「inProcess」に変更し、ジョブが終了したら nextFireTime を更新します。
問題は、労働者が静かに死ぬときに発生します。nextFireTime を更新したり、ステータスを「idle」に戻したりすることはできません。
残念ながら、ジョブは長時間実行される可能性があるため、inProcess が長すぎるジョブを探すリーパー スレッドはオプションではありません。機能するタイムアウト値はありません。
信頼性の低いワーカー マシンを適切に処理する設計パターンを提案できる人はいますか?
MySQL をジョブ キューとして使用することは、RDBMS の通常の目標にはあまり適合しないため、一般的には苦痛に終わります。ユーザー「toong」はすでにhttps://www.engineyard.com/blog/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-youにリンクされています。それについて言うべき多くの興味深いこと。信頼できない労働者は複雑な問題の 1 つにすぎません。
ジョブの分散を処理するためのシステムは非常に多くありますが、そのほとんどは、高度なキューイング機能とスケジューリング機能によって特徴付けられます。単純な FIFO 側には、Resque、Celery、Beanstalkd、Gearman などがあります。洗練されたものとしては、GridEngine、Torque/Maui、PBS Pro などがあります。Amazon サービスへの依存を許容できる場合は、新しい Amazon Simple Workflow システムを強くお勧めします ( EC2 にいる必要はないと思います)。
元の質問に対して: 現在、ノードのジョブがまだアクティブであるかどうかを判断できるノードごとのスーパーバイザーを実装しており、アクティブな場合はジョブ モニターにハートビートを送信しています。それは苦痛ですが、あなたが発見し続けているように、管理しなければならない詳細とエラーケースがたくさんあります。ただし、ほとんどの場合、このドメインについて学習し、最初から適切にシステムを構築することで、自分に有利になるように勧める必要があります。
多分このように
ワーカーがジョブを取得すると、プロセス ID または別の一意の ID をジョブのフィールドに追加できます。
次に、別のテーブルで、すべてのワーカーが生きているという値を更新し続けます。「私は生きている」フィールドを更新するとき、他のすべての「前回の労働者が生命の兆候を示した」をチェックします。1 つのワーカーが制限を超えている場合は、作業中のすべてのジョブを見つけてリセットします。
つまり、ウォッチドッグは、ジョブ自体ではなく、ワーカー プロセスで機能します。
1 つのオプションは、ジョブがべき等であることを確認し、複数のワーカーが特定のジョブを開始できるようにすることです。どのワーカーがジョブを完了するか、または複数のワーカーがジョブを完了するかは問題ではありません。ジョブは、複数の完了が適切に処理されるように設計されているためです。おそらくワーカーは結果を提供するために競争し、敗者は結果を保持するスロットがすでにいっぱいであることに気づき、結果をドロップするだけです。
別のオプションは、大きな仕事をしないことです。長時間実行されているジョブを中間ステップに分割します。ジョブが (たとえば) 1 分以上かかる場合は、中間結果を新しいジョブとして保存し (何らかの方法で古いジョブへのリンクを付けて)、新しいジョブを再びキューに入れることができるようにします。もう 1 分間の作業を行います。