kafka通过心跳机制与超时参数协同判断消费者是否失联：heartbeat.interval.ms控制心跳频率，session.timeout.ms定义会话超时阈值，且推荐后者≥3倍前者；若心跳超时或poll间隔超过max.poll.interval.ms，即触发重平衡。
Kafka 通过心跳机制和超时参数协同判断消费者是否“失联”，一旦判定为长时间未响应，就会将其踢出消费组，触发重平衡。这不是故障，而是 Kafka 保障分区不被“卡死”的主动保护策略。关键在于让消费者持续向协调器（Coordinator）证明自己还活着，并在合理时间内完成消息处理。
核心机制：心跳与会话超时
消费者必须周期性发送心跳请求，Broker 的 Coordinator 依据两个参数做判断：
- heartbeat.interval.ms：心跳发送间隔，比如设为 3000（3 秒），代表每 3 秒发一次心跳；
- session.timeout.ms：会话超时时间，比如设为 10000（10 秒），代表 Coordinator 最多容忍 10 秒收不到心跳，就认为该消费者已失效。
官方推荐 session.timeout.ms ≥ 3 × heartbeat.interval.ms，确保网络抖动或短暂 GC 不会误判。若心跳停发超过 session.timeout.ms，Coordinator 立即发起 Rebalance，将该消费者负责的分区重新分配。
另一个常见诱因：消息处理超时
即使心跳正常，如果单次 poll 后的消息处理耗时太久，也会触发重平衡。Kafka 用以下参数约束处理窗口：
- max.poll.interval.ms：两次 poll 调用之间的最大允许间隔（默认 5 分钟）。消费者必须在这个时间内完成上一批消息处理并再次调用 poll()；
- 若处理逻辑中包含阻塞操作（如远程调用、大文件解析、Thread.sleep(600000)），导致 poll 间隔超时，Coordinator 同样会将其标记为失败并踢出组。
如何避免因响应慢引发的重平衡
重点不是“不让它发生”，而是“让系统能扛住真实业务耗时”。实用建议包括：
- 把耗时操作从 @KafkaListener 方法内移出，改用异步线程池处理，保证主线程快速返回并及时 poll；
- 调小 max.poll.records（如设为 50 或 100），降低单次 poll 返回的消息量，缩短整体处理时间；
- 根据实际处理能力，合理放大 max.poll.interval.ms（如设为 10 分钟），但需同步评估消息积压风险；
- 禁用自动提交（enable.auto.commit=false），改为手动 commitSync/commitAsync，避免偏移量提交滞后于实际处理进度。
辅助排查手段
当频繁出现 “Rejoining group due to: need to rebalance” 日志时，可结合以下方式定位：
- 查消费者日志中是否有 “Attempt to heartbeat failed” 或 “ConsumerCoordinator: Lost heartbeat”；
- 用命令行检查消费组状态：kafka-consumer-groups.sh --bootstrap-server xxx --group xxx --describe，观察成员数是否波动、是否有 "REBALANCING" 状态；
- 监控 JVM GC 日志，确认是否存在长时间 Full GC 导致心跳线程无法调度。
