1

Request/Response パターンを使用して、MassTransit/RabbitMQ 経由で API からのリクエストがバックエンド サービスに転送される API の作成を完了しました。現在、これを本番環境にプッシュすることを検討しており、アプリケーションの複数のインスタンス (API とサービスの両方) を異なるサービスで実行し、ロード バランサーがそれらの間でリクエストを分散することを望んでいます。

これにより、サーバーの 1 つが何らかの理由でプールから取り出された場合、すべてのメッセージを失う可能性があるという状況に陥ります。サーバー間でRabbitMQクラスターを作成しようとしています（各サーバーにはローカルインストールがあります）が、このインスタンスで競合するコンシューマーをどのようにセットアップするのか疑問に思っていました.

RabbitMQ または MassTransit はこれを処理して、1 つのコンシューマーのみがリクエストを受信するようにしますか、それともすべてのコンシューマーがリクエストを受信して​​応答を試みるようにしますか? また、RabbitMQ クラスターでは、MassTransit/RabbitMQ はノードの障害をどのように処理しますか?

4

1 に答える 1

2

このドキュメントをご覧ください。 http://www.rabbitmq.com/distributed.html

一般的な分散シナリオを非常にうまく説明します。あなたのシナリオでは、クラスタリングよりもフェデレーションの方が適していると思います。クラスタリングを行う場合は、ミラーリングされたキューを確認する必要があります。

パフォーマンスだけが必要な場合は、単一のサーバーでメッセージキューを処理し、他のサーバーがそれに接続してメッセージを生成/消費する方がよいでしょう。

大量輸送機関がどのように機能するかはわかりませんが、要求/応答を使用する場合は、単一のコンシューマーにメッセージを1回配信する必要があります。メッセージが確認されない場合（コンシューマーがクラッシュする場合）、他のコンシューマーがメッセージを受け取る必要があります。 。

于 2012-06-18T18:45:13.740 に答える