百万消息积压的两小时，我们做了什么

周五 22 点告警：核心 topic 消费 lag 从 2 万涨到 100 万，还在爬。把处理时间线记下来，这类事故的应对本身值得复用。

第一步定位为什么积压。消费组监控显示三台消费者 CPU 正常、GC 正常，但消费速率从 4000 每秒掉到 300。消费者日志里大量处理超时——下游风控接口故障，每次调用挂 30 秒才超时。瓶颈不在 Kafka，在消费逻辑里的同步外部调用。

第二步止血三板斧：下游调用超时从 30 秒降到 2 秒（配置中心秒级下发）；非关键校验逻辑用预埋的开关摘除；消费者临时扩到 10 个（分区数 12，天花板就在这）。消费速率回到 5000 每秒，40 分钟消化完积压。

第三步防复发，落到消费参数和熔断：

# 消费者关键参数
max:
  poll:
    records: 100        # 单批拉小，防单批处理超时
poll:
  interval:
    ms: 300000          # 两次 poll 最大间隔，超时触发重平衡

max.poll.records 调小配合 poll.interval 是防重平衡的组合：单批处理时间必须小于间隔上限，否则消费者被踢出组，重平衡雪上加霜。外部依赖全部包熔断（失败率 50% 打开、半开探测），下游故障时走快速失败加小重试。告警阈值从 lag 十万改成一万，另配增速告警。

复盘一句话：积压是症状，病因几乎总在消费端的外部依赖。扩消费者只是最后手段，分区数就是天花板——平时按故障场景演练过，才知道极限在哪。那次之后每季度一次积压演练成了固定动作。