クラスタ内でRabbitMQノードの障害を処理して公開および使用を継続する

Question

高可用性のためにクラスタを作成し、このクラスタのロードバランサフロントを配置したいとします。私たちの設定では、交換とキューを手動で作成したいので、1つの交換とキューが作成されます。クライアントはそれらを再宣言する必要はありません。私はルーティングキーとの直接交換を使用しているので、異なるノード上の異なるキューにメッセージをルーティングすることが可能です。しかし、私はクラスタリングとキューに関するいくつかの問題があります。

私がRabbitMQのドキュメントを読む限り、キューは作成されたノードに固有です。さらに、パブリッシュ/コンシューム操作時に生存しているはずのクラスター内に、同じ名前のキューを1つしか配置できません。ノードが消滅した場合、そのノードのキューは消え、メッセージは復元されません（もちろん構成によって異なります）。したがって、たとえ同じメッセージを別のノードの別のキューにルーティングしても、メッセージを消費し続けるためにそれらを使用する方法を把握する必要があります。

ミラー化されたキューを使用せずにこのフェールオーバーのシナリオを処理できるかどうかは疑問です。障害が発生した場合に新しいノードに切り替えて、同じキューから継続して消費したいとします。パブリッシャはルーティングキーを使用しているだけで、これらのメッセージは複数のキューに入る可能性があるため、コンシューマにとって同じ状況は不可能です。

要するに、最初の段落で説明した環境での失敗にどう対処することができますか。キューミラーリングは、クラスター内でのパフォーマンスの低下や、より実用的なソリューションが存在する最善の方法です。

Answer 1

データ複製（RabbitMQのミラー化キュー）は、高可用性を実現するための標準的な方法です。私はそれらを使用することをお勧めします。データを複製しないと、データは失われます。

パフォーマンスが心配な人は、RabbitMQの拡張性はよくありません。 パフォーマンスを向上させるための唯一の方法は、ノードを大きくするか、2番目のクラスタを作成することです。クラスタにノードを追加しても、実際には改善されません。また、TLSを使用する予定がある場合は、スループットも大幅に低下します。ハイスループット要件+ HAがある場合は、Apache Kafkaを検討します。

ユースケースでHAについて気にすることができない場合は、コンシューマ/パブリッシャがブローカに接続するたびにキュー/交換を再宣言するだけです。これは大丈夫です。既に存在するキューを宣言すると間違ったことは起こりません。キューはパージされません。交換と同じです。

さらに、RabbitMQ sharding pluginをチェックしてください。これはおそらくあなたのユースケースに役立ちます。