Kafka 消费堆积先判断是慢消费还是下游故障一、Lag 上升只是症状Kafka 消费 lag 上升时很多人第一反应是加消费者实例。但 lag 上升可能来自消息突增、消费者处理慢、下游数据库故障、分区数不足、rebalance 频繁、单条消息卡住或业务逻辑异常。加实例只对部分场景有效盲目扩容可能把下游打得更狠。排查消费堆积先判断是消费能力不足还是下游不可用。如果消费者 CPU 很低、处理耗时高、下游错误多问题不在 Kafka如果消费者 CPU 打满、下游正常才可能是消费能力不足。二、排查链路Lag、吞吐、耗时一起看flowchart TD A[消费 Lag 上升] -- B[看生产速率] B -- C[看消费速率] C -- D[看处理耗时] D -- E[检查下游] E -- F[扩容或降级]Lag 要结合生产速率看。活动期间生产速率突然翻倍短时间 lag 上升可能正常生产速率恢复后能追上就不是严重问题。若生产速率正常但 lag 持续上升说明消费侧或下游有瓶颈。还要看分区数。Kafka 同一个 consumer group 内一个分区同一时间只能由一个消费者消费。消费者实例数超过分区数后再扩容也没用。分区设计是吞吐上限的一部分不能等堆积时才想起来。三、监控指标不要只盯一个 Lag下面是一组建议指标。它们能帮助判断瓶颈位置。kafka_consumer_metrics: - records_lag_max - records_consumed_rate - records_processed_latency_p95 - poll_interval_ms - rebalance_count - downstream_error_rate - commit_latency_mspoll_interval_ms过长可能触发 rebalance。处理逻辑太慢、单批消息太大或线程阻塞都可能导致消费者没及时 poll。rebalance 频繁时消费会反复暂停lag 更难下降。提交位点也要谨慎。业务处理成功后再提交能避免丢消息但如果单条消息一直失败会阻塞后续消息。需要死信队列或跳过策略避免坏消息卡住整个分区。四、处理策略扩容、限流和降级要配合如果瓶颈在消费者 CPU可以增加实例或优化处理逻辑如果瓶颈在数据库要限流或批量写入如果瓶颈在外部接口要降级、异步重试或进入死信。策略必须针对瓶颈不要把所有堆积都当成消费者不够。批量处理可以提升吞吐但会增加单批失败成本。要控制 batch size并记录每条消息处理结果。大批量写库时还要注意事务时间和锁竞争。最后堆积恢复也要保护下游。lag 很大时消费者追赶会形成高峰可能把刚恢复的数据库再次打挂。可以限速追赶优先处理高优先级 topic 或关键消息。恢复阶段也需要架构设计。还要提前定义告警分级。短时间 lag 上升可以提醒持续无法追平才需要升级核心 topic 和低优先级 topic 的阈值也不一样。告警如果不分级值班人员会被普通波动淹没。Kafka 的稳定性不只在 broker也在消费侧的运营纪律里。死信队列要有人看。把失败消息丢进 DLQ 后如果没人处理只是把问题换了个位置。DLQ 应该有数量告警、重放工具和人工处理流程。五、总结Kafka 消费堆积要先判断慢消费、消息突增还是下游故障。Lag 只是症状生产速率、消费速率、处理耗时、rebalance 和下游错误率才是证据。扩容有用但不是唯一答案。