Kafka 0.10.0.0以降のバージョンのsession.timeout.msとmax.poll.interval.msの違い
両方が必要な理由はわかりませんsession.timeout.msおよびmax.poll.interval.msそして、いつどちらか一方または両方を使用しますか？両方とも、コーディネーターが消費者からハートビートを取得するのを待ってから、それが死んだと仮定するまでの時間の上限を示しているようです。
また、 KIP-62 に基づいたバージョン0.10.1.0+ではどのように動作しますか？
KIP-62より前は、_session.timeout.ms_のみです（つまり、Kafka _0.10.0_以前）。_max.poll.interval.ms_は KIP-62 （Kafka _0.10.1_）の一部）。
KIP-62は、バックグラウンドハートビートスレッドを介してpoll()への呼び出しからハートビートを分離し、ハートビート間隔よりも長い処理時間（つまり、2つの連続したpoll()）間の時間を許可します。
メッセージの処理に1分かかると仮定します。ハートビートとポーリングが結合されている場合（つまり、KIP-62より前）、_session.timeout.ms_を1分以上に設定して、コンシューマーがタイムアウトしないようにする必要があります。ただし、消費者が死亡した場合、障害のある消費者を検出するのにも1分以上かかります。
KIP-62は、ポーリングとハートビートを分離し、2つの連続したポーリング間でハートビートを送信できるようにします。ハートビートスレッドと処理スレッドの2つのスレッドが実行されているため、KIP-62はそれぞれにタイムアウトを導入しました。 _session.timeout.ms_はハートビートスレッド用、_max.poll.interval.ms_は処理スレッド用です。
_session.timeout.ms=30000_を設定すると仮定します。したがって、この時間の期限が切れる前に、コンシューマーハートビートスレッドはブローカーにハートビートを送信する必要があります。一方、単一のメッセージの処理に1分かかる場合は、_max.poll.interval.ms_を1分より大きく設定して、処理スレッドにメッセージを処理する時間をより多く与えることができます。
処理スレッドが停止した場合、_max.poll.interval.ms_を使用してこれを検出します。ただし、コンシューマー全体が死んだ場合（および、死にかけている処理スレッドがハートビートスレッドを含むコンシューマー全体をクラッシュさせる可能性が最も高い）、それを検出するのに_session.timeout.ms_しかかかりません。
アイデアは、処理自体に非常に時間がかかっても、障害のある消費者をすばやく検出できるようにすることです。