消息积压：十万条消息堆着怎么办

老王的值班夜

周日晚上八点，告警响了：ORDER_PAID 队列积压 50 万条，且还在涨。积分服务消费 TPS 从两千掉到三百，用户开始反馈「下单了没积分」。老王深吸一口气，先给自己立了条规矩：先诊断，再动手——积压时乱开药方比病更危险。

第一步：诊断积压的病因

老王一看监控：生产 TPS 正常，消费 TPS 腰斩，积分库的慢查询飙升——病根在下游数据库，不是消息变多了，是干活的人虚了。

第二步：止血三板斧

第一斧：加机器，但有天花板。扩消费者的第一性原理要记牢：消费者数量不能超过队列数。8 个队列最多 8 个消费者有效干活，第 9 个只能干瞪眼。队列不够就先扩队列（RocketMQ 控制台改 Topic 队列数；Kafka 扩 partition），再同步加消费者。Kafka 扩 partition 有个副作用要掂量：key 哈希的映射关系变了，顺序消息的顺序保证会被打破。

第二斧：单机榨干。来不及加机器时，先提单机消费并发：调大消费线程池、调大批量拉取条数（一次拉 100 条批量处理）、把消费逻辑里的串行 RPC 改并行。但下游是瓶颈时慎用——消费线程加得越猛，下游死得越快，水位反而涨得越凶。

第三斧：降级非核心动作。消费逻辑里排着优先级：发积分是核心，写消费日志、发短信是次要。紧急状态下，次要动作改成先落任务表后补执行，消费 TPS 立刻翻倍。降级开关平时就要备好，现场写来不及。

第三步：积压太深时的奇兵——紧急转储

如果积压是百万级、按现有消费力要消化一天，常规手段都太慢。上奇兵：

1 写一个「搬运工」消费者：不做业务，只把消息快速转发到新 Topic
   （新 Topic 队列数拉到 100 个），单条转发耗时极低，积压迅速清空
2 新 Topic 上拉起 100 个真正的业务消费者并行消化
3 修完主故障，把新 Topic 剩余消息重放回主 Topic，恢复正常链路

转储的本质是把「一条队列的消费并行度」瞬间放大百倍。代价是消息经历了额外一跳，全程要盯紧重复与丢失——重放和搬运都要幂等兜底。

最后手段：跳过

业务上确认这批消息可以放弃（比如过期的库存刷新事件），可以把消费位点直接重置到最新，跳过堆积段。注意：跳过就是丢消息，执行前把跳过的消息落一份到补偿库，事后逐条对账补发。跳过是创可贴，不是治疗方案。

事后：让下一次积压不来

• 积压告警分级：水位超 10 分钟消费量告警，超 1 小时消费量升级 call 人；
• 容量留余量：消费能力按峰值流量的 2 倍压测预留，队列数提前扩够；
• 下游保护：慢查询治理、接口熔断，下游不塌消费就不塌；
• 预案演练：转储脚本、跳过工具、降级开关提前备好并演练，值班手册写到页。

小结

积压处置的顺序：先诊断病因，再止血（扩容、榨单机、降级），深的上转储，绝境才跳过。每个动作的适用边界和副作用都要烂熟——现场没有时间给你翻文档。

可靠性三部曲（不丢、不重、有序）加上运维三课（重试、死信、积压），MQ 的「用」讲完了。下一篇开始「为什么」：Kafka 凭什么每秒百万条——顺序写、零拷贝、批量压缩三板斧的原理。