私はいくつかのモジュールで構成され、それらが互いに情報を共有することを要求するアプリケーションに取り組んでいます。例：モジュールがいくつかの情報（状態変数など）をパブリッシュし、特定の情報に関心のあるモジュールがそれを取得するパブリッシュ/サブスクライブシナリオ。または、関心のあるモジュールが情報について明示的に質問し、回答を得た要求/応答シナリオ。
私はさまざまなメッセージバスの実装、つまりD-bus、ØMQ、RabbitMQ、およびQPID（後者の2つはAMQPに基づいています）を調査してきました。しかし、誰かが、複雑で重いメッセージバスの実装を試す代わりに、問題を解決するために単にマルチキャストを使用しないのはなぜかと指摘しました。
マルチキャストが私の問題を本当に解決できるかどうかを確認し、2つのソリューションの長所と短所を理解するための経験が不足しているので、専門家に助けを求めたいと思います。よろしくお願いします。
大規模な大量生産環境でのメッセージバスとマルチキャストの両方の経験があり、問題について経験豊富なネットワークエンジニアと話し合ったことがあるので、非常に多くの人にブロードキャストする場合を除いて、ペストのようなマルチキャストは避けるべきだと言えます。ノード（数百）。
マルチキャストを使用する場合は、それが信頼性の低いプロトコルであることを理解する必要があります。メッセージが失われたり、複製されたりする可能性があります。マルチキャストを有効にするには、マルチキャストに加えて信頼性プロトコル（再試行、重複検出、再送信）を取得するために多くの時間を費やす必要があります。私が参照を見つけようとしているマルチキャストコマンドロボット戦車の軍隊テストについての良い逸話があります...基本的にあなたが「右に90度曲がり、右に曲がり、90度、発射」を戦車の列に送るとき右折メッセージを1つだけ受け取るものもあれば、3つ受け取るものもあります。これは、騒乱のレシピです。
共有する必要のある情報の種類に応じて、いくつかのオプションがあります。
彼らが構成情報を共有している場合は、Zookeeperのようなものを見てください。信頼性が高く、軽量で、使いやすいです。共有状態の最新の値は常に利用可能であり、永続化されます。メッセージバスでは、モジュールがダウンして最後の構成メッセージを見逃した場合に備えて、再送信プロトコルが必要です。
メッセージバスに関しては、複雑になる可能性があります。ただし、必ずしもZeroMQをそのカテゴリに分類するわけではありません。メッセージバスをエミュレートできますが、それはポイントツーポイントメカニズムのようなものです。私はそれを本番環境で使用していませんが、私がそれを使って行った研究とプロトタイピングは非常に好意的でした。
もう1つのオプションは、Oracle Coherence、GridGain、GigaSpacesなどの分散データグリッドです。繰り返しになりますが、これはインストールと保守を行う別のアプリケーションであるため、複雑さが増しますが、データグリッドには多くの用途があります。
もう1つのMQオプションはHornetMQです。私はそれを使用していません（SonicとMQシリーズの両方の2つの商用MQを社内で使用しています）が、いくつかの好ましい比較を見てきました。
D-Busは、単一のマシンでの通信用に最適化されているようです。FAQでは、ピアツーピア、クラスタリング、またはその他の同様のことを行っている場合は、他の場所を探すことをお勧めします。警告：私はD-Busを使用したことがないので、基本的に今読んだ情報を逆流させています。
パケット/メッセージがドロップまたは失われることを心配していますか？メッセージバスはこれらの懸念を処理または軽減できますが、マルチキャストはデフォルトでは処理されません。