Kafka 消费延迟 — 定位卡住的分区与重平衡风暴

用消费者组命令、分区数量、poll 间隔与处理耗时，定位 Kafka lag 持续增长的原因，再决定扩容消费者还是优化处理逻辑。

现象

消费者组 lag 持续增长不回落；部分分区没有 consumer id；日志频繁出现 Rebalance 或 CommitFailedException；吞吐在重平衡期间骤降；某些分区 offset 长时间不动。

诊断

查消费者组每个分区的 lag 与归属：

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group orders-worker

LAG 集中在少数分区说明热点；CONSUMER-ID 为空说明该分区没有成员，常见于消费者数量少于分区数。再用 kafka-topics.sh --describe --topic orders 查看 PartitionCount，它就是普通消费者组的并行度上限。检查日志中的 Rebalance、max.poll.interval、CommitFailedException：启动后很快重平衡，多半是一批消息处理时间超过 max.poll.interval.ms 被踢出组，而不是吞吐不够。

根因

消费能力跟不上生产速率，或者成员在提交前就离开组。lag 只是结果：分区没有消费者、单条处理慢于到达速率，或者 poll 超时触发反复重平衡，都会让进度停住。

修复

同步增加分区与消费者（不超过分区数）；降低 max.poll.records，把一批处理控制在 poll 间隔内；毒消息转到死信 topic 并提交 offset，避免卡住分区。

max.poll.records=200
max.poll.interval.ms=300000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

注意增加分区会改变既有 key 的分区映射，破坏同一 key 的顺序保证；调大 poll 间隔也会延后对真正失联消费者的检测。

验证

至少观察一个完整流量周期：lag 趋近于零、每个分区都有 consumer id、重平衡次数不再增长，单批处理 P99 明显低于 max.poll.interval.ms，提交 offset 持续前进。