Kafka Consumer Lag 排查：从积压到恢复

Kafka Consumer Lag 排查的第一步不是立刻扩容，而是确认“落后的是哪一个位置”。对某个分区来说，消费者有当前 position，Kafka 还有日志终点；提交的 committed position 又是重启和重平衡后的恢复点。通常可以把积压理解为日志终点与消费位置之间的差距，但不同读取隔离级别、事务状态和监控实现会影响终点定义。正确的恢复路径是：确认组和分区，区分流量突增与消费变慢，找出最慢环节，再选择扩容、降载、修复消息或安全重置偏移量。

先确认是不是“真积压”

先固定四个维度：topic、consumer group、partition、观测时间。不要只看全组总 lag，因为总数可能被平均值掩盖；一个热点分区持续增长，其他分区正常，通常意味着键分布、单条消息处理或分区领导者存在局部问题。

KafkaConsumer Javadoc 区分了 position 和 committed position。position 是下一条将被拉取的 offset，每次 poll 取得消息后会自动前进；committed position 是已经安全保存的 offset，进程重启或重新分配分区时会从这里恢复。若监控系统使用 committed offset 计算 lag，而应用已经处理但尚未提交，看到的数字会偏大；若应用提前提交，数字可能下降但业务结果仍未完成。

读取事务消息时还要注意终点。read_uncommitted 下，分区终点通常接近高水位线；read_committed 下，有效终点可能是 Last Stable Offset，开放事务会让消费者暂时看不到后续未稳定记录。因此，看到 lag 增加时，先记录消费者的 isolation.level、事务状态和生产端提交情况，不能把两种模式的数值直接比较。

五分钟内的初筛顺序

第一，观察生产速率和消费速率。若生产速率突然超过消费能力，lag 呈连续上升；若生产恢复正常而消费速率稳定高于生产，lag 应逐步下降。若两者都下降，可能是客户端断连、分区未分配、重平衡或下游阻塞，而不是单纯吞吐不足。

第二，按分区看增长斜率。一个分区异常而其他分区正常，优先检查该分区的消息键是否形成热点、是否有大消息、是否有一条处理很慢的记录。所有分区同时增长，则检查消费者实例资源、下游依赖、网络、序列化和批次处理耗时。

第三，查看消费者组状态和分配变化。频繁重平衡会让实例反复加入和离开，正常消费时间被分配、撤销和恢复打断。记录每次 rebalance 的时间、原因、成员数量和分区分配，结合应用日志寻找心跳超时、处理超过 poll 间隔或实例异常退出。

第四，查看处理阶段的耗时分布，而不是只看平均值。平均处理 50 毫秒并不能说明系统健康，如果少量消息需要几十秒，批次确认和 offset 提交可能被长尾拖住。把 poll、反序列化、业务处理、外部写入、提交分别计时，才能判断瓶颈在哪里。

按根因选择修复动作

生产突增或下游暂时变慢

如果生产端短时间突增，但消费者处理速度和实例健康，通常不需要立刻改配置；先估算积压是否会在日志保留期内追平。如果不能追平，再考虑增加消费者实例、提升处理并行度或临时降低非关键生产流量。扩容只有在有可分配分区时才有收益，一个分区同一时刻只能由一个组成员消费；实例数超过分区数不会线性提高吞吐。

如果业务处理依赖数据库、HTTP 或文件系统，先检查这些依赖的延迟和错误率。直接增加消费者可能把下游打得更慢，形成“实例越多，重试越多，lag 越高”的反馈。更稳妥的方式是给外部调用设置超时、隔离连接池、使用批量写入或把非关键操作异步化，同时保持 offset 不领先于已完成处理。

单分区热点

单分区热点通常不是客户端实例数量问题。先确认生产端 key 的分布和该分区的消息大小，再检查是否存在顺序要求。若业务允许重新分区，可以设计更均匀的 key；若必须保持同一业务实体有序，就不能简单随机打散，而应把慢处理移出消费主线程，或将大任务拆成可追踪的子任务。改变分区数也会影响 key 到分区的映射，必须评估重分区后的顺序和重放影响。

处理时间超过 poll 间隔

消费者需要持续调用 poll 维护组成员关系。若单批处理时间长期超过允许的 poll 间隔，组可能认为成员失活并触发重平衡；重启后又从较早的 committed offset 读取，lag 反复升高。KafkaConsumer Javadoc 建议，对于处理时间不可预测的场景，可以把处理移到其他线程，同时避免提交超过真实处理位置，并在处理期间暂停相应分区。

实现上要为每条消息保存处理状态，只有成功完成的连续范围才提交。不能为了避免重平衡而直接提交整个 poll 批次，因为那会把未处理消息标记为已消费。若消息处理不可拆分且确实很慢，应根据最大处理时长重新评估 poll 相关配置，并配合超时、重试和死信策略；只调大超时而不处理下游长尾，故障恢复仍会很慢。

Poison pill 与持续重试

某条无法解析或违反业务约束的消息可能让消费者在同一 offset 无限重试，表现为某分区 lag 不再下降、CPU 不高但日志重复刷屏。先记录 topic、partition、offset、消息键和错误类型，确认问题消息不会被无限重试。根据业务要求，可以把消息转入隔离队列并提交到该 offset 之后的位置，或暂停该分区等待人工修复；任何跳过都必须有原始消息保留和补偿记录，不能静默丢弃。

恢复动作的次序

先止血：限制无效重试，恢复下游依赖，必要时暂停非关键分区；再恢复吞吐：按分区能力增加成员或提高批处理效率；最后补齐数据：让消费者从安全提交点继续追赶。auto.offset.reset=latest 不是清理已有 committed offset 的命令。Kafka 官方配置文档规定，它只在消费者没有初始 offset，或当前 offset 已不再存在于 broker（例如日志保留清理了该位置）时生效；此时消费者会把位置重置到最新可用位置。若存在有效的 committed offset，latest 不会覆盖它。因此，排查时必须同时记录 committed offset 与 position：前者决定重启或重平衡后的恢复点，后者表示当前下一条要拉取的位置；只有在确认没有有效提交位点或位点已经越过保留边界后，才评估该重置行为是否会跳过仍需补齐的历史消息。

如果确实需要重置 offset，先导出当前组状态、保留要重放的时间范围和分区映射，计算目标 offset，并确认下游具有幂等能力。重置后应先在一个分区或临时组验证，再扩大范围。重放期间可能产生重复写入、顺序变化或下游压力，必须设置速率限制并监控错误率。

在 StreamWorks 中，可以利用任务的 Metric 曲线、运行日志和异常告警观察实时延迟，但告警本身不能替代 Kafka 的分区级核对；恢复前仍要把 group、partition、position、committed offset 和下游处理结果对应起来。

如何证明已经恢复

lag 下降只是一个信号，不是验收结论。至少同时检查：所有异常分区的 lag 是否下降且没有重新上升；生产和消费速率是否恢复到稳定关系；重平衡次数是否回到正常水平；处理错误、重试和下游超时是否消失；提交 offset 是否持续前进；日志保留窗口内是否仍有未覆盖的时间段。

可以选择一个已知事件，从生产时间、Kafka offset、消费日志、下游写入时间一路追踪。对重复处理的系统，还要比较业务唯一键的最终状态，而不是只比较消息数量。对事务消费者，要以可提交事务的可见终点为准，避免因为开放事务而误判恢复失败。

容易误用的修复方式

只加实例是最常见误区：没有足够分区、下游已饱和或存在单分区热点时，扩容不会解决问题。只调大批量也可能增加单批处理时间和失败重做范围。只看总 lag 会遗漏局部热点；只看 committed offset 又可能掩盖处理线程仍未完成。还有一种危险做法是删除并重建消费组，这会改变恢复点，必须把它当作数据操作而不是普通运维动作。

把排查过程沉淀为固定记录：哪几个分区先增长、生产和消费速率如何变化、最长处理耗时是多少、最后一个安全提交点在哪里、采取动作后哪些指标恢复。这样下一次积压出现时，团队可以从证据进入决策，而不是从“重启一下”开始。