メッセージングの混乱:パブ/サブ対マルチキャスト対ファンアウト

私は私の会社のメッセージング技術を評価してきましたが、私はいくつかの用語の概念の違いによって非常に混乱しました。

Pub/Sub vs Multicast vs Fan Out I am working with the following definitions:

  • Pub/Sub has publishers delivering a separate copy of each message to each subscriber which means that the opportunity to guarantee delivery exists
  • Fan Out has a single queue pushing to all listening clients.
  • Multicast just spams out data and if someone is listening then fine, if not, it doesn't matter. No possibility to guarantee a client definitely gets a message.

これらの定義は正しいですか?または、Pub/Subパターンとマルチキャスト、直接、ファンアウトなどのパターンを達成する方法?

私はすぐに使えるRabbitMQの定義を私たちのアーキテクチャに取り込もうとしていますが、私たちはアプリの仕様書を書こうとしている瞬間にサークルを回っています。

誰かが私に正しいかどうか私に助言することができますか?

35

3 答え

私はあなたの3つの言葉を比較するのは混乱しています。 RabbitMQでは、FanoutとDirectは交換タイプです。 Pub-Subは一般的なメッセージングパターンですが、交換タイプはありません。そして、あなたは3番目に重要な交換タイプ、つまりTopicについて言及しませんでした。実際には、同じバインディングキーを持つ複数のキューを宣言するだけで、トピック交換でファンアウト動作を実装できます。また、ワイルドカードバインディングキーとして * を使用してキューを宣言することで、トピック交換の直接動作を定義できます。

Pub-Subは、一般に、アプリケーションがいくつかのサブスクライバによって消費されるメッセージをパブリッシュするパターンとして理解されています。

RabbitMQ/AMQPでは、メッセージは常にExchangeに公開されることを覚えておくことが重要です。次に、キューへのルートを交換します。キューは、メッセージを購読者に配信します。交換の振る舞いは重要です。トピック交換では、ルーティング決定を行うために、パブリッシャからのルーティングキーとサブスクライバからのバインディングキーが一致します。バインディングキーにはルーティングの決定にさらに影響するワイルドカードパターンを使用できます。より複雑なルーティングは、メッセージヘッダーの内容に基づいて行われます。ヘッダ交換型

RabbitMQはメッセージの配信を保証するものではありませんが、適切なオプション(永続的なメッセージの場合は配信モード= 2)を選択し、メッセージを破棄しないようにアプリケーションを実行する前に交換およびキューを宣言することにより、

35
追加された
注:トピック交換を使用してファンアウトまたはダイレクトをシミュレートすると、特定の交換タイプのいずれかを使用する場合よりも少し遅くなります。これは、古典的なパフォーマンス/柔軟性のトレードオフです。
追加された 著者 cdeszaq,
@iddqd:あなたが言っていることを理解していません。 AMQPにはタスクキューのようなものはありません。トピック交換を使用してファンアウト交換をシミュレートします。コンシューマは同じバインディングキーを持つ異なるキュー名を宣言し、バインディングキーと一致するルーティングキーを持つこのトピック交換へのメッセージは、各キューにファンアウト(コピー)されます。消費メッセージは、メッセージがキューにルーティングされた後に発生します。詳細については、この質問を参照してください。 stackoverflow .com/questions/5253557 /…
追加された 著者 Michael Dillon,
それは真実ではない。タスクキューを使ってファンアウトをシミュレートすることはできません。それは、最初に消費した後に物語が終わったからです。
追加された 著者 iddqd,
申し訳ありませんが、私の間違いは、AMQP +セロリを検索している間に答えています。
追加された 著者 iddqd,
これは私が望んでいた答えのようなものです。トピックが他の交換タイプをシミュレートできるので、有用であることは分かりませんでした。
追加された 著者 ghostJago,

あなたの定義はかなり正しいです。保証された配信は、pub/subのみに限定されず、ファンアウトでも行うことができます。そして、はい、パブ/サブはファンアウト、ダイレクトなどの特定の方法で実現できる非常に基本的な説明です。

あなたが役に立つかもしれないより多くのメッセージングパターンがあります。詳細については、エンタープライズ統合パターンをご覧ください。

7
追加された
はい、素晴らしい本です。
追加された 著者 Michael Dillon,
EIPブックを提案するための+1。
追加された 著者 T.Rob,

From an electronic exchange point of view the term “Multicast” means “the message is placed on the wire once” and all client applications that are listening can read the message off the “wire”. Any solution that makes N copies of the message for the N clients is not multicast. In addition to examining the source code one can also use a “sniffer” to determine how many copies of the message is sent over the wire from the messaging system. And yes, multicast messages are a form the UDP protocol message. See: http://en.wikipedia.org/wiki/Multicast for a general description. About ten years ago, we used the messaging system from TIBCO that supported multicast. See: 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

1
追加された