Rabbitは約1年使用しています。最近、複製されたメッセージキューを持つクラスターを使用するため、v2.6.1にアップグレードしました。
私のテストは、私にはウサギのバグのようなにおいがする不可解な動作にぶつかりました。これを明らかにするテストは、2ノードクラスターで機能しています。両方のノードがv2.6.1を実行しています。両方のノードにディスクがあります。どちらのノードもMacOSで実行されていますが、これが適切かどうかは疑問です。
また、テストを実行するノードでAliceを実行しています。テストでは、これを使用して、ノードの1つでstop_appをプログラムで実行します。これは、クラスターマスターに障害が発生し、スレーブが昇格してメッセージが失われないことを検証しようとしているためです。
そのため、テストには小さなスレッドプールがあり、定期的に1）メッセージを公開し、2）Rabbitマスターノードの状態を切り替えます（実行中の場合は停止、停止中の場合は開始）。他のスレッドはキューからのメッセージを消費しています。
私はパブリッシャーの確認を使用しており、コンシューマーのメッセージも確認しています（channel.basicConsume（）にautoAck = falseを使用）。
マスターノードが停止すると、プロデューサーとコンシューマーの両方がShutdownSignalExceptionをキャッチしているのがわかります。彼らは、クラスターへの再接続を試みることによってこれを処理します。これは正常に機能します。再接続すると、彼らはビジネスを継続します。
時々、私が見るのは、コンシューマーがブローカーからメッセージを正常にフェッチし、ShutdownSignalExceptionを取得したときにchannel.basicAck（）を呼び出していることです。
後で、コンシューマーが再接続すると、同じメッセージが再度プルダウンされます。（メッセージ本文はUUIDでタグ付けされているので、同じものであることがわかります。）今回、コンシューマーがメッセージをbasicAck（）しようとすると、再びShutdownSignalExceptionが発生しますが、これには次のテキストが含まれています。 reply-text=PRECONDITION_FAILED-不明な配信タグ7"。
実際、これは、マスターがダウンしてコンシューマーが再接続する前にブローカーによってコンシューマーに提供されたものと同じ配信タグです。
グーグルは、このイベントが、消費者が同じメッセージを複数回確認しようとしていることを意味していることを示唆しています。
しかし、これはどうしてそうなるのでしょうか？最初のackが成功した場合、メッセージはブローカーのキューから削除されているはずであり、コンシューマーには同じメッセージが再び表示されないはずです。
それでも、最初のackが成功しなかった場合、消費者はメッセージを再ackしようとしたことでうんざりするべきではありません。
これを見た人はいますか？Rabbitの複製されたキューのバグのような匂いがしますが、私はまだRabbitを初めて使用しているので、クラスター化されたブローカーからの消費にはまだ微妙な点があると信じています。
ありがとう、-スティーブ