問題タブ [rabbitmq-federation]

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

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

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

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

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

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

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

私の質問を要約すると：

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

フェデレーション プラグインを使用するサーバーには 4 つの仮想チャネルがあり、それぞれが 10 プリフェッチに設定されています。10 件のメッセージが確認されない場合、サーバーは停止します。

仮想ホストに no-ack を設定するにはどうすればよいですか?

ウサギのクラスターをセットアップし、データベースで何かが変更されるたびにメッセージをファンアウト交換に発行します。

これらの更新を使用する一部のマイクロサービス用に、このエクスチェンジにバインドされた専用キューがあります。また、最初に外部クライアント用の専用キューをセットアップして、外部クライアントが独自のウサギ インフラストラクチャとフェデレートし、すべてのメッセージのコピーを使用できるようにしました。

ますます多くのユーザーが来るため、新しい外部コンシューマーごとに新しい専用キューを作成するのではなく、交換フェデレーションを許可する方がより良いアプローチになるかどうか疑問に思っています.

長所と短所は何ですか？

ありがとう

背景情報として、当社は 200 を超える店舗を持つ小売業者です。200 以上の RabbitMQ サーバー (各ストアに 1 つのサーバー) との rabbitmq フェデレーションを使用します。各 RabbitMQ サーバーには 4 つの交換があります。そのため、合計で約 800 の取引所があります。

メッセージが発行される中央サーバーが 1 つあります。これは、他の 200 台のサーバーのアップストリーム サーバーとして使用されます。製品の変更があると、メッセージが中央サーバーに送信され、他の rabbitmq サーバーに転送され、各ストアでローカルに処理されます。私たちのアプリケーションは、Windows サーバー上の .NET フレームワークで実行されます (Masstransit を使用して RabbitMQ を処理します)。

イベントを rabbitMQ に発行するときに、タイムアウト エラーが発生することがあります。これは例です:

各メッセージは約 5000 バイトです。メッセージがどのようにタイムアウトになったかを理解したいと思います。ack の動作に関して、rabbitMQ の Web サイトでこれを見つけました。

For routable messages, the basic.ack is sent when a message has been accepted by all the queues. For persistent messages routed to durable queues, this means persisting to disk. For mirrored queues, this means that all mirrors have accepted the message. ( https://www.rabbitmq.com/confirms.html#when-publishes-are-confirmed )

ただし、フェデレーションでの公開確認動作に関する情報は見つかりませんでした。だから私たちの質問は

1. Exchange フェデレーションでは、すべてのダウンストリーム サーバーがメッセージを受信したとき、またはアップストリーム サーバーがメッセージをディスクに永続化したときに、ブローカーは公開確認を送信しますか?
2. タイムアウトエラーを解決するには?

どんな助けでも大歓迎です。