3. Kafka 堆积的成因分析

Kafka 消息堆积的本质是生产速率 > 消费速率，导致消息在 Broker 端持续积压。本章从四个核心维度剖析堆积的根因：生产者行为、消费者能力、分区策略、基础设施瓶颈。理解这些成因是后续制定削峰、扩容、调优策略的基础。

3.1 生产者发送过快

生产者端是堆积的“源头”。常见场景包括：突发流量、批量过大、异步发送未做背压、重试机制导致消息重复发送。

3.2 消费者处理过慢

消费者是堆积的“出口”。处理慢的原因通常分为三类：业务逻辑耗时、消费模型不当、Rebalance 频繁。

• 业务逻辑阻塞： 每条消息涉及数据库写入、远程 RPC 调用或复杂计算，单条处理耗时 > 100ms。
• 消费模型缺陷： 使用 poll() 单条处理而非批量处理；max.poll.records 设置过小（如 1），导致每次拉取量不足。
• Rebalance 震荡： 消费者心跳超时触发 Rebalance，期间所有分区暂停消费，堆积瞬时增加。

// 消费者处理慢的典型配置陷阱
props.put("max.poll.records", 1);          // 每次只拉1条，吞吐极低
props.put("max.poll.interval.ms", 300000); // 5分钟超时，掩盖处理慢问题
props.put("session.timeout.ms", 10000);    // 心跳超时过短，频繁Rebalance

3.3 分区分配不均

即使总生产速率与消费速率匹配，分区分配不均也会导致局部堆积。常见场景：

• 消息 Key 倾斜： 热点 Key 集中写入同一分区，该分区 Leader 所在 Broker 负载过高。
• 消费者组内分配不均： 使用 Range 或 Sticky 策略时，部分消费者分配分区数远多于其他消费者。
• 分区数不足： 分区数 < 消费者数，部分消费者空闲，无法水平扩展消费能力。

3.4 网络与磁盘瓶颈

基础设施瓶颈是堆积的“放大器”。即使生产者和消费者逻辑正常，网络或磁盘达到上限后，吞吐会急剧下降。

3.4.1 网络瓶颈

• 带宽打满： 千兆网卡理论 125MB/s，实际可用约 100MB/s。若生产+消费总流量超过此值，延迟飙升。
• TCP 连接数过多： 每个生产者/消费者建立独立连接，Broker 端连接数超过 5000 时，内核开销显著增加。
• 跨机房延迟： 生产者和 Broker 跨 AZ 部署，RTT > 5ms 时，ACK 等待时间拉长，有效吞吐下降。

3.4.2 磁盘瓶颈

• 磁盘 IOPS 耗尽： 机械硬盘 IOPS 通常 < 200，SSD 可达 10k+。日志刷盘频率过高时，IO 等待成为瓶颈。
• 磁盘空间不足： 日志保留策略（log.retention.bytes）设置过大，磁盘写满后 Broker 强制停止服务。
• Page Cache 抖动： 大量写入导致 Page Cache 频繁回收，脏页比例过高，刷盘线程阻塞。

3.5 成因总结与优先级排序

在实际生产环境中，四种成因往往叠加出现。建议按以下优先级排查：

1. 消费者处理慢（最常见）： 检查 max.poll.records、业务逻辑耗时、GC 频率。
2. 分区分配不均（隐蔽性强）： 查看每个分区的 LogEndOffset 与 ConsumerOffset 差值。
3. 生产者发送过快（突发场景）： 监控发送速率与 Broker 端写入速率是否匹配。
4. 网络与磁盘瓶颈（基础设施）： 使用 iostat、sar、dmesg 确认硬件是否达到上限。