消息队列积压处理实战：从 consumer 扩容到死信设计的完整预案

积压不是故障，是「欠债」

消息队列积压时，多数团队的条件反射是「加消费者」。这个动作只对一半的场景有效——如果下游是数据库，加消费者就是把队列的债转给数据库，最后两条链一起挂。积压处理的前提是先回答：生产速率为什么突增？消费能力为什么下降？这批消息能不能丢、能不能延迟？这篇给一套完整的处置预案。

一、先止血：三个立即动作

1. 停掉非关键生产者：大促/故障时刻，日志类、统计类消息先降级或丢弃，把带宽让给交易类消息——按 topic 分级是预案里就该写好的；

2. 消费者扩容的边界：扩 consumer 前先看下游——下游是数据库就先扩数据库读能力或加缓存，下游是无状态服务才能放心扩；partition 数限制并发上限（Kafka 一个 partition 一个 consumer），扩容前确认 partition 规划；

3. 跳过策略：可丢的消息（监控埋点、日志）设置「跳到最新」——先保实时流量，历史欠账用离线补录。

二、再还债：欠账处理的三种模式

止血后处理存量积压，按消息性质选模式：

- 重放模式：存量消息转储到新 topic，用临时消费者集群（独立资源组）全速消化，产出的结果直接写库或写缓存，绕过常规下游；

- 批量模式：如果积压的是「状态同步类」消息（如缓存刷新），可以不做逐条处理——直接用数据库当前数据全量刷一遍缓存，跳过队列里的百万条旧消息；

- 丢弃模式：统计类消息超过时效就失去价值，直接按时间戳截断丢弃，只保留最近 N 小时。

一个实战案例：2 亿条缓存刷新消息积压 14 小时，逐条消费需要 3 天——改用「全量刷新」方案 40 分钟解决，队列清空。

三、根因预防：从架构上消灭积压

1. 生产削峰：生产者侧加本地缓冲与限流，瞬时高峰先落本地再匀速入队；

2. 消费弹性：消费者组做成 HPA 可伸缩的部署（K8s 里按 lag 指标自动扩缩容）；

3. 死信与隔离：处理失败 N 次的消息进死信队列单独处理，避免「一条毒消息卡住整条分区」；

4. 容量预案：按大促峰值压测过「生产速率 X 时的最大可承受积压」，超线自动触发预案——预案写在飞书上不叫预案。

四、监控四指标

积压预防的监控底线：Lag 绝对值、Lag 增速、消费失败率、最老消息年龄。Lag 增速比绝对值更重要——增速转正就是扩容信号。四指标配到告警面板，积压才会从「用户投诉才发现」变成「扩容告警先响」。

结语

积压处置的顺序是：止血（分级+扩容+跳过）→ 还债（重放/批量/丢弃）→ 根因（削峰/弹性/死信）→ 监控（四指标）。队列是缓冲器不是无限仓库，把「积压预案」写成和大促预案同级的文档，才是队列架构师的合格线。