48

私が働いている会社では、RabbitMQ をメインのメッセージ バスとして使用したいと考えています。私たちが持っているアイデアは、すべての単一のアプリケーションが内部通信に独自の vhost を使用し、シャベルまたはフェデレーション プラグインを介して、特定のタイプのイベントを複数の vhost (おそらく複数のマシン (非クラスター化) でさえも) で共有できるようにすることです。 . 仮想ホストごとのアプリケーションを選択して、内部通信を公開イベントから分離し、アプリケーションごとにセキュリティを調整できるようにしました。

RabbitMQ Web サイトで公開されている情報に基づくと、シャベルを選択する必要があるとき、またはフェデレーション プラグインを選択する必要があるときはわかりません。

RabbitMQ には、いつ何を使用するかについて次の説明があります。

通常、フェデレーションが提供する以上の制御が必要な場合は、シャベルを使用してインターネット経由でブローカーをリンクします。

フェデレーションを選択したときに欠けているシャベルの細かい制御は何ですか?

現時点では、フェデレーション プラグインが提供する REST API を介して仮想ホスト間通信を自動化できるため、フェデレーション プラグインを好むと思います。シャベルの場合、仮想ホスト間でイベントを共有するたびに、シャベルの構成を変更して RabbitMQ インスタンスを再起動する必要があります。これについて私の考えは正しいですか？

現在、Windows で RMQ を実行しており、クライアントは .NET から接続しています。近い将来、Java/Perl/PHP クライアントが参加する予定です。

私の質問を要約すると：


  • フェデレーションを選択したときに欠けているシャベルの細かい制御は何ですか?
  • ショベルを使用するときに仮想ホスト間通信を変更する唯一の方法は、構成ファイルを変更してインスタンスを再起動することであるというのは正しいですか?
  • セットアップ (アプリケーションごとの vhost) は理にかなっていますか、それとも要点を完全に見逃していますか?
4

2 に答える 2

42

シャベルとキューは、ある RabbitMQ ノードから別のノードにメッセージを転送するためのさまざまな手段を提供します。

フェデレーテッド エクスチェンジ

フェデレーテッド エクスチェンジでは、キューを上流 (ソース) ノードのキューに接続できます。さらに、下流 (宛先) ノードでの交換は、上流ノードに発行されたメッセージのコピーを受け取ります。

フェデレーテッド エクスチェンジは、(オプションで) アップストリーム エクスチェンジからの限定されたメッセージ セットをサブスクライブできるという点で、エクスチェンジ間バインディングに似ています。

フェデレーテッド キュー (注: これらは RabbitMQ 3.2.x の新機能です)

フェデレーション キューを使用すると、コンシューマーは上流 (ソース) ノードと下流 (宛先) ノードの両方でキューに接続できます。

本質的に、ダウンストリーム キューはアップストリーム キューのコンシューマーであり、アップストリーム キューにアタッチされたコンシューマーと同じ方法でメッセージを処理する追加のダウンストリーム コンシューマーが存在することが期待されます。

ダウンストリーム (フェデレーション) キューによって消費されるメッセージは、アップストリーム キューのコンシューマーには利用できません。

使用事例：

コンシューマがあるノードから別のノードに移行されている場合、フェデレーテッド キューを使用すると、メッセージが失われたり、2 回処理されたりすることなく、これを行うことができます。

ユースケース: RabbitMQ ドキュメントから

典型的な用途は、同じ「論理」キューを多くのブローカーに分散させることです。各ブローカーは、他のすべてのフェデレーテッド キューと共にフェデレーテッド キューを上流に宣言します。(リンクは、n 個のキューで完全な双方向グラフを形成します。)

シャベル

一方、シャベルは、「上流」キューを「下流」交換に接続します。(ショベルのドキュメントではフェデレーションのドキュメントと同じセマンティクスでノードを説明していないため、用語を引用符で囲みます。)

シャベルはキューからメッセージを消費し、宛先ノードの交換に送信します。(注: 通常、このパターンの一部として議論されることはありませんが、コンシューマーが起点ノードのキューに接続するのを止めるものは何もありません。)

特定の質問に答えるには:

フェデレーションを選択したときに欠けているシャベルの細かい制御は何ですか?

シャベルは「上流」または「下流」ノードに存在する必要はありません。独立したノードから構成および操作できます。

シャベルは、リンケージのすべての要素 (ソース キュー、キューのバインディング、および宛先交換) をそれ自体で作成できます。したがって、送信元ノードにも宛先ノードにも侵襲的ではありません。

ショベルを使用する場合に仮想ホスト間通信を変更する唯一の方法は、構成ファイルを変更してインスタンスを再起動することであるというのは正しいですか?

これは一般に、シャベルの欠点として受け入れられています。

次のコマンド (注意: RabbitMQ 3.1.x でのみテストされ、rabbitmq.configのみを含む非常に特殊なファイルを使用) を使用すると、指定したファイルから shovel 構成をリロードできます。(この場合/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).'

.

セットアップ (アプリケーションごとの vhost) は理にかなっていますか、それとも要点を完全に見逃していますか?

この決定は、ユースケースによって異なります。仮想ホストは主に、キュー/エクスチェンジと承認されたユーザーの間の論理 (およびアクセス) 分離を提供します。

于 2014-01-23T07:23:11.200 に答える