メッセージキューと複数のサブスクライバー
私のチームは、（特に）マイクロサービス間の通信にRabbitMQを使用することについて話し合っています。また、現時点では未定の方法（BoomiやIdocsなど）でデータをプッシュするSAPバックエンドもサポートしています。 RabbitMQについては、メッセージキューの一般的な概念と、それらのドキュメントを高レベルで確認して決定できたことを除いて、ほとんど何も知りません。一般的なパターンは、コンシューマーが1つ以上のキューにサブスクライブしているようで、高度な設定が可能なルールに基づいてRabbitがそれらのキューにプッシュしますが、個々のキューのメッセージは、削除される前に完全に「一度」しか読み取られません（これは確認などに関する多くのオプションがあるため、一般化）。
これは、各コンシューマーが個別のトピックのみを気にするセットアップの非常に単純なイメージです。 
これはより複雑なものですが、単一のトピックが複数のキューに分割されます。ただし、キューを構成するときは、トピックをどこに送信するかを知る必要があり、そのメッセージのコンシューマーごとに1つのキューが必要です。
代わりに私が想定しているのは、すべてのメッセージが通過する1つの巨大なメッセージパイプラインであり、個々のサブスクライバーがそれらに関連するメッセージを読んでいます。この概念に近いもの：
これの私の目標は、すべてを可能な限り疎結合にすることです。デザイン1または2では、新しい消費者が追加されるたびに、キューイングシステムを更新するか、交換する必要があります。 3番目の設計では、キューシステムは、それを消費しているものにとらわれず、メッセージを送信する必要があることだけを認識します。その後、コンシューマはキューを読み取るだけで、関連するメッセージのコピーを取得できます。
このデザインは意味がありますか？このようなシステムを望むのは私たちが最初にすることはできません。これはかなり一般的なニーズであるためです（変更はシステムで発生し、複数のコンシューマーがそれに対処する必要があります）。
あなたが提案している3番目の図では、コンシューマー1が最初にメッセージに到達すると（そしてACKSすると）、コンシューマー2と3はメッセージを受信しません。それがあなたが望むものなら、それで結構です。各コンシューマがメッセージを受信するようにする場合は、コンシューマごとに個別のキューが必要です。
3番目の図は、同じコンシューマーがデプロイされた複数のサーバーがある場合のシナリオとほぼ同じです。コンシューマー1が3つのサーバーにデプロイされている場合、どのサーバーが最初にメッセージを取得するかは問題ではありません。
懸念事項に答えるために、図1と図2では、キューシステムはどのキューが作成されるかを気にしません。むしろ、キューを作成してバインドするのはプロデューサーではなくコンシューマーであるため、プロデューサーは気にしません。プロデューサーはルーティングキーを含むメッセージをエクスチェンジにプッシュします。それがその仕事の終わりです。次に、新しいコンシューマを追加すると、キューが作成され、ルーティングキーを使用してエクスチェンジにバインドされます。
おそらく、Apache NIFIのようなものをメッセージのルーティング/変換に使用し、kafkaをメッセージブローカーとして使用できます。どちらもオープンソースオプションです。
プロデューサーは、正規化されたスキーマモデルに従ってメッセージをトピックに公開します>>>
Apache NIFIはメッセージを収集し、一般的なスキーマモデルからコンシューマーモデル（必要な場合）へのコンシューマーのニーズに従って変換を行い、それをコンシューマーの特定のトピックにルーティングします>>>
コンシューマ（多数）はさまざまなトピックにサブスクライブして、それらのメッセージを消費できます。
いくつかのハイライト、Kafkaのトピックは常にマルチサブスクライバーです。つまり、トピックには、0、1、または多数のコンシューマーがあり、そこに書き込まれたデータをサブスクライブできます。キューは本質的にはマルチサブスクライバー。Kafkaのトピックでは、注文と、少なくとも1回は消費者への保証が提供されます https://kafka.Apache.org/intro#kafka_mq
通常、プロデューサは、すべてのコンシューマが読み取る単一のキューにメッセージを貼り付け、1つだけがメッセージを取得するようにロックします。
ただし、3番目のシナリオは、すべてのコンシューマーが同じメッセージを受信し、それを処理するかどうかを決定した場合、見事に機能します。私はこのアプローチを何度も使用して大きな成功を収めてきましたが、メッセージを処理するコンシューマーを区別する方法が必要です。処理できない場合は、すべてを処理します。これはそのような問題ではない可能性があります。たとえば、UIはそのようなシステムを使用でき、メッセージは基準を通過するすべてのコンシューマ（UI要素など）に渡されます（たとえば、イベントが発生したときにマウスカーソルの下にあります）。
したがって、最終的には、ここでの答えは、メッセージがどのようなものであり、消費者がメッセージをどのように処理するかに依存します。
さらに読むために、私は zeromqガイド を見て、多くの異なるメッセージキューシステムとそれらの利点/欠点について詳細に説明します。