Kafka 心跳正常为什么还会 Rebalance？max.poll.interval.ms 怎么配？
面试怎么回答
心跳负责存活，max.poll.interval.ms 负责判断应用是否持续调用 poll，两者不能互相替代。我会根据批次尾延迟、外部重试和 GC 调整批量与间隔，同时确认消费组协议和静态成员行为。若异步处理，消费线程要协调 poll 和提交，并按分区连续完成水位提交，防止为保持心跳而提前确认未处理数据。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Consumer 日志里心跳一直正常，但处理一批数据后提交 Offset 却报组成员状态变化。面试里经常会被问：心跳没有断，为什么还会发生 Rebalance？
心跳检测存活，poll 间隔检测消费程序是否持续推进；配置要结合最坏批次耗时、协议类型与成员模式，处理线程和提交位点也必须协调。
两个超时机制观察的不是同一件事
在常见 Kafka Java Consumer 的经典组协议场景中，心跳用于让协调器知道成员仍然存活，session timeout 约束连续收不到心跳的等待时间。后台仍能发心跳，不代表应用在正常处理下一批记录。
max.poll.interval.ms 则限制相邻 poll 调用的最大间隔，用于识别应用长时间无法推进。网络正常、进程存活，但一批业务处理卡住，仍可能触发组成员变化。先确认触发的是哪条超时，再决定调整哪个参数。
批次预算要看尾部耗时
处理一批记录的时间不仅是平均单条耗时乘条数，还包括慢请求、批量写入、重试、GC 和提交。可以用实测高分位与已知最坏路径评估安全余量，而不是仅按平时平均值设置。
max.poll.records 限制一次 poll 返回给应用的记录数，有助于控制处理批量，但不是底层 fetch 字节量的同义词。调小它以后也应观察缓冲和拉取行为，不能推断所有网络与内存压力都会等比例下降。
静态成员和新协议需要单独确认
静态成员使用 group.instance.id 时，超过 poll 间隔后的分区重新分配时机与普通动态成员有所不同，不能断言所有客户端都会立刻把分区交出去。
Kafka 新消费组协议的心跳和会话控制也与经典协议不同，部分参数由 Broker 管理。实际排查先记录客户端版本、group.protocol、是否静态成员及服务端配置，再读取对应版本文档，避免把经典协议参数解释套到所有部署。
一个典型场景：慢接口让提交失败
比如单批数据触发一轮外部接口重试，此前后台心跳一直正常，但处理耗时最终超过允许的 poll 间隔。业务日志先出现提交失败，团队最初以为 Broker 不稳定，随后在更早的日志里找到处理间隔超时。
原监控只看心跳与消费总吞吐，没记录批次处理尾延迟。修复包括限制外部重试总时长、缩小批次，并按业务容忍度评估是否增加 poll 间隔。单纯把间隔调得极大，会延长真正卡死任务被发现的时间。
线程池处理还需要控制提交顺序
把记录交给线程池，可以让消费线程更及时地 poll，但 KafkaConsumer 本身并非通用线程安全对象，poll、提交、pause 与 resume 应由受控消费线程协调。
同一分区后面的记录先完成时，不能越过尚未完成的前序记录提交更大的 Offset。需要维护每分区连续完成水位、限制在途队列，并在分区撤销时处理未完成工作。吞吐提高以后，正确提交边界仍然是验收重点。