积压排查的思路
Lag 增长只是结果，原因分布在四个层次：消费者成员是否齐全、分区分配是否均衡、单个分区是否存在热点、以及集群副本是否健康。按「范围—成员—分布—集群」的顺序走一遍，能在几分钟内把方向收窄到一类原因，而不是在客户端与服务端之间来回猜。
先分清生产突增还是消费变慢
两种情况的处置完全不同：生产突增属于容量问题，扩容或临时加并行度即可；消费变慢多半是下游依赖变慢（数据库写入、外部接口超时）或消费逻辑变重。看生产速率曲线与消费速率曲线的关系，是区分二者的第一步。
基本信息
| 第一步 | 组级概览：确认 lag 规模与分区分布 |
|---|---|
| 第二步 | 成员视图：确认成员数、分配是否完整 |
| 第三步 | 分区维度：判断是热点倾斜还是整体落后 |
| 第四步 | 集群维度：确认副本健康与 Broker 负载 |
| 关键原则 | 先看分区数再看消费者数，先看下游再优化消费端 |
四步排查清单
- 组级概览：describe 看每分区 lag，确认是全局上涨还是个别分区独高
- 成员核对：--members --verbose 确认消费者数量与分区分配是否完整、有无闲置成员
- 再均衡检查：看组状态是否长时间停留在 rebalance，以及 max.poll.interval.ms 是否被处理耗时突破
- 热点确认：个别分区 lag 远高于其他时，检查分区键是否倾斜或存在大量空键
- 集群侧确认：under-replicated 分区数量、Broker 磁盘 IO 与网络是否异常
- 下游确认：数据库写入耗时、外部接口响应时间是否同步变慢
四步排查命令
四步排查命令
# 1) 组级概览：逐分区位移与 lag
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer
# 2) 成员与分配是否正常：成员数、每人分到哪些分区
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer --members --verbose
# 3) 组状态：Stable 正常，长期 PreparingRebalance 说明再均衡反复
kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
--describe --group order-consumer --state
# 4) 集群侧副本健康：有掉队副本说明 Broker 可能同时承压
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-replicated-partitions现象与方向
| 现象 | 大概率原因 | 动作 |
|---|---|---|
| 全部分区均匀上涨 | 消费能力不足或下游变慢 | 先查下游耗时，再考虑扩容消费者与分区 |
| 个别分区独高 | 热 key 导致分区倾斜 | 调整分区键或把热点单独处理 |
| lag 锯齿状波动 | 频繁再均衡或处理超时 | 核对 max.poll.interval.ms 与单批处理耗时 |
| 消费者无分配 | 分区数、组名或订阅不一致 | 核对分区数、group.id 与订阅的主题名 |
| 生产与消费速率同时波动 | 上游流量突增 | 按峰值扩容，必要时临时提高并行度 |
再均衡是 lag 锯齿的常见来源：一批消息处理时间超过 max.poll.interval.ms 会被踢出组，重新入组后又从头拉取未提交的部分，形成「重复处理 + 位移推进缓慢」的循环。
盲目扩容消费者是常见误操作：分区数不足时新增实例不承担任何分区，lag 毫无变化；扩容前必须先看分区数与分配结果。