RabbitMQシャベルを使用する場合と、フェデレーションプラグインを使用する場合
私が働いている会社では、RabbitMQをメインメッセージバスとして使用したいと考えています。私たちが持っているアイデアは、すべての単一のアプリケーションが内部通信に独自の仮想ホストを使用し、シャベルまたはフェデレーションプラグインを介して特定のタイプのイベントを複数の仮想ホスト間で共有できるようにすることです（複数のマシン（クラスター化されていない場合もあります）） 。内部通信と公開イベントを分離し、セキュリティをアプリケーションごとに調整できるようにするために、vhostごとのアプリケーションを選択しました。
RabbitMQ Webサイトで公開されている情報に基づいて、シャベルを選択する必要がある場合、またはフェデレーションプラグインを選択する必要がある場合、取得できません。
RabbitMQには次のものがあります 説明 何を使用するか：
通常、フェデレーションが提供する以上の制御が必要な場合は、シャベルを使用してインターネット上のブローカーをリンクします。
フェデレーションを選択したときに不足しているシャベルの細粒度制御とは何ですか？
現時点では、フェデレーションプラグインが提供するREST APIを介してvhost-communication間を自動化できるため、フェデレーションプラグインを好むと思います。シャベルの場合は、仮想ホスト間でイベントを共有するたびに、シャベルの構成とRabbitMQインスタンスの再起動を行います。
現在、.NETから接続するクライアントを使用して、Windows上でRMQを実行しています。近い将来、Java/Perl/PHPクライアントが参加します。
私の質問を要約するには：
- シャベルのきめ細かな制御とは何ですか？
フェデレーションを選択しますか？ - シャベルを使用するときに仮想ホスト間通信を変更する唯一の方法は、configファイルを変更してインスタンスを再起動することです。
- セットアップ（アプリケーションごとの仮想ホスト）は意味がありますか、それとも完全にポイントがありませんか？
シャベルとキューは、RabbitMQノード間でメッセージを転送するためのさまざまな手段を提供します。
フェデレーションエクスチェンジ
フェデレーション交換では、キューをアップストリーム（ソース）ノードのキューに接続できます。さらに、ダウンストリーム（宛先）ノードでの交換は、アップストリームノードに発行されたメッセージのコピーを受信します。
フェデレーションエクスチェンジは、エクスチェンジエクスチェンジバインディングに似ています。つまり、（オプションで）アップストリームエクスチェンジからの限られたメッセージセットをサブスクライブできます。
フェデレーションキュー（注：これらはRabbitMQ 3.2.xの新機能です）
連合キューを使用すると、コンシューマはアップストリーム（ソース）ノードとダウンストリーム（宛先）ノードの両方でキューに接続できます。
本質的に、ダウンストリームキューはアップストリームキューのコンシューマであり、アップストリームキューに接続されたコンシューマと同じ方法でメッセージを処理する追加のダウンストリームコンシューマが存在することが期待されます。
ダウンストリーム（フェデレーション）キューによって消費されるメッセージは、アップストリームキューのコンシューマーには利用できません。
使用事例：
コンシューマーが1つのノードから別のノードに移行されている場合、フェデレーテッドキューにより、メッセージが失われたり、2回処理されたりすることなく、これが可能になります。
ユースケース： RabbitMQドキュメントから
典型的な用途は、同じ「論理」キューを多くのブローカーに分散させることです。各ブローカーは、他のすべての統合キューを上流に持つ統合キューを宣言します。 （リンクは、n個のキューで完全な双方向グラフを形成します。）
Shovel
一方、シャベルは、「アップストリーム」キューを「ダウンストリーム」交換に接続します。 （シャベルのドキュメントでは、フェデレーションのドキュメントと同じセマンティクスでノードを説明していないため、用語を引用符で囲みます。）
シャベルはキューからのメッセージを消費し、宛先ノードの交換機に送信します。 （注：このパターンの一部として通常説明されていませんが、コンシューマーがオリジンノードのキューに接続するのを止めるものはありません。）
特定の質問に答えるには：
フェデレーションを選択したときに不足しているシャベルの細粒度制御とは何ですか？
シャベルはhaveを「アップストリーム」または「ダウンストリーム」ノードに常駐させません。独立したノードから構成および操作できます。
シャベルは、リンクのすべての要素（ソースキュー、キューのバインディング、宛先交換）を単独で作成できます。したがって、送信元ノードまたは宛先ノードのいずれに対しても非侵襲的です。
シャベルを使用するときに仮想ホスト間通信を変更する唯一の方法は、configファイルを変更してインスタンスを再起動することです。
これは一般に、シャベルの欠点として受け入れられてきました。
次のコマンド（注意：RabbitMQ 3.1.xでのみテストされ、非常に具体的なrabbitmq.configファイルのみを含む）シャベル設定を指定したファイルからリロードできます。 （この場合 /etc/rabbitmq/rabbitmq.config）
rabbitmqctl eval 'application:stop(rabbitmq_shovel), {ok, [[{rabbit, _}|[{rabbitmq_shovel, [{shovels, Shovels}] }]]]} = file:consult("/etc/rabbitmq/rabbitmq.config"), application:set_env(rabbitmq_shovel, shovels, Shovels), application:start(rabbitmq_shovel).'
。
セットアップ（アプリケーションごとの仮想ホスト）は意味がありますか、それとも完全にポイントがありませんか？
この決定は、ユースケースに依存します。仮想ホストは主に、キュー/エクスチェンジと許可されたユーザーの間の論理的な（およびアクセス）分離を提供します。
Shovelは、適切に設計された組み込みコンシューマのように機能します。送信元ブローカーとキューからのメッセージを消費し、送信先ブローカーと交換にそれらを公開できます。あなたはそれを行うためのアプリケーションを書くことができますが、シャベルはすでにそれを正しくしています-あなたが必要なのはキューから同じまたは別のブローカーの交換に移動するだけなら、シャベルはあなたのためにそれを行うことができます。正常に動作するアプリと同じように、交換/キュー/バインディングの宣言、再接続、ルーティングキーの変更などを行うことができます。ソースまたは宛先ブローカーに設定するか、サードブローカーを使用することもできます。基本的にAMQPクライアントです。
フェデレーション、一方、ブローカーを1つまたは複数のアップストリームブローカーに接続するために使用されます。または、ブローカーのチェーンを作成して、トポロジーを自由に曲げることもできます。交換またはキューをフェデレートできます。追加のキューをトピック交換にバインドしたり、ファンアウト交換を使用したりすることなく、複数のブローカーにメッセージを配信し、各キューから下流のブローカーにメッセージをシャベルします。
要約すると、フェデレーションはより高いレベルで動作しますが、ショベルはほとんどの場合、「よく」書かれたクライアントです。
シャベルを再構成するには、残念ながらブローカーを再起動する必要があります。
アプリごとの仮想ホストは本当に必要ないと思います。個別の仮想ホストなしで、アプリごとのユーザーをブローカーに追加できます。ただし、「vhost間でイベントを共有する」の意味がわかりません。