問題：
Kafka0.10.2.1のバージョンを使用しています。
#kafka.bootstrap.servers=
kafka.bootstrap.servers=
kafka.group.id=
kafka.topic=
kafka.concurrency=5
kafka.key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
kafka.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
kafka.auto.offset.reset=latest
kafka.enable.auto.commit=true
kafka.auto.commit.interval=100
kafka.max.poll.records=20
kafka.session.timeout.ms=30000
kafka.security.protocol=SASL_PLAINTEXT
kafka.sasl.mechanism=PLAINしかし、kafka消費者の頻繁な再配布があります
Kafkaの高低バージョンのハートビートとセッションタイムアウトメカニズム
Kafka 0.10.0.0＆Kafka 0.10.1.0
0.10.0.0ハートビートとタイムアウトのメカニズム：
ハートビートとポーリングは結合され、session.timeout.msパラメーターのみが提供され、独立した制御ポーリングポーリングパラメーターはありません。
コンシューマーがメッセージを処理するのに1分かかると仮定すると、session.timeout.msを1分より大きく設定する必要があります。そうしないと、コンシューマーはタイムアウトになります。
session.timeout.msKafka
のグループ管理機能を使用するときに障害を検出するために使用されるタイムアウト。
セッションタイムアウト内にコンシューマーのハートビートが受信されない場合、ブローカーはコンシューマーを失敗としてマークし、グループのバランスを取り直します。
ハートビートはpoll（）が呼び出されたときにのみ送信されるため、セッションタイムアウトが長くなると、ハード障害の検出に時間がかかる代わりに、コンシューマーのポーリングループでのメッセージ処理により多くの時間がかかります。
ポーリングループでの処理時間を制御する別のオプションについては、max.poll.recordsも参照してください。
値は、group.min.session.timeout.msおよびgroup.max.session.timeout.ms。
官方提到すると、max.poll.records参数により、ブローカー構成で構成されている許容範囲内にある必要があることに注意してください。セッション外一パラメータ维度来容制影响每次世論調査時間。
heartbeat.interval.msKafka
のグループ管理機能を使用する場合のコンシューマーコーディネーターへのハートビート間の予想時間。
ハートビートは、コンシューマーのセッションがアクティブなままであることを保証し、新しいコンシューマーがグループに参加またはグループから脱退するときのリバランスを容易にするために使用されます。
値はsession.timeout.msより低く設定する必要がありますが、通常はその値の1/3以下に設定する必要があります。
通常のリバランスの予想時間を制御するために、さらに低く調整することができます。
0.10.1.0ハートビートメカニズム：
このバージョン以降、ハートビートとポーリングは分離され、各スレッドには独立したハートビートメンテナンスメカニズムがあります。
このバージョンから、独立したmax.poll.interval.msパラメーターが追加されました。このようにして、2つのポーリング間の間隔を個別に構成できます。これにより、ポーリング間隔をハートビート間隔より長く構成できます。つまり、コンシューマーがメッセージを処理する時間を個別に構成できるため、メッセージ処理が可能になります。ハートビート時間よりも長くなる時間（セッションタイムアウトセッション。timeout.ms）。
session.timeout.msはハートビート保守スレッドに使用され、max.poll.interval.msは消費処理スレッドに使用されます。このバージョンには2つの別々のスレッドがあります。
session.timeout.ms = 30000、つまり30秒とすると、コンシューマーハートビートスレッドは、このタイムアウトの前にサーバーにハートビートを送信する必要があります。
一方、単一のメッセージ処理に1分かかる場合は、max.poll.interval.msを1分より大きく設定して、コンシューマー処理スレッドがメッセージを処理する時間を増やすことができます。
それ以外の場合、max.poll.interval.msが1分未満の場合、2つのポーリングがmax.poll.interval.msを超えてポーリングが失敗するため、単一のメッセージが処理され、次のポーリングを待機します（セッションがタイムアウトしていない場合）、ポーリングは失敗します）。
処理（pol）スレッドがハングした場合、サーバーはmax.poll.interval.msを介してそれを検出できます。
コンシューマー全体（コンシューマー）がハングした場合は、session.timeout.msを介してのみ検出できます。
0.10.1.0的熟修改：
新しいJavaコンシューマーは、バックグラウンドスレッドからのハートビートをサポートするようになりました。
新しい構成max.poll.interval.msがあり、コンシューマーがプロアクティブにグループを離れるまでのポーリング呼び出し間の最大時間を制御します（デフォルトでは5分）。
構成request.timeout.msの値は、常にmax.poll.interval.msよりも大きくする必要があります。これは、コンシューマーのリバランス中にJoinGroup要求がサーバー上でブロックできる最大時間であるため、デフォルト値を変更しました。 5分強まで。
最後に、session.timeout.msのデフォルト値が10秒に調整され、max.poll.recordsのデフォルト値が500に変更されました。
0.10.1.0版本的官方说明（http://kafka.apache.org/0101/documentation.html）
max.poll.interval.ms
ポーリングの起動との間の最大遅延（）コンシューマ・グループの管理を使用する場合。これにより、コンシューマーがさらにレコードをフェッチする前にアイドル状態にできる時間に上限が設定されます。このタイムアウトの期限が切れる前にpoll（）が呼び出されなかった場合、コンシューマーは失敗したと見なされ、グループはパーティションを別のメンバーに再割り当てするためにリバランスします。
session.timeout.msKafka
のグループ管理機能を使用するときにコンシューマーの障害を検出するために使用されるタイムアウト。コンシューマーは定期的にハートビートを送信して、ブローカーにその活性を示します。このセッションタイムアウトの期限が切れる前にブローカーがハートビートを受信しなかった場合、ブローカーはこのコンシューマーをグループから削除し、リバランスを開始します。値は、group.min.session.timeout.msおよびgroup.max.session.timeout.msによってブローカー構成で構成されている許容範囲内にある必要があることに注意してください。
request.timeout.ms
構成は、クライアントが要求の応答を待機する最大時間を制御します。
タイムアウトが経過する前に応答が受信されない場合、クライアントは必要に応じて要求を再送信するか、再試行が尽きた場合は要求を失敗させます。
また注意してください：
バージョン0.10.2.1のデフォルトパラメータ（max.poll.interval.ms）はInteger.MAX_VALUEに調整されます
http://kafka.apache.org/0102/documentation.html
0.10.2.1で
の注目すべき変更点StreamsConfigクラスの2つの構成のデフォルト値が変更され、KafkaStreamsアプリケーションの復元力が向上しました。
内部
KafkaStreamsプロデューサーの再試行のデフォルト値が0から10に変更されました。 内部KafkaStreamsコンシューマーのmax.poll.interval.msデフォルト値が300000からInteger.MAX_VALUEに変更されました。