私は、メッセージング キューを使用して、分散プロデューサー/コンシューマー システムに取り組んでいます。私が並列化に興味を持っているのは消費者側であり、私はそのために持っているものに満足しています.
しかし、プロデューサーについてはどうすればよいかわかりません。システムのプロデュース部分の負荷はそれほど高くないので、一度に実行する必要があるのは 1 つのプロデューサだけですが、起動、停止、再起動、および主に監視など、信頼できる管理方法が必要です。プロデューサー ホストが失敗した場合、別のホストがピックアップできます。
それが役立つなら、ジョブをキューに入れるコンシューマ アルゴリズムに満足しています。これは、一定期間ダウンして、ダウン中に発生したものを取得する耐障害性があるためです。
これを行うためのツールまたは少なくとも既知のパターンがあり、車輪を再発明しないと確信しています。
私はrabbitmqを使用していますが、activemqを使用したり、必要に応じてストームなどにリファクタリングしたりすることもできます.私のコードは今のところ複雑ではありません.
それについて数週間考えた後、最も簡単な解決策が頭に浮かびました。実際、私はそれに非常に満足しています。これまでのところうまくいっているようです。
私は、ts と呼ばれる単一のタイムスタンプ フィールドを持つ、heartbeat と呼ばれる私の DB で最も単純なテーブルを作成しました。これは、常に単一の行を持つことを意図しています。
私はすべての潜在的なプロデューサを 5 分ごと (クォーツ) に開始し、ts フィールドが now() - 5 分より古い場合、テーブルの更新を行います。update 呼び出しがブロックされているため、db スレッドの問題は発生しません。ここで、更新が > 0 を返した場合、実際に ts の値が変更されたことを意味し、実際の生成コード (キュー ジョブ) を実行します。update が 0 を返した場合、他の誰かが 5 分以内にテーブルを変更したため、テーブルは変更されていません。したがって、このプロデューサーは 5 分後に再度チェックするまで何もしません。
明らかに、5 分の値は構成可能であり、これにより、必要に応じて複数のプロデューサーを同時に実行できるように、小さな変更を加えた非常にきちんとしたアップグレードが可能になります。