0

ロードバランサーの背後にある 2 つのノードを持つ HA RabbitMQ クラスター (v3.2.x) があります。クライアントは 300 秒のハートビートを使用するように構成されています。ほとんどの場合、すべてが期待どおりに機能します。

ただし、クライアントの接続が切断された場合 (たとえば、クライアントの NIC が切断された場合)、接続を閉じる前に、RabbitMQ ノードが 3 つのハートビート メッセージ (この場合は約 15 分) を試行することに (TCPDump/wireshark を介して) 気づきました。なんで?1回失敗したら閉じませんか?

RabbitMQ サーバーでこの動作を変更する方法はありますか? それとも、接続をより早く閉じるために、ハートビートを 5 秒または 10 秒などのはるかに小さいものに短縮する必要がありますか?

関連する問題...

TCPDump (ロードバランサーでキャプチャ) を見ると、プロキシされた RabbitMQ サーバーのハートビート要求に応答して、死んだクライアントから TCP-ACK を受信しない場合、LB が接続を閉じないのはなぜでしょうか? 実際、LB は要求を数回送信しようとします (もちろん、応答を受信することはありません)。LB が接続が切断されたと想定し、セッション全体 (RabbitMQ ノードへの接続を含む) を閉じることは意味がありませんか?

4

1 に答える 1

0

RabbitMQ は、接続を終了する前に 2 回のハートビートの欠落を許容するように構成されているようです。ただし、接続をドロップする前に次のハートビートを送信する必要があるまで待機します。これにより、3 つの欠落したハートビートが必要なように見えます。

Heartbeat1 (応答なし) 待機 Heartbeat2 (応答なし) 待機 Heartbeat3 終了

MQ にはわずかなバグがあります (3 番目のハートビートを送信しますが、すぐに接続を終了します) が、実際には何の影響もありません。

于 2014-04-11T17:56:25.663 に答える