何かを使用して、それぞれが異なるオペレーティングシステムの異なるマシンで実行されている複数のコンシューマー/プロデューサーとシステムを調整する必要があります。私はこれを行うためにMySqlを使用することを研究してきましたが、それは途方もなく難しいようです。
私の要件は単純です。消費者/プロデューサーをいつでも追加または削除できるようにしたいので、相互に依存するべきではありません。当然、データベースは2つをうまく分離します。
MySql用のQ4Mメッセージキュープラグインを見てきましたが、使用するのが複雑なようです。
システムを可能な限り最適に構築する方法について、いくつかの情報が本当に必要です。
何かを使用して、それぞれが異なるオペレーティングシステムの異なるマシンで実行されている複数のコンシューマー/プロデューサーとシステムを調整する必要があります
それはメッセージキューです。他の選択肢を追求しないでください。他のすべて（つまり、挿入と削除を伴うデータベースの使用）は、非常に遅く、面倒です。
（1）データベースが遅い、（2）データベースが巨大で複雑である、（3）各トランザクションを潜在的に遅くするロックと競合の問題があるため、データベースを使用して大きくて遅いメッセージキューを構築すると、実際にはうまくいかないことがよくあります。 4）問題に値するよりもはるかに多くのオーバーヘッドがあります。
多数のメッセージキューソリューションがあります。
Q4Mを機能させることができない場合は、別の場所に移動する必要があります。
http://en.wikipedia.org/wiki/Message_queue
そのようなシステムを構築することは実際には（かなり）複雑です。（もちろん実行可能であるため、私は公平に言います）。
複数のプロデューサーと1つのコンシューマーがある場合、それは簡単です。すべてのプロデューサーは同時に書き込みを行い、単一のコンシューマーはデータが表示される（コミットされる）とすぐにデータを読み取ります。
ただし、複数のコンシューマーでスケーラビリティが必要な場合は、簡単ではないロックスキームを作成する必要があります。（2つのコンシューマーに行がディスパッチされないようにする必要があります。これは、データベーストランザクションとロックでは簡単に実現できません。単純なソリューションでは、コンシューマーが1つしかない場合と同様に、すべてのメッセージ配信がシリアル化されます。 ）。
組み込みのソリューションを使用することをお勧めします。同様の質問についてもこの質問を読むことができます。
サードパーティのソフトウェアがなくても実現可能だと思います。
私の最初のデザインは次のようになります。
トランザクション要件のため、InnoDBはストレージエンジンの論理的な選択です。また、分離レベルを慎重に選択する必要があります。私の最初の推測は、ファントム読み取りを回避するために「シリアル化可能」ですが、おそらくより弱いレベルも可能です。
パフォーマンスとスケーラビリティが問題になる場合は、「実際の」メッセージングソリューションの使用を検討する必要があります。展開すると、パフォーマンスやスケーラビリティの問題が発生する可能性があります。
状況によります。
私の場合、1人のプロデューサーだけが1日に数千のメッセージを作成し、数人の消費者が次の24時間でこれらのメッセージを消費し、それぞれが完了するまでに数分かかります。したがって、mysqlは私の要件を満たしていると思います。トランザクションを使用して、コンシューマー間の一貫性を確保できます。
それがお役に立てば幸いです。