Kafka 消费积压排查：从 rebalance 到扩容的决策流程

消费积压（consumer lag）只是一个症状，直接"加消费者"往往治标不治本，甚至加剧问题——当分区数不够时，加消费者只会反复触发 rebalance。正确的排查顺序是：先确认积压是否真实、属于哪种类型，再按 rebalance → offset 提交 → 消费者扩容 三类诱因逐一排查，最后区分应急处理与根因治理。

第一步：确认积压的真实性与类型

用监控指标回答三个问题：

• consumer_lag（当前消费 offset 与 log-end offset 之差）是持续增长还是保持稳定；
• 生产速率与消费速率（bytes-in / bytes-out）谁高谁低；
• 消费者处理耗时（poll 循环耗时、单条处理耗时）是否异常。

据此把积压分成两类：追赶型（lag 恒定，消费速率与生产持平，只是历史欠账）与失速型（lag 持续增长，消费跟不上生产，需要立即介入）。两类积压的处理手段完全不同：追赶型一般靠时间消化或适度扩容，失速型必须马上定位瓶颈。注意还要排除"假积压"：某些监控采集的是 log-end offset 与当前 offset 之差，但如果消费者短暂停止（如发布重启），lag 会瞬时上升又回落，不代表真积压，要结合时间窗口观察趋势。

第二步：按三类诱因排查

诱因 A：rebalance 频繁

症状：lag 呈锯齿状（每次 rebalance 后跳升）、日志中出现大量 rebalance 记录、消费组状态频繁变化。

排查点：

• session.timeout.ms 过小，或单次处理耗时超过 max.poll.interval.ms，消费者被判定死亡；
• max.poll.records 过大导致单轮 poll 处理超时，主动触发 rebalance；
• 分区再分配（如 broker 变动）导致"已消费未提交"的 offset 重放；
• 消费者实例频繁扩缩容或发布重启，也会引入不必要的 rebalance。

对策：调大 max.poll.interval.ms 或减小 max.poll.records；开启静态成员资格（group.instance.id），让消费者短暂网络抖动时不被踢出消费组；发布时采用滚动重启而不是全量重启。rebalance 期间消费是暂停的，所以每次 rebalance 都会带来一段"消费空窗"，频繁 rebalance 等于频繁暂停。

诱因 B：offset 提交问题

症状：lag 不大但数据重复或丢失，或提交阻塞导致消费暂停。

排查点：

• 自动提交（enable.auto.commit=true）且处理与提交之间存在大窗口，崩溃后同一批数据被重放；
• 手动提交使用同步 commitSync 且处理慢，poll 被阻塞，消费吞吐下降；
• 提交粒度（按批还是按记录）与业务幂等能力不匹配；
• 提交时抛异常且未处理，导致 offset 一直不前进。

对策：处理成功后再提交；异步提交加定期同步兜底；消费端做幂等（唯一键去重），容忍至少一次语义。要理解 offset 提交与"数据处理成功"是两个时刻：如果先提交后处理，处理失败时数据已"丢失"；如果先处理后提交，崩溃时会重复消费——没有完美的方案，只能选"至少一次"配合幂等，或者"精确一次"配合事务（成本更高）。

诱因 C：消费者扩容不当

症状：消费者数大于等于分区数时，新增消费者不生效（分区已被占满），只会触发 rebalance。

排查点：

• 当前分区数与消费者数各是多少；
• 分区分配是否均匀（range 分配在分区数少时容易让部分消费者空转）；
• 是否有热点分区集中在单个消费者上（某分区消息量大或单条处理慢）。

对策：扩容前先评估"分区数是否够"；分区数不足且业务允许时增加分区（注意：分区数只能增不能减，且会改变同 key 消息的顺序保证），再扩容消费者到不超过分区数；热点分区则优先处理该分区的瓶颈（如单条消息过大、处理逻辑有慢调用），而不是简单加消费者。

第三步：应急处理 vs 根因治理

应急处理（先止血）：

• 分区有富余：按需增加消费者，最多加到分区数；
• 分区不足且业务允许：增加分区并重置消费组 offset 到目标位置；
• 单条处理过慢：临时减小 max.poll.records 降低单批压力，或临时提高消费者实例规格缩短单条耗时；
• 业务允许丢弃部分数据：seek 到指定 offset 跳过积压区间——必须先与业务确认。

根因治理（再治本）：

• 优化处理逻辑：减少外部调用、批量写入、合并多次网络往返；
• 改造提交策略与消费幂等，消除重复与丢失；
• 容量规划：按峰值生产速率乘以单条处理耗时估算所需分区数，留出 30% 以上余量；
• 建立分级告警：lag 阈值加增长率，区分白天高峰与夜间低谷的基线，避免误报。

应急与治理的分界线在于"是否修改了长期配置"：应急处理允许临时改参数、临时扩容，但每一项都要记录在案，并在积压消除后回滚；根因治理则是把临时方案固化为长期能力（容量规划、监控基线、幂等改造）。如果只做应急不做治理，同样的积压会在下一个业务高峰再次出现。

一个容易误判的细节：lag 的度量口径

同一时刻，从不同工具看到的 lag 可能不一样：有的按"当前 offset 与 log-end offset 的差值"计算，有的按"消费时间与最新消息时间的差值"计算，还有的按"消费组每个分区 lag 的最大值或总和"展示。排查前先统一口径，否则会出现"监控显示积压、实际消费正常"或相反的情况。建议以"按分区维度的差值型 lag"为准，同时记录最大值与总和：最大值暴露热点分区，总和反映整体压力。

另外要区分"任务型消费者"与"常驻型消费者"。任务型消费者（如批处理）处理完当前批次就退出，lag 会在任务间隙自然增长，这类"积压"是设计使然；常驻型消费者（如实时链路）lag 应长期接近零。告警规则要按消费者类型分别设置，否则任务型消费者的正常间隙会持续误报。

监控指标清单

• 每个消费组按 topic-partition 维度的 consumer_lag；
• rebalance 次数与频率；
• 消费组状态（Active / Dead / Empty）；
• poll 间隔与处理耗时的分位数（p99）；
• offset 提交成功/失败次数与 commit 耗时；
• 分区数与消费者数快照（用于判断扩容是否还有效）。

一个完整的应急恢复序列

1. 确认 lag 的真实性与量级（消费组、topic、受影响分区）；
2. 判断是追赶型还是失速型积压；
3. 检查 rebalance 频率与最近事件，若频繁 rebalance 先修消费者配置；
4. 检查处理耗时与提交行为，锁定瓶颈环节；
5. 扩容：分区有富余则加消费者，否则评估加分区并重置 offset；
6. 观察 lag 曲线是否收敛；收敛后回切配置，进入根因治理。

下一步

把分区数、消费者数、处理耗时 p99、rebalance 频率四类指标接进监控面板并设置分级告警（阈值加增长率双条件）；为核心消费组编写一份积压应急手册，明确"谁触发、先看什么、什么情况下允许 seek"，下次积压时按手册操作而不是临场判断。