RocketMQ消息堆积1亿条应急处理与架构反思

你有没有过这种经历？面试到最后一轮，面试官突然抛出一个灵魂拷问：

“如果RocketMQ突然积压了1亿条消息，系统都报警了，你作为技术负责人该怎么去解决这个问题？”

这个时候，如果你张口就说“加机器”，那恭喜你，面试基本凉了。这是初级开发最容易踩的坑，也是面试官筛选真正有实战经验的工程师的试金石。

为什么单纯加机器没用？

要回答这个问题，首先得搞懂RocketMQ的核心规则：在集群消费模式下，一个queue在同一时间只能被同一个consumer group的下一个消费者实例消费。简单来说就是queue和consumer是一对一的绑定关系。

我给你算一笔账：

• 你的topic用的是默认配置，通常是4个queue
• 现在你有两台消费的机器，每台机器分配两个queue刚好满负荷工作
• 这个时候如果你觉得消费速度不够，一口气扩容到100台
• 结果会怎么样？只有前4台机器能分到queue，每台负责一个，剩下的96台机器根本就没活可干，CPU占用率几乎为0

这就像给一口快干的老井挖了口新井，老井的水该干还是干，根本解不了近渴。

大厂的解决方案：空间换时间

真正可行的解决方案是什么？大厂的思路是 空间换时间，我把这个方案叫做 消息转发加临时扩容的搬运模式，分两步走，既简单又高效。

第一步：消息搬运程序

先上线一个消息搬运的程序，不用修改原来复杂的业务代码（修改业务代码耗时久还容易出bug）。专门写一个临时的consumer程序，这个程序不处理任何的业务逻辑，不查数据库不做业务计算，就干一件事：把旧的topic里面积压的消息快速的读出来，直接转发到一个新的临时的topic里，比如可以叫 topic_temp。

正因为不带任何业务逻辑，搬运程序的处理速度能接近系统的IO极限，用几台机器就能快速把原来4个queue里面的积压消息搬空。

第二步：并行消费

在新的topic上实现真正的并行消费：

1. 新建 topic_temp 的时候把queue的数量直接设置为100（如果不够还可以再增加）
2. 部署100台运行业务逻辑的消费者机器，专门订阅新的topic
3. 这100个queue就对应着100台机器，每台机器都能分配到对应的任务，真正实现了并行消费

三个潜在的风险

这个方案不是完美的，如果想拿到高薪的offer，必须主动说出这个方案存在的3个潜在的风险，这其实就是区分架构师和普通开发的关键所在。

风险一：顺序消息的处理问题

如果你的消息有严格的顺序要求，比如创建订单、支付订单，绝对不能随便转发。多线程并发读取旧的queue，再乱序写入新的topic，很有可能就会导致下游系统先收到支付成功的消息，再收到订单创建的消息，直接造成业务逻辑的混乱。

解决办法：转发消息的时候必须保留原来的sharding key，比如订单号，确保同一个订单的所有消息都进入新的topic的同一个queue里面，这样就能保证消息的顺序不混乱。

风险二：Broker IO爆炸

搬运程序一边疯狂的读取旧消息，一边疯狂的写入新消息，这就会让RocketMQ的Broker磁盘读写和CPU压力直接翻倍。本来Broker就因为消息积压处于高负载的状态，再这么折腾很可能就直接导致Broker宕机，让问题雪上加霜。

解决办法：动手之前一定要先看监控数据。如果Broker的IO使用率已经很高，出现告警，必须先扩容Broker集群，缓解它的负载压力，再进行消息的搬运。

风险三：数据库能抗住吗？

你需要考验下游数据库的承载能力。你把消费速度提升100倍，也就意味着下游MySQL要承受100倍的并发查询压力。如果消息积压的根源本来就是数据库处理速度慢，那这100个并发请求过去就相当于对自己的数据库进行一次压力攻击，很有可能直接导致数据库宕机，引发全站瘫痪的P0事故。

解决办法：扩容消费端之前，必须先评估下游DB的承载能力。如果数据库是整个链路的瓶颈，盲目加机器只会适得其反。你需要考虑分库分表、读写分离，或者使用更强大的数据库方案来应对。

特殊情况：非核心数据的处理

如果积压的是日志、打点这类非核心的数据，而且已经影响到核心业务的实时处理了，这个时候要懂得取舍，优先保证核心业务的正常运行。最快的兜底方案就是优先止损：

• 要么直接修改consumer的消费位点，跳过1亿积压数据
• 要么把这些老消息全部导流到死信队列，等业务高峰期过去之后再慢慢地处理

这么做的核心目标只有一个：先让系统恢复到实时处理状态，保住当下的业务。

事后复盘优化

处理消息积压只是紧急止血，真正重要的是事后的复盘优化，要深入排查问题的根源：

• 到底是数据库处理慢了？
• 还是第三方接口超时导致消费卡住了？
• 又或者是代码里存在死锁，影响了消费的效率？

不能只做只会重启机器、加机器的执行者，更要做能够看透本质、设计合理解决方案的架构师，这才是提升核心竞争力、拿高薪的关键。

总结

面试的时候，如果你能按照这个思路回答，面试官一定会眼前一亮。不仅能体现你对RocketMQ底层原理的理解，还能展示你处理实际生产问题的能力和架构思维。

记住，面试官想看到的不是你会背多少API，而是你在面对复杂问题时的思考方式和解决能力。希望这个从实战中总结出的方案能帮到你。如果你对RocketMQ或其他分布式系统问题有更多想法，欢迎在云栈社区与更多同行交流探讨。