这个坑值得记一笔。三节点 Kafka 2.8 集群，订单事件 topic 有六个分区，消费组 lag 从十万涨到两百万，把消费者从两台扩到六台，lag 还在继续涨。
刚开始盯着「每次只拉一条，拉取条数与预算都没调」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。分区只有六个，消费者再多也只有六个能干活；消费线程里同步调下游接口，单条耗时两百毫秒；下游数据库写入慢，消费端被反压回去。
动手时先看每个分区的 lag 分布
kafka-consumer-groups.sh --bootstrap-server 10.0.0.31:9092 --describe --group order-cg随后确认消费者数与分区数是否匹配
kafka-topics.sh --bootstrap-server 10.0.0.31:9092 --describe --topic order-event | head -3再往下扩容分区数到能撑起并行度
kafka-topics.sh --bootstrap-server 10.0.0.31:9092 --alter --topic order-event --partitions 12调大单次拉取条数并改批量写库
kafka-consumer-groups.sh --bootstrap-server 10.0.0.31:9092 --describe --group order-cg | awk '{print $3,$6}'怎么算真的好了，看的是同一批现象。扩容并改批量后 lag 在两小时内回落到一万以内，单条消息的平均处理耗时从两百毫秒降到二十毫秒。
消费者数量超过分区数就是浪费，扩分区要同时看 key 分布，否则新增分区没有流量，lag 还是消不下去。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。