メッセージングの混乱：Pub / Sub vsマルチキャストvsファンアウト
私は自分の会社のメッセージングテクノロジーを評価してきましたが、いくつかの用語の概念的な違いに非常に混乱しています。
Pub/Sub vs マルチキャスト vs ファンアウト私は次の定義で作業しています：
- Pub/Subパブリッシャーは各メッセージの個別のコピーを各サブスクライバーに配信します。つまり、配信を保証する機会が存在します。
- Fan Outは、すべてのリッスンしているクライアントにプッシュする単一のキューを持っています。
- マルチキャストはデータをスパム送信するだけで、誰かが聴いている場合は問題なく、そうでない場合は問題ありません。クライアントが確実にメッセージを受け取ることを保証する可能性はありません。
これらの定義は正しいですか？または、Pub/Subはパターンであり、マルチキャスト、ダイレクト、ファンアウトなどの方法でパターンを実現できますか？
すぐに使えるRabbitMQの定義をアーキテクチャに取り入れようとしていますが、現時点では、アプリの仕様を記述しようとしているだけです。
誰かが私が正しいかどうか私にアドバイスしてもらえますか？
比較する3つの用語の選択に混乱しています。 RabbitMQ内では、FanoutとDirectは交換タイプです。 Pub-Subは一般的なメッセージングパターンですが、交換タイプではありません。また、3番目の最も重要なExchangeタイプ、つまりトピックについても言及しませんでした。実際、同じバインディングキーを持つ複数のキューを宣言するだけで、トピック交換にファンアウト動作を実装できます。また、ワイルドカードバインディングキーとして*を使用してキューを宣言することにより、トピック交換の直接動作を定義できます。
Pub-Subは一般に、アプリケーションが複数のサブスクライバーによって消費されるメッセージを公開するパターンとして理解されています。
RabbitMQ/AMQPでは、メッセージは常にエクスチェンジに公開されることを覚えておくことが重要です。次に、キューへのルートを交換します。そして、キューはサブスクライバーにメッセージを配信します。交換の動作は重要です。トピック交換では、ルーティングの決定を行うために、パブリッシャーからのルーティングキーがサブスクライバーからのバインディングキーに一致します。バインディングキーには、ルーティングの決定にさらに影響するワイルドカードパターンを含めることができます。より複雑なルーティングは メッセージヘッダーのコンテンツに基づいて行われます ヘッダー交換タイプを使用することができます
RabbitMQはメッセージの配信を保証しませんが、適切なオプション（永続メッセージの配信モード= 2）を選択し、アプリケーションを実行する前に交換とキューを宣言してメッセージが破棄されないようにすることで、配信を保証できます。
定義はほぼ正しいです。保証付き配信はpub/subのみに限定されず、ファンアウトでも実行できることに注意してください。はい、pub/subは、ファンアウト、ダイレクトなどの特定の方法で実現できる非常に基本的な説明です。
役立つと思われるメッセージパターンが他にもあります。詳細については Enterprise Integration Patterns をご覧ください。
電子交換の観点からは、「マルチキャスト」という用語は「メッセージが一度ワイヤに配置される」ことを意味し、リスニングしているすべてのクライアントアプリケーションは「ワイヤ」からメッセージを読み取ることができます。 N個のクライアントに対してメッセージのN個のコピーを作成するソリューションは、マルチキャストではありません。ソースコードを調べるだけでなく、「スニファ」を使用して、メッセージングシステムからネットワーク経由で送信されるメッセージのコピー数を判断することもできます。はい、マルチキャストメッセージはUDPプロトコルメッセージの形式です。一般的な説明については、 http://en.wikipedia.org/wiki/Multicast を参照してください。約10年前、マルチキャストをサポートするTIBCOのメッセージングシステムを使用しました。参照： https://docs.tibco.com/pub/ems_openvms_c_client/8.0.0-june-2013/docs/html/tib_ems_users_guide/wwhelp/wwhimpl/common/html/wwhelp.htm#context=tib_ems_users_guide&file= EMS.5.091.htm