前言
昨天帮一个 3 年经验的兄弟复盘阿里二面，他心态崩了。
面试官问了一个非常经典的生产场景：“线上 RocketMQ 突发流量，导致 Topic 积压了 1 亿条消息，下游消费速度跟不上，导致系统报警。你作为 Tech Lead，这时候该怎么救火？”
这兄弟想都没想，脱口而出：“很简单啊，横向扩容！多申请几台机器，启动新的 Consumer 实例，把消费并行度拉上去，刷刷刷就消费完了。”
面试官冷笑一声，甩出两道送命题：
“你 Topic 只有 4 个 Queue，你扩容到 100 台机器有什么用？剩下的 96 台都在围观吗？”
“那你为什么不直接修改 Topic 配置，把 Queue 扩容到 100 个？”
兄弟当场傻眼，最后灰溜溜地挂了电话。
说实话，“加机器”是初级开发最喜欢用的万能药，但在 MQ 积压场景下，这招往往是无效的，甚至可能导致系统全线崩溃。
今天带你拆解 RocketMQ 积压处理的3 个“生死关卡”，以及1 个 架构师视角的“隐藏杀招”。
一、 致命盲区：Queue 与 Consumer 的“一夫一妻制”
为什么面试官嘲笑“加机器”？ 因为他考的是你对RocketMQ 负载均衡（Rebalance）底层原理的理解。
在 RocketMQ 的集群消费模式（Clustering）下，有一个铁律：一个 Queue（队列），在同一时间，只能被同一个 Consumer Group 下的一个消费者实例消费。
算笔账：
你的 Topic 创建时设置了4 个 Queue（默认值）。
你现在的 Consumer Group 有2 台机器。
结果：每台机器分到 2 个 Queue。大家都满载工作。
这时候你扩容：
你一口气扩容到了10 台机器。
结果：
前 4 台机器，每人分到 1 个 Queue。
后 6 台机器，分不到任何 Queue，只能干瞪眼，CPU 占用率 0%！
结论：如果不扩容 Queue 数量，光加 Consumer 机器，哪怕你加到 1 万台，消费速度也不会提升 1 毫秒。
二、 逻辑陷阱：为什么不能直接修改 Topic 扩容？
这是 P7 面试官最喜欢挖的坑。“既然 Queue 少，那我直接去控制台把 Queue 数量改成 100 不行吗？”
答案是：不行！
原因极其硬核：
历史包袱：那积压的 1 亿条消息，已经存储在老的 4 个 Queue 里了。
新旧隔离：你扩容到 100 个 Queue，RocketMQ 只会把新来的消息发到新的 Queue 里。
无济于事：对于那 1 亿条老积压，它们依然死死地躺在旧的 4 个 Queue 里，依然只能由 4 个消费者去慢慢消化。
所以，直接改配置，解不了近渴。
三、 终极救火方案：李代桃僵（搬运工模式）
既然原 Topic 的物理存储结构已经限制死了，那如果你真的积压了 1 亿条，标准的大厂救火 SOP（标准作业程序）只有这一招：
第一步：临时扩容大法（不改原代码）
不要试图去改原本复杂的业务逻辑（耗时、易错）。 你需要写一个“搬运工”程序（或者配置一个临时的 Consumer Group）。
核心逻辑：
这个“搬运工”只做一件事：光速把消息读出来，不处理业务，直接丢到另一个新的 Topic（我们叫 Topic-Temp）。
因为不处理业务（不查库、不计算），所以这个“搬运工”的消费速度是极快的（接近 IO 极限），4 台机器就能把 4 个 Queue 的积压迅速搬空。
第二步：在新 Topic 上大展拳脚
新建 Topic-Temp：这次学乖了，创建时把 Queue 设为100 个。
部署业务 Consumer：把真正的业务逻辑部署 100 台机器，订阅 Topic-Temp。
结果：100 个 Queue 对应 100 台机器，火力全开，真正的并行消费。
画外音：这叫“空间换时间”。 原 Topic 的 Queue 限制了你，那我就把水引到一个更宽的池子里再去处理。
四、 “防杠”指南：三个致命隐患（必看）
如果你答完上面的方案，面试官大概率会点头。但想拿 SSP（Special Offer），你必须主动指出这个方案的风险点。
隐患 1：顺序消息的“火葬场”
警惕：如果你的消息是严格顺序的（比如：订单创建 -> 支付 -> 完成），千万别用“搬运工模式”！ 多线程并发读取旧 Queue，再乱序写入新 Topic，会导致下游先收到“支付成功”，后收到“订单创建”。
对策：如果必须搬运，搬运时必须保留原有的 Sharding Key（如订单号），确保同一个订单的消息依然进入新 Topic 的同一个 Queue。
隐患 2：Broker 的 I/O 爆炸
警惕：积压时，Broker 压力本来就大。你搞个搬运程序，一边疯狂读旧消息，一边疯狂写新消息，I/O 直接翻倍。
对策：动手前先看监控。如果 Broker 磁盘或 CPU 已经红了，禁止搬运！先扩容 Broker 才是正解。
隐患 3：数据库（DB）能抗住吗？
警惕：你扩容了 100 个消费者，消费速度是快了，但你的数据库（MySQL）受得了吗？ 如果积压的根源是数据库慢，你这 100 个并发冲过去，相当于对自己发起了 DDoS 攻击，瞬间把数据库打挂，造成 P0 级全站瘫痪。
对策：扩容消费端前，必须评估下游 DB 的承载能力。如果 DB 是瓶颈，加机器等于自杀。
五、 残酷的 Plan B：弃车保帅
如果积压的消息是“非核心数据”（如日志、埋点、非资金类通知），且积压量太大影响了新消息的进入。
成年人的世界，有时候必须学会舍弃。
最快方案：
Skip Offset：直接修改 Consumer 的 Offset，跳过这 1 亿条老积压。
丢进死信：或者把老积压全部导流到死信队列，等空闲了再慢慢处理。
止损：让系统立刻恢复实时水位，保住当下的业务。
四、 面试标准答案模板（直接背）
如果面试官再问“消息积压”，别再说“加机器”了，按这个逻辑输出：
1. 破题（指出限制）：“RocketMQ 的队列模型决定了消费者数量不能超过 Queue 的数量。单纯加机器无效。”
2. 避坑（原 Topic 扩容无效）：“即使直接修改原 Topic 的 Queue 配置，也无法解决存量积压，因为旧消息依然存储在旧队列中，无法并行消费。”
3. 解决方案（转发+扩容）：“我的方案是‘流量分流 + 临时扩容’：上线一组不带业务逻辑的‘搬运 Consumer’，只负责把积压消息转发到一个 Queue 数量为 100 的临时 Topic 中。然后上线 100 个真实的业务 Consumer 去消费那个临时 Topic。 ”
4. 兜底（高阶思维）：“但在执行前，我会确认三点：1）消息是否要求严格顺序？2）MQ 集群的I/O是否有余量？3）下游MySQL能否抗住 100 个并发的洪峰？如果是非核心数据，我会建议直接丢弃或跳过积压，优先保证服务恢复。”
写在最后
MQ 积压，本质上是“生产速度 > 消费速度”。 解决积压只是止血，事后复盘一定要查原因：
是数据库慢了？
是第三方接口超时了？
还是代码里有死锁？
https://mp.weixin.qq.com/s/ih6hhTPTAgfT0L6MLObmqA
