Kafka 消费者频繁重平衡：先查 poll 处理耗时，别急着调 session.timeout.ms

线上有一批订单消息的消费组，监控显示消费 lag 在几分钟内从几千涨到几十万，客户端日志里每隔两三分钟就打印一次 “Successfully joined group” 和 “Member is sending LeaveGroup request”。业务同学的第一反应是 Kafka 集群不稳定，于是一路把 session.timeout 从 10 秒调到 45 秒（默认值上限），结果延迟一点没改善，反而让故障恢复变得更慢。## 为什么会这样Kafka 消费者的"心跳"和"拉取"是两套独立机制。（下文涉及客户端参数时，均省略文档里最后的毫秒后缀，例如 max.poll.interval 即完整写法的参数名。）心跳线程定期向 broker 报告"我还活着"，判定失活用的是 session.timeout 和 heartbeat.interval；而判定"这个消费者是不是卡住了"，用的是 max.poll.interval，也就是两次 poll 调用之间允许的最大间隔，默认 5 分钟。关键点在于：你的 poll 回调执行期间，心跳线程仍然在正常工作，broker 并不会认为你掉线。所以哪怕 session.timeout 调得再大，只要单次 poll 的处理时间超过 max.poll.interval，broker 依然会认为这个成员无法正常工作，把它踢出消费组并触发 rebalance。也就是说，绝大多数"莫名 rebalance"的根因不在 Kafka 配置，而在业务代码。## 定位步骤第一步，看客户端日志里的 rebalance 原因。 原因字段会直接告诉你方向：出现 “max.poll.interval has expired” 基本可以定案；出现 “Member has left the group” 多半是进程重启或主动退组；出现 “Failed to send heartbeat” 才是心跳层面的问题。第二步，看客户端埋的耗时指标。 关键是两个：poll 循环的空转时长（从 poll 返回到下次发起 poll 的间隔），以及单条消息的业务处理耗时。如果前者稳定接近甚至超过 max.poll.interval，就可以确认是消费逻辑堵住了拉取线程。第三步，拆解回调里的耗时构成。 常见的三种情况：1. 回调里做了同步的 HTTP 调用。下游接口 RT 从 50ms 涨到 800ms，批量消费一叠加，单轮 poll 就逼近分钟级。2. 回调里包着大事务。数据库锁等待叠加起来，同样会拖长单轮耗时。3. 回调里做了失败重试加退避 sleep。这是最隐蔽的一种：平时无故障时一切正常，下游抖动时才突然开始持续 rebalance。第四步，给消费延迟埋点并告警。 在 poll 返回时打一个时间戳，回调结束时再打一次，差值超过 max.poll.interval 的一半就告警。这一步做得越早，后面定位越省事。## 修复方案分两层做，先止血再根治。第一层，止血。 调小单次拉取量，把 max.poll.records 从 500 降到 100，单轮处理的数据量自然下降；再适当把 max.poll.interval 提到 10 分钟。注意这只是给业务逻辑争取时间，不能替代优化。第二层，根治。 把重逻辑从 poll 线程里挪出去：- 同步调用下游改成异步。poll 线程只负责把消息投递到本地线程池或内存队列，提交 offset 改成手动提交（关闭自动提交）并使用异步提交。- 大批量拆小批。一轮 poll 拿到的消息分成若干批处理，每批处理完提交一次 offset，这样单次阻塞时长可控。- 重试移出回调。失败消息投递到重试 topic 或退避队列，由独立线程按节奏拉取，poll 线程立刻返回。这里有个容易踩的坑：手动提交 offset 时，如果每次都做同步 commit，commit 这个 RPC 本身又会拖慢 poll 循环。建议用异步提交，同时在 rebalance 回调里保留一次同步 commit，避免消息重复处理。## 预防措施1. 上线前用真实消息量压测，关注单条处理耗时的 p99 而不是平均值，p99 才是决定 max.poll.interval 要不要调的依据。2. 把 max.poll.interval 当作"消费能力的上限"来设置，一旦需要往上调，就说明架构上把同步链路放错了位置。3. 监控里加上"消费组 rebalance 次数"和"poll 空转时长"两个指标，比只盯 lag 更早发现问题。4. 排查 rebalance 时，先看日志原因字段，再看客户端耗时指标，最后才去动 broker 或客户端参数。绝大多数问题出在业务处理耗时上，参数调整只能掩盖症状。最后补一句：把 max.poll.interval 调大之后确实不会再被踢出组，但被踢出和卡住是两码事。真正的处理能力提升，只可能来自业务逻辑本身的改造。