堆积场景的典型表现

Kafka 堆积（Backlog）并非单一故障，而是一组连锁症状的集合。当消费端处理能力持续低于生产端写入速率时，系统会依次出现以下四种典型表现。准确识别这些表现所处的阶段，是制定调优策略的前提。

表现一：消费延迟（Consumer Lag）持续增长

消费延迟是堆积最直接的度量指标。Kafka 通过消费者组偏移量（Offset）与分区最新消息位置（Log End Offset, LEO）之间的差值来定义 Lag。当 Lag 持续上升而非趋于稳定，说明消费速率 < 生产速率。

表现二：消息积压导致磁盘空间告急

当消费端无法及时拉取消息，Kafka Broker 端的日志段（Log Segment）文件会持续保留未被消费的数据。若 log.retention.bytes 或 log.retention.hours 配置不当，磁盘使用率会快速攀升，最终触发 磁盘写满 → 分区不可用 → 生产端写入失败 的级联故障。

• 监控命令： df -h 查看 Broker 数据目录使用率；du -sh /data/kafka/* 定位积压严重的 Topic 分区目录。
• 典型现象： 磁盘 IO 利用率（iostat -x 1 中的 %util）持续超过 80%，且 await 时间 > 30ms。
• 避坑提示： 不要仅依赖保留时间策略清理堆积数据。当消费端彻底宕机时，保留时间策略无法缓解瞬时写入洪峰，必须配合容量规划和限流。

表现三：消费者组 Rebalance 频繁

Rebalance 是 Kafka 消费者组在成员变更或分区分配调整时触发的重分配过程。在堆积场景下，Rebalance 频率会异常升高，主要原因包括：

1. 消费者心跳超时： 消费者因处理堆积消息导致 GC 停顿或 CPU 满载，无法在 session.timeout.ms（默认 45 秒）内发送心跳，被协调器判定为下线。
2. Max Poll Interval 超时： 消费者处理一批消息的时间超过了 max.poll.interval.ms（默认 5 分钟），触发主动离开组。
3. 分区分配不均： 部分消费者因处理缓慢导致 Lag 极高，而其他消费者空闲，触发 cooperative rebalance 或 eager rebalance 重新分配。

Rebalance 期间所有消费者会暂停消费（Eager 模式）或部分暂停（Cooperative 模式），这反而加剧了消息积压，形成 堆积 → Rebalance → 更严重堆积 → 更频繁 Rebalance 的恶性循环。

四种表现的关联关系

以下 SVG 图展示了四种典型表现之间的因果链条与正反馈循环：

四种表现的诊断优先级

在实际运维中，建议按以下优先级进行排查，避免被次要症状干扰：