kafka队列积压问题如何排查

对于高级 Java 开发而言，Kafka 积压（Lag）是面试和实战中最常遇到的高频问题。排查积压不能只看“加机器”，而要从生产端、服务端、消费端全链路定位“瓶颈点”。

以下是标准排查逻辑：

1. 第一步：定位瓶颈（监控先行）

首先要确认：是生产太快了，还是消费太慢了？

• 核心指标： 查看 Consumer Lag（落后位移数）。

  • 如果 Lag 持续增长，说明消费速率 < 生产速率。

• 分片查看： 确认是某个特定的 Partition 积压，还是所有 Partition 全线积压。

  • 单个积压： 通常是 Data Skew（数据倾斜），某个 Key 特别多导致某个消费者压力大。

  • 全线积压： 消费端整体逻辑变慢、网络问题或 Kafka 集群压力。

2. 第二步：分析消费端（90% 的积压原因在此）

如果确定是消费端跟不上，按以下维度拆解：

A. 消费逻辑变慢

• 排查： 消费逻辑里是否有慢 SQL、外部 API 调用超时、磁盘 IO 瓶颈？

• 手段： 查看消费端的 CPU 和内存监控。如果 CPU 占用极低但 Lag 增长，说明线程在等待 IO（阻塞）。

B. Rebalance（重平衡）风暴

• 现象： 消费组频繁重平衡，导致消费间歇性停滞。

• 原因： * max.poll.interval.ms（两次 poll 间隔时间）设置太短，导致逻辑没执行完就被认为挂了。

  • session.timeout.ms 设置太短，网络抖动导致频繁剔除成员。

C. 线程配置不合理

• 检查： 消费者线程数是否小于 Partition 数？

  • 注意： 增加消费者线程数，只有在消费者少于 Partition 数时才有效。

3. 第三步：分析生产端与服务端

• Batch 配置： batch.size 和 linger.ms 是否设置得太小，导致请求次数过于频繁，网络开销大？

• 压缩机制： 是否开启了 compression.type（如 zstd/lz4）？开启压缩可以极大缓解网络带宽压力。

• Broker 性能： 查看 Kafka 节点的磁盘利用率和 IO 等待时间（iowait）。如果磁盘满了或 IO 达到瓶颈，ACK 回复会变慢，反压生产端。

4. 第四步：紧急处理预案（面试必杀技）

如果是在生产环境下，积压已经导致业务延迟，常规优化来不及，可以采用**“临时紧急扩容”**：

1. 修复 Consumer 逻辑： 确保代码没 Bug（如死循环）。

2. 停掉旧的 Consumer： 临时停止消费。

3. 新建大 Partition Topic： 比如创建一个比原 Topic 分区多 10 倍的新 Topic。

4. 搬运工程序： 写一个临时 Consumer，不做任何逻辑，只负责把数据转发到新 Topic 中。

5. 批量扩容： 部署 10 倍数量的消费者去消费新 Topic。

6. 后续恢复： 积压消化完后，恢复原有架构。

5. 面试加分点：常见参数调优

你可以主动提到以下参数的调优经验：

• fetch.min.bytes： 提高该值可以增加单次拉取的数据量，减少请求频率。

• max.poll.records： 调小此值可以防止单次 poll 数据过多导致处理超时（触发 Rebalance）。

• enable.auto.commit： 建议设为 false 改为手动提交，防止丢数据或重复消费。

总结：

“排查 Kafka 积压，我首先会通过监控工具确认 Lag 趋势。如果是部分分区积压，我会查数据倾斜；如果是整体积压，我会重点分析消费端的 IO 阻塞情况和 Rebalance 日志。在极端情况下，我会采用横向扩容分区和消费者的方式来快速消化存量数据。”

你前年处理交易数据时，如果行情数据瞬间爆发导致积压，你们是选择增加 Partition 还是丢弃旧数据（针对行情这种时效性强的业务）？