web-dev-qa-db-ja.com

RabbitMQでのトピック交換と直接交換

RabbitMQを使用するアプリケーションがあり、階層間でメッセージを渡すためのいくつかの異なるキューがあります。

最初は、メッセージタイプごとに1つずつ、複数の直接交換を使用することを計画していましたが、異なるルーティングキーバインディングを使用するキューで単一のトピック交換を行うことで同じことが実現できるようです。

単一の交換を維持することは、維持するのが少し簡単だと思われますが、他の方法よりも一方向でそれを行う利点があるかどうか疑問に思いましたか？

オプション1、複数の直接交換を使用：

ExchangeA (type: direct)
-QueueA

ExchangeB (type: direct)
-QueueB

ExchangeC (type: direct)
-QueueC

オプション2、単一トピック交換を使用：

Exchange (type: topic)
-QueueA  (receives messages from exchange with routing key of "TypeA")
-QueueB  (receives messages from exchange with routing key of "TypeB")
-QueueC  (receives messages from exchange with routing key of "TypeC")
rabbitmqmessage-queuerabbitmq-exchange
45
Mun

両方のモデルが、実行中の1つのブローカーを使用して実装されると見なされていると仮定すると、ほとんど違いはありません。

オプション2は、この種のルーティングの問題を解決するために（少なくとも私の逸話的な経験では）現実の世界でより一般的であり、解決するためにトピックエクスチェンジが存在するのはまさに課題です。

発生する可能性のある唯一の違いは、ルーティング速度に関連します。トピック交換（#や*のようなワイルドカードを含めることができる）で使用されるルーティングキー技術と比較した場合、RabbitMQでのExchangeルーティング（常に正確な文字列一致に基づく）が高速かどうかはわかりません。私の考えでは、Exchangeの差別はより迅速になりますが、自分で実験して調べるか、RabbitMQチームに連絡して尋ねることができます。

最後に、オプション1で多くのキューを使用すると、Exchangeが比例して増加します。それはメンテナンスの頭痛の種のように聞こえます。キューの数が少ない場合は、それほど問題にはなりません。

34
Brian Kelly

実際、アプローチ2は、複数のルーティングキーに単一のキューを使用する柔軟性を提供するため、より優れています。

Exchangeトピック

QueueA-- binding key = India.Karnataka.*

India.Karnataka.bangalore、India.Karnataka.Mysoreなどのルーティングキーを使用して、メッセージをトピック交換にルーティングできます。

上記のメッセージはすべてQueueAに送信されます。

直接交換

しかし、アプローチ1で複数の直接交換を作成する理由については理解していませんでした。単一の直接交換を持ち、各キューが一意のキーでバインドされた複数のキューを持つことができます。

QueueA-- binding key = Key1
QueueB-- binding Key = Key2
QueueC-- binding Key = Key3

すべてのkey1メッセージはQueueAに送られ、Key2はQueueBに送られます...単一の直接交換を維持できます。

13
vinod hy

負荷の少ない単一の小さなノードの場合、違いはほとんどありません。上記の理由から、ほとんどの人はオプション2を使用します。

システムを設計するとき、これが将来どのように拡大するかを自問する必要があります。

どのようにスケーリングしますか？
スケーリングに必要ですか？将来、高可用性クラスターを追加しますか？ルーティングは変わりますか...

オプション2は、ほとんどの場合により多くの柔軟性を提供します。

これにより、独自のキューを使用して新しいコンシューマをExchangeに接続し、メッセージフローのサブセットまたはすべてを簡単にキャプチャできます。 （これらのキューは、クラスター内の他のノード上にあるか、フェイルオーバーを提供するnノードにミラー化されている可能性があります）典型的な使用例は、4番目のキューを使用してすべてのメッセージを記録することです。

ボトルネックが処理側にある場合は、メッセージトピックをさらに細分化し、パブリッシャーを変更せずに、ある程度の優先順位付けを実行することもできます。例：専用のコンシューマーによって処理されたToppicA.urgent、最終的に処理されたTopicA.log。

非常に具体的なパフォーマンス要件がない限り、簡単な答えはオプション2です。たとえば、5万msg/sを超える持続レートを処理する必要がある場合、専用ノードでオプション1を検討する必要がありますが、通常のフローオプション2は、スケーリングと保守が簡単になります。

6
Abelgo

直接交換は複数のルートもサポートします（ https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchange-direct ）。

ExchangeA (type: direct)
-QueueA
-RoutingA

ExchangeB (type: direct)
-QueueB
-RoutingB

ExchangeC (type: direct)
-QueueC
-RoutingC
0
user763694