Kafka 消费者消息堆积延迟排查指南

Kafka 消费者消息堆积（consumer lag）是生产环境中最常见的延迟告警来源。排查 lag 不能只看数字大小，更重要的是判断 lag 是"正常追赶中"还是"永久性堆积"。端到端排障需要覆盖 lag 指标解读、消费者健康检查、broker 端排查和重启恢复四个环节。

一、区分"追赶中 lag"和"堆积 lag"

Kafka 消费者的 lag 定义为最新写入的 offset 与消费者当前 offset 的差值。一个正在追赶的消费者即使 lag 很大也是正常的，比如全量数据回刷场景。判断标准是：如果 lag 值随时间单调递减，说明消费者在追赶；如果 lag 值持续增长或停滞不变，才是真正的堆积。

使用 Kafka 自带的 kafka-consumer-groups.sh 工具查看 lag：

kafka-consumer-groups.sh --bootstrap-server localhost:9092 \
  --describe --group my-consumer-group

输出中的 LAG 列就是当前堆积量。重点关注 CURRENT-OFFSET 是否在变化，以及 LAG 是否在缩小。建议每隔 30 秒采集一次，连续采集 5 次以上再判断趋势。单次快照无法反映趋势，误判会导致不必要的紧急处理。采集时还可以记录 LOG-END-OFFSET，如果 LOG-END-OFFSET 持续增长但 CURRENT-OFFSET 不变，说明消费者完全停止了消费。

在实际生产环境中，建议将 lag 指标接入 Prometheus 的 JMX Exporter 或 Burrow（LinkedIn 开源的 Kafka 消费者监控工具），通过 Grafana 看板设置自动化的趋势判断和告警，而不是依赖人工定期查看。

二、消费者端排查：从线程阻塞到反序列化

消费者堆积的最常见原因是消费逻辑执行缓慢。排查路径按概率排序：

第一，检查消费线程是否存在阻塞。如果消费逻辑中调用了外部 HTTP 接口、数据库或 Redis，超时或网络抖动会直接阻塞消费线程。在 Java 应用中用 jstack 导出线程堆栈，搜索 BLOCKED 或 WAITING 状态的线程，确认阻塞点。如果阻塞点是数据库操作，检查数据库连接池是否耗尽（通过 HikariCP 或 Druid 的监控指标确认活跃连接数）。如果阻塞点是 HTTP 调用，检查目标服务的 P99 延迟是否突然升高。

第二，检查反序列化性能。如果使用了 Avro 或 Protobuf 等 schema-aware 序列化格式，schema 解析在首次遇到新版本时会消耗额外 CPU 和内存。在消费日志中搜索 AvroRuntimeException 或 SchemaParseException 关键字。对于使用 JSON 反序列化的场景，如果消息体本身很大（超过 1 MB），反序列化的时间也会显著增加，此时考虑切换到二进制格式。

第三，检查 rebalance 频繁程度。消费者组频繁 rebalance 会导致大量时间花在停止、分配、恢复的循环上而非实际消费。通过 Kafka broker 日志中的 GroupCoordinator 和消费者日志中的 Rebalance 关键词，统计单位时间内的 rebalance 次数。如果每分钟超过 1 次，需要排查 session.timeout.ms 和 max.poll.interval.ms 参数是否过小。常见的情况是 max.poll.interval.ms 默认值为 5 分钟，如果消费逻辑偶尔执行较慢（如批量写入数据库时），超过这个阈值就会触发 rebalance。

三、Broker 端排查：分区热点与磁盘 IO

即使消费者本身没问题，broker 端的问题也会导致 lag 增长。

分区数据倾斜： 某些分区的消息量远大于其他分区，导致负责这些分区的消费者过载。通过 kafka-log-dirs.sh 查看各分区的日志段大小，确认是否存在数据倾斜。如果某个分区的消息量是平均值的 5 倍以上，考虑增加该主题的分区数并重新分配 key 的分布。增加分区数需要评估消费者组的消费能力是否同步提升——如果消费者实例数不变，更多分区只会导致每个消费者承担更多分区，不一定能缓解 lag。

磁盘 IO 瓶颈： Kafka 依赖顺序写磁盘提供高吞吐。如果 broker 的磁盘 IO util 持续超过 80%（通过 iostat -x 1 观察 %util 指标），消费者拉取消息的延迟会显著上升。常见原因是日志段清理（log compaction 或 retention 删除）与读取操作争抢磁盘带宽。临时缓解方案是调整 log.cleanup.policy 或增加 log.retention.hours，长期方案是将磁盘从 HDD 升级到 SSD，或者增加 broker 节点分摊负载。

网络带宽： 在消费者与 broker 跨机架或跨可用区部署时，网络带宽可能成为瓶颈。用 iftop 或 Prometheus 的 node_exporter 网络指标确认是否存在带宽饱和。如果消费者需要从远端 broker 拉取消息，可以通过设置 replica.lag.time.max.ms 让消费者优先从同机架的 follower 副本拉取。

四、Offset 管理与重启恢复

当 lag 已经堆积到无法接受的程度，最直接的措施是重置 offset。但重置操作有风险，必须谨慎执行。

自动重置策略（auto.offset.reset）控制的是消费者组首次启动时的行为，对已经运行中的消费者无效。要对运行中的消费者重置 offset，需要先停止消费者组，然后使用 kafka-consumer-groups.sh --reset-offsets 命令指定新的起始位置。注意：--execute 参数会真正写入，--dry-run 只预览不执行，生产环境务必先 dry-run 确认。

重置后需要确认下游系统能否处理重复消息。如果消费者的处理逻辑不是幂等的（比如直接写入数据库计数器），重置 offset 会导致数据重复。此时需要先改造消费逻辑为幂等写入，利用 Kafka 的 offset 记录配合数据库唯一键做去重，再执行 offset 重置。对于已经造成的重复数据，可以用去重脚本或数据库的 INSERT IGNORE 策略进行修复。

另一个常见的误区是直接删除消费者组再重建。这虽然能跳过所有未消费的消息，但会导致所有分区的 offset 从头开始，消费者需要重新消费已经处理过的数据，对下游系统造成不必要的压力。

五、健康检查与自动重启

在生产环境中，消费者进程可能因内存溢出、GC 停顿或未捕获异常而"假死"——进程还在但不再消费消息。设置健康检查机制是防止这种静默堆积的关键。

心跳检测： 消费者定期向监控系统上报心跳，如果超过阈值未收到心跳则触发告警和重启。通过 Kafka 的 max.poll.interval.ms 参数配合，可以让 broker 在消费者失联后自动将其分区分配给其他消费者。同时设置 session.timeout.ms（默认 45 秒）控制 broker 判定消费者失联的超时时间，建议在消费逻辑较慢时适当调大该值。

消费速率监控： 对每个消费者组设置 lag 增长率告警。如果 lag 在 5 分钟内增长超过阈值（如 10000 条），说明消费速率跟不上生产速率，需要立即排查。配合 lag 的绝对值告警（如 lag 超过 100000），形成双维度告警策略。增长率告警可以捕捉突发的消费降速，绝对值告警可以捕捉长期的缓慢堆积，两者缺一不可。

StreamWorks 支持全链路 CDC 采集，覆盖 MySQL Binlog、Oracle LogMiner 等多种数据源，实时写入 Kafka，并提供完善的运维监控、告警与数据补全机制，帮助保障 7×24 实时任务稳定运行，避免因消费者堆积导致的下游数据延迟。

排查路径总结

Kafka 消费者 lag 排查的正确姿势是"先看趋势，再查消费者，然后查 broker，最后做恢复"。不要看到 lag 就急着重置 offset——先判断是追赶中还是真堆积。设置 lag 增长率和绝对值双维度告警，配合消费者健康检查和自动重启机制，才能从根本上预防消息堆积演变为生产事故。

如果你的消费者组 lag 已经告警，建议按以下顺序排查：用 kafka-consumer-groups.sh --describe 确认 lag 趋势，用 jstack 检查消费线程是否阻塞，用 iostat 确认 broker 磁盘 IO 是否饱和，最后根据排查结果决定是调整消费逻辑、增加分区数还是重置 offset。