[解決済み] グループがリバランスしているため、ハートビートが失敗しました。

質問

リバランスのためにグループのハートビート障害が発生する正確な理由は何ですか？グループ内のすべてのコンシューマが稼働している状態でリバランスが発生する理由は何ですか？

ありがとうございました。

解決方法は？

ハートビートは、すべてのコンシューマーがまだ稼働しているかどうかを確認するための基本的なメカニズムです。グループのリバランス中にハートビート失敗が発生した場合、コンシューマーインスタンスが次のハートビートを送信するのに時間がかかりすぎたため、死んだとみなされ、リバランスがトリガーされたことを示します。

これを防ぐには、タイムアウトを長くするか ( session.timeout.ms )、またはコンシューマがより頻繁にハートビートを送信するようにする ( heartbeat.interval.ms ). ハートビートは基本的に poll() したがって、十分な頻度で poll を呼び出すようにする必要があります。これは通常、1回のポーリングが返すレコードの数を max.poll.records (取得したすべてのデータを処理する時間を短縮するため)。

更新

Kafka 0.10.1以降、ハートビートはバックグラウンドのスレッドで送信され、次のような場合には送信されません。 poll() が呼ばれる（cf. https://cwiki.apache.org/confluence/display/KAFKA/KIP-62%3A+Allow+consumer+to+send+heartbeats+from+a+background+thread ). この新しいデザインでは、コンフィギュレーション session.timeout.ms と heartbeat.interval.ms はそのままです。さらに、そこには max.poll.interval.ms の頻度を決定するものです。 poll() を呼び出す必要があります。もし poll() の中で max.poll.interval.ms ハートビートスレッドは、処理スレッドが死んだと仮定し、リバランスを引き起こす leave-group-request を送信し、その後ハートビートの送信を停止します。処理スレッドが正常であっても、単に遅いだけであれば、次に呼び出すのは poll() は再びリバランスを開始し、再びグループに参加する。

詳細はこちらをご覧ください。 Kafka の session.timeout.ms と max.poll.interval.ms の差分 >= 0.10.1