Appearance
Kafka 消息积压排查：Lag 为什么会涨，先查消费慢还是分区不均
Kafka 一旦进入生产环境，最常见的运维问题之一就是：
- 消息积压
表象通常是：
- Lag 持续上涨
- 消费延迟越来越大
- 业务异步链路开始滞后
先说结论
排查 Kafka 积压时，最实用的顺序通常是：
- 先看消费端是不是慢了或异常了
- 再看分区和负载是否不均
- 再看下游依赖是不是拖慢了整个消费链路
- 最后再考虑扩分区、扩实例或重构模型
不要一看到 lag 涨就先扩容。
一、Lag 到底是什么
可以先粗略理解成：
- 生产进度和消费进度之间的差值
如果这个差值持续扩大，就说明：
- 消费赶不上生产
二、最常见的积压原因有哪些
1. 消费逻辑变慢
例如：
- 业务代码变重
- 远程调用变慢
- 数据库写入变慢
2. 消费者异常但没完全挂
例如：
- 持续报错重试
- 某些分区消费线程卡住
3. 分区热点不均
某些分区特别忙，导致某几个消费者压力远高于其他实例。
4. 生产流量突然升高
活动、批量任务、异常重放都可能让消息量激增。
三、为什么“先查消费端”最重要
因为在大多数真实场景里，积压的根因通常不在 Kafka 本身，而在：
- 消费业务逻辑
- 下游依赖
也就是说，Kafka 常常只是把问题“显露出来”，不是源头。
四、排查更实用的顺序
第一步：先看是否有报错和重试
这是最基础的一步。
很多积压本质上只是：
- 消费在反复失败
第二步：看单条消息处理耗时
如果原来 10ms 处理完，现在变成 500ms，lag 涨起来很正常。
第三步：看分区分布是否均匀
如果数据倾斜明显，你可能会发现：
- 某些分区 lag 很高
- 某些分区几乎没压力
第四步：看消费组是否频繁 rebalance
rebalance 过于频繁也会放大消费抖动。
五、什么时候才该考虑扩容
当你已经确认：
- 消费逻辑没有明显异常
- 下游依赖也没有拖慢
- 当前实例和分区并行确实不足
这时再去考虑：
- 增加消费者实例
- 增加分区数
会更合理。
六、几个特别容易踩的坑
1. 只看总 lag，不看分区 lag
这样很容易忽略数据倾斜问题。
2. 一积压就盲目扩容
如果根因是下游接口慢，扩容只会把压力更快打到下游。
3. 消费线程里做太重的阻塞操作
这会把本来应该“快进快出”的消息消费链路拖成串行瓶颈。
一句话总结
Kafka 积压排查最关键的是先分清：
- 是生产变快了
- 还是消费变慢了
- 是整体都慢
- 还是少数分区热点特别重
把这个判断顺序理顺后，Lag 问题通常会比想象中更容易拆开。