RabbitMQは非常に柔軟性があり、要件を満たすためのさまざまな交換とキューの設計ソリューションがあります。
しかし、まず、私たちはキューと消費者との関係や、基本的なルールを理解しておく必要があります
- メッセージタイプが唯一のすべての消費者のによって消費されるようにしたい場合は、あなたが言ったように、あなたが必要ワーカーキューには、すべてのコンシューマーがそれにサブスクライブする必要があります。
- コンシューマごとにメッセージタイプを使用する場合は、コンシューマごとにキューを用意する必要があり、各コンシューマは独自のキューにのみサブスクライブします。
上記の理解に基づいてキューの数が明確な場合。残りのものは、メッセージをこれらのキューにルーティングする方法です。多くのソリューションがあります。以下はいくつかの例です。
1つの実行可能な解決策は、メッセージタイプごとに1つずつ、2つの交換を作成することです。
| message type | exchange name | exchange type | bound queues |
|------------------------------------------------------------------|
| type_1 | exchange1 | fanout | shared_queue |
| type_2 | exchange2 | fanout | queue1,queue2,... |
あなたに2つのメッセージタイプを公開するための唯一の交流を持つようにしたい場合は、別の可能な解決策は、ある、「直接」交換タイプを使用します。
| routing_key | binding_key | bound queues |
|-----------------------------------------------|
| type_1 | type_1 | shared_queue |
| type_2 | type_2 | queue1,queue2,... |
一つの交換がにバインドされた複数のキューを持っている可能性を同じバインディングキーを使用しています。したがって、パブリッシュルーティングキー(type_1)を使用してメッセージタイプ1をパブリッシュする場合、shared_queueだけがメッセージを受信します。パブリッシュルーティングキー - 「type_2」を使用してメッセージタイプ2をパブリッシュすると、すべてのqueue1、queue2、...がメッセージを受信します。
メッセージごとに異なるバインディングキーを使用すると、より多くのメッセージタイプがあり、同じルーティングキーを使用したくない場合に、実際のケースには適していない可能性があります。その場合は、代わりに「トピック」交換タイプを使用することをおすすめします。
| routing_key | binding_key | bound queues |
|-----------------------------------------------|
| type_1.1 | type_1.* | shared_queue |
| type_2.2 | type_2.* | queue1,queue2,... |
詳細な回答ありがとうございます。私が正しく理解していれば、単一の消費者が複数のキューを購読することができますか? Rabbitのチュートリアルから、コンシューマが単一のキューに登録できるという印象を得ました – user1102018
"コンシューマ"がコンシューマアプリケーションをアプリケーションとして定義している場合、もちろんそれは必要な数のキューにサブスクライブできます。アプリケーションでは、複数の接続を持つことができます。また、複数のチャネルを1つの接続で共有することもできます。各チャネルは異なるキューに加入しています。 –
ありがとうございます。私はあなたが提案したものを試してみる。 – user1102018