企业官网建设流程全解析

面试时候被问到“RocketMQ 消息堆积怎么办”，其实真正想听的未必是标准操作，而是你有没有独立处理过线上压测和真实故障。因为消息堆积背后的坑太典型了：消费速度跟不上、队列并发配错、死信没人管、监控看不到积压趋势。这篇文章不打算背八股，我会把排查思路、应急手段、治本方案、还有我实际踩过的坑全部摊开讲一遍，适合正在准备面试的研发同学，也适合已经上了 RocketMQ 但还没遭过大堵车的运维和架构师。

先说一下我的态度：消息堆积本身不可怕，可怕的是堆积之后你还在乱加机器。很多人一看到积压数字变红，第一反应就是扩容消费者实例，结果加了 20 台上去，积压一点没降。为什么？因为 RocketMQ 的消费并行度根本不由机器数量决定，队列数量才是上限。这些底层机制不搞明白，后续所有操作都是盲人摸象。

这篇内容从堆积发生的原理讲起，再给出一套完整的排查命令和监控指标，然后按“应急、优化、扩容、治本”四个层次拆解解决方案，最后附上真实案例复盘和日常预防体系。你可以把它当作一张消息堆积处理的地图，线上出了状况照着走，至少不会慌。

1. 消息堆积的本质：先搞清楚消息积压在哪里

1.1 一条消息从生产到消费，堆积到底发生在哪个环节

我特别喜欢用一个比喻来解释 RocketMQ 的消息流转：生产者是拧开的水龙头，消费者是下水道地漏，Broker 是中间的蓄水池。正常情况下水龙头进水速度和地漏排水速度差不多，水池水位稳定；一旦进水速度超过排水速度，或者地漏本身堵了，水位就开始涨。RocketMQ 里的“水位”，就是消费位点（ConsumerOffset）和最大位点（MaxOffset）的差值，也就是我们常说的积压量。

你手上有这么一条链路，Producer 把消息写到 Broker，Broker 把消息顺序追加到 CommitLog，同时按照 Topic 队列生成逻辑索引 ConsumeQueue，然后等消费者来拉取。消息一旦进了 CommitLog，它就稳稳地躺在 Broker 磁盘上，不存在“弄丢”的可能，唯一的问题是消费者有没有及时把它消费掉并提交位点。所以严格来说，消息堆积不是消息在 Producer 端堵住，而是 Broker 里的消息没有被消费者按照正常速度取走，属于消费侧问题。

这里有一个很多人容易忽略的细节：Broker 上的“积压”其实分两块，一块是正常业务 Topic 下每个队列里未被消费的消息，另一块是消费失败后进入的重试队列和死信队列。当你打开 Dashboard 看某个消费组的积压数量时，统计口径通常是所有队列位点差值的总和，但如果业务里消费失败率很高，你会发现重试队列里其实还压着一批“隐形积压”，主队列看着还好，实际消息已经从主队列挪到重试队列了，消费滞后依旧无法缓解。这个视角很重要，因为很多排查手段第一步都盯主队列，结果忽略了重试和死信。

还要注意，Broker 侧每个 Topic 默认会划分成多个队列，比如默认创建 4 个写队列和 4 个读队列。消息会按照选择策略分配到不同队列里，而消费端同一个消费组的消费者实例会瓜分这些队列。水位到底是均匀上涨还是某个队列单独暴涨，这是判断瓶颈位置的第一张图。

1.2 消费并发模型和重试机制，决定了你能怎么处理堆积

RocketMQ 的客户端虽然叫 PushConsumer，但底层其实是长轮询拉取模式。消费者启动后每个实例会启动拉取线程，向 Broker 拉取一批消息，然后提交到消费线程池里执行业务逻辑，处理成功就上报位点，处理失败就会触发重试。这个“拉一批、处理一批、上报位点”的过程有个关键含义：消费并行度是由队列数量和消费线程数共同决定的，但队列数量是天花板。

我打个比方：队列就像是传送带上的工位，每个工位同时只能站一个工人，消费者实例就是工人数量。传送带只有 8 条，你哪怕喊来 100 个工人，同一时刻能上手处理的也只有 8 条传送带上的 8 份工作。在 RocketMQ 这里，一个队列同一时刻只分配到一个消费者实例，一个消费者实例内部才能多个线程并行消费它拥有的队列，所以消费者实例再多的，只要 Topic 队列数不增加，并行度就上不去。这就是“加了 20 台机器但积压纹丝不动”的根本原因。

重试机制也得拎出来说清楚。业务消费抛异常时，RocketMQ 会按延迟级别重试，默认 16 次，间隔从 1 秒逐步拉长到最长 10 分钟以上。重试期间消息不在原队列里，而是进入 ConsumerGroup 对应的重试队列。如果重试全失败，消息会进入死信队列等待人工处理。这套机制保护了消息不丢，但也带来一个副作用：如果业务逻辑处于“一直失败”状态，重试队列会不断吞噬积压，主队列积压数字看着上涨不明显，但消费位点就是不动。所以排查积压问题时，重试次数、消费失败率、死信队列积压三项必须一起看，任何一个异常都可能导致“水龙头正常、地漏却堵了”。

了解完这些底层机制，你就能理解为什么我不主张一上来就重启服务。重启消费者只是让进程恢复，那些已经挂在 Broker 上的消息依然在，消费逻辑没变，重启一百遍也消不完。正确做法是先分清是“水龙头放水变快”还是“地漏排水变慢”，再决定下一步动作。

2. 排查消息堆积的完整思路：从监控到定位瓶颈

2.1 第一步先确认：这是不是真的堆积

线上遇到积压告警，先别急着操作，第一步是确认告警本身是否可靠。所谓“伪堆积”，指的是消费位点其实在正常推进，但由于监控系统数据延迟、消费组名写错、Dashboard 统计口径异常等原因，展示出一个虚高的积压数字。我在实际工作中就见过监控系统每 5 分钟拉一次 Broker 数据，在消费位点尚未刷新到最新时算出来的差值偏大，误报了好几次。

最原始也最可靠的办法，是用命令行工具查看真实位点。找到你部署 RocketMQ 的机器，直接执行：

# 查看某个消费组的消费进度的简单命令，具体参数以你安装的版本为准 mqadmin consumerProgress -g 你的消费组名 -n 你的nameserver地址

输出里会列出每个 Topic 每个队列的最大位点、消费位点，以及两者差值。如果差值是 0 或者在一个很小的区间内波动，说明消费速度是跟得上的，当前告警大概率是误报；如果差值持续变大，这个积压才是真积压。

同时还要确认消费组名字别搞错。RocketMQ 里消费进度是按消费组维度存储的，你明明有一套新的消费者示例在跑，但如果 group 名和监控面板里配的不是同一个，监控自然显示积压，原消费组却已经把消息消费完了。这种低级问题在微服务化改造后特别常见，不同团队各建一套 group 却不更新监控配置。

此外建议一上来就把三个面板拉出来看：实时积压量、积压变化趋势、消费 TPS。积压量是存量，变化趋势是速度，消费 TPS 是能力。只看积压量会误判严重程度，比如积压 10 万条但消费 TPS 有 5000，理论上 20 秒就能追平，真不用慌；反之积压只有 5000 条但消费 TPS 为 0，那才叫真故障。

2.2 判断“能消化”还是“消化不动”：消费能力和耗时是关键

确认积压真实之后，先分清楚一个核心问题：当前消费能力有没有在正常输出？如果消费 TPS 接近正常水平，只是生产峰值更高导致积压，这是“流量压差型”积压，处理起来相对容易；如果消费 TPS 掉到 0 或者极低，这是“消费故障型”积压，必须立刻找消费端哪里出了问题。

判断消费能力，用命令行工具看消费状态，同时观察消费者进程本身运行是否正常。消费状态里可以看到每个客户端实例的消费位点、拉取位点、队列分配情况，以及在线的消费者列表。如果某个实例迟迟没有上报位点，同时队列分配集中在剩余几个实例上，大概率是某个消费者实例已经挂掉或者卡死，触发了队列的重新分配（Rebalance），而新分配的实例还没来得及追上。

接下来要确认消费耗时。一个常见的排查姿势是：在业务代码里给消费逻辑加上埋点日志，打印单条消息的处理耗时。别小看这个动作，很多积压的根源就是消费逻辑里某个环节从平均 50ms 涨到了 800ms，比如下游数据库出现慢查询、Redis 热点键超时、外部 RPC 接口抖动。耗时一长，线程池被占满，新消息拉出来了也排不上队，整体消费 TPS 自然往下掉。

这里我分享一个我自己的排查习惯：先把消费线程池核心数和最大数、当前活跃线程数、队列长度这些指标用 JMX 或可视化工具拉出来看一眼。如果活跃线程数始终等于最大线程数，并且阻塞队列一直有等待任务，说明你的消费线程已经被卡住了，消费耗时变大是果，线程耗尽才是表象。这时再去逐层排查消费逻辑里是什么拖慢了速度。

我遇到过最典型的一次，是业务方在消费逻辑里同步调了下游的“用户等级判定”接口，平时就 30ms 左右，结果那天数据库连接池被打满，接口耗时涨到 5 秒，消费线程很快全部卡住。最后那个系统的积压从 0 涨到 30 万只用了不到半小时。所以排查积压一定要先看消费链路上游的健康度，而不是一上来就调 RocketMQ 参数。

2.3 逐个环节扫描：实例、队列、消费组一个都不漏

确认消费能力有问题之后，就开始做系统性扫描，我习惯按“实例层、队列层、消费组层”三步走。

实例层排查消费者进程的资源占用和健康度：CPU 利用率是否长期跑满、JVM GC 是否频繁、线程池有没有大量拒绝任务、机器网络吞吐有没有异常。这一步可以用 Arthas 或者 jstack 直接抓线程栈，看看消费线程到底阻塞在哪个调用点上。我得提醒一句，很多开发者会忽略机器网络本身，消费组所在机器的带宽打满也会让拉取速度急剧下降，这种积压你光看业务日志完全看不出来。

队列层排查从 Broker 侧看每个 Topic 队列的积压分布。用命令或者 Dashboard 把每个队列的位点差单独列出来，如果积压均匀分布在所有队列，大概率是整体消费能力不够；如果积压集中在一两个队列，就要考虑消息分配是否不均匀，或者有没有某个队列对应的消费者实例出问题。我在实战里见过最离谱的情况是某个消费者实例所在机器磁盘满了，ReBalance 之后它的队列迟迟分配不出去，结果积压全堆在少数队列上。

消费组层排查要看有没有多个消费者实例订阅了同一个消费组，但它们实际处理逻辑却不一样。由于 RocketMQ 中同一个消费组内消息会被负载均衡地分到所有实例上，如果某个实例的代码逻辑有问题，比如它消费失败率高或者处理特别慢，整体消费能力就会被这个“木桶短板”拉低。这类问题尤其容易出现在没有做灰度隔离、新老版本共存一段时间的系统里。

3. 解决消息堆积的四个层次：优化、扩容、兜底、治本

3.1 消费端优化：先把单条消息的消费速度提上去

在扩容和重置位点之前，我强烈建议先做一轮消费端优化，因为同样一条消息，你要是能把它处理得更快，积压自然就消化得快。

第一个可以动的是消费线程数。RocketMQ 的 DefaultMQPushConsumer 默认消费线程数在 20 左右，你可以按实际 CPU 核数和业务逻辑调整。设置方式是在代码里指定：

consumer.setConsumeThreadMin(20); consumer.setConsumeThreadMax(64);

注意线程数不是越大越好，如果业务逻辑里有锁、有数据库行锁竞争、有外部接口阻塞，线程数拉高反而会增加等待和上下文切换，TPS 未必上行。一般建议先从 30 到 50 之间开始调整，观察消费 TPS 和 CPU 使用率，找到一个拐点。

第二个是批量消费。RocketMQ 的 DefaultMQPushConsumer 默认一次拉取的消息数不多，如果你每条消息的处理逻辑都包含网络 IO，可以考虑开启批量消费。设置参数是：

consumer.setConsumeMessageBatchMaxSize(8);

批量消费适合那种可以攒一批再处理的消息类型，比如批量写数据库、批量调批量接口。但如果一条消息本身的处理就涉及事务性操作，批量反而难处理，因为你要自己保证批内消息部分失败时的重试语义。这一步没有万金油，需要按业务形态取舍。

第三个优化点才是重点：消费逻辑本身。把消费逻辑里的外部 RPC 调用从串行改成并行；能走本地缓存的一定要走缓存；能合并到批量查询的不要一条一条查数据库；能异步化的非关键步骤丢到独立线程池里执行，不让它卡消费主流程。很多时候消费耗时的瓶颈根本不在 RocketMQ 上，而是业务代码自己把链路拉长了。你要记住，消息积压只是表象，消费端处理能力才是真正的核心瓶颈。

3.2 扩容的正确姿势：别只盯着机器数量

消费端优化做完还不够，如果积压量很大，比如几十万上百万条，光靠提高单机消费速度可能需要几个小时才能消化，这时候就得考虑扩容。但扩容前先记住一句话：RocketMQ 的消费并行度由队列数量决定，机器数量只影响单台机器上的并发线程数，机器再多也突破不了队列总数的上限。

具体来说，如果你 Topic 的读队列数是 8，当前有 8 台消费者实例，那么每台实例各消费 1 个队列，扩容到 16 台实例也只能让 8 台实例干活，剩下 8 台不会有任何消费行为。所以扩容集群前，先确认 Topic 的队列数量是否足够。查看和修改队列数的办法是利用管理工具或者 Dashboard 更新 Topic 配置，把读队列数从 8 调整到 16、32，甚至更多。

但是有一个极其重要的坑：如果业务里用到了顺序消息，你就不能随意改动队列数。因为顺序消息依赖消息队列选择规则，比如按业务主键 hash 到固定队列，一旦队列数变化，hash 分布就会重新洗牌，原来同一个业务键的消息可能被分配到不同队列，破坏局部顺序。这种情况下，扩容消费者实例并不能提升并行度，因为同一个队列同时只允许一个消费者实例消费，而顺序消息又不能让多个线程并发消费同一个队列。遇到这种场景，更合理的方案是业务层面拆分 Topic，把不同业务域的订单消息拆到不同 Topic，每个 Topic 可以有独立的队列数和消费者实例，这样既保证业务内顺序，又提升了链路整体并行度。

还要注意，扩容消费实例之后，一定要重启或者触发 rebalance，让新实例能真正分到队列。很多团队给容器平台扩容了 Pod 数量，但因为 RocketMQ 客户端实例注册有延迟，新实例没有及时拿到队列分配，旧实例依然在扛压力。通过 consumerStatus 命令可以确认每个实例当前分到的队列数量，看到分配均衡后再下结论。

3.3 紧急兜底：重置位点、死信处理和临时降级

有些积压场景时间紧、任务重，比如大促时积压了几百万条消息但业务要求 10 分钟之内恢复，这时候免不了要做一些“非常规”操作。必须说清楚，这类操作有副作用，一定要在确认业务可接受、并且有人审批的情况下才能执行。

最直接的兜底操作是重置消费位点，也就是把消费组的消费进度直接调到最新位点。这样积压的历史消息就不消费了，相当于放弃了旧消息，只从当前时间点往后消费新消息。具体命令：

# 重置消费位点到一个较早或较新的时间点，需要用时间戳，单位毫秒 mqadmin resetOffsetByTime -g 消费组名 -t Topic名 -s 当前时间戳 -n nameserver地址

这个操作一旦执行，消费进度就跳到指定时间点，历史消息不会进入正常消费流程。所以你一定要问清楚业务方：这些积压消息里有没有必须处理的订单、扣款、补偿类消息？如果丢弃会造成数据不一致，那绝对不能盲目跳过。我见过有的团队为了快速恢复系统，直接 reset 了一大堆交易消息，事后发现大量订单状态没更新，只能靠人工跑批补偿，折腾了整整两天。

死信队列的处理也需要配套进行。积压期间很多消息会经历 16 次重试最终进入死信队列，这些消息如果业务上还有价值，就要写一个专门扫死信队列的程序，把消息捞出来重新投递到正常 Topic 或者直接调用补偿接口。我在后面会专门讲到死信排查，这里想强调的是：死信不是终点，务必清零。

临时降级指的是在消费端代码上做个方案开关，把非核心逻辑临时关闭。比如消费订单消息时，原本需要同步调用积分服务、短信服务、审计服务，在堆积严重时只保留订单状态更新这个核心动作，其余全部降级或异步化。这种做法能迅速把单条消息的处理耗时降下来，相当于给地漏临时加大排水口径，先把水位降下去，等活动峰值过去再恢复完整链路。这个思路在电商大促场景下非常常用，前提是业务方同意非核心逻辑的延时执行，并且有补偿机制。

3.4 治本：容量规划、隔离与链路治理

应急处理完，更要回头思考一个问题：为什么这次会堆积？如果只是流量突然翻倍，那下一次流量再翻倍怎么办？消息堆积治理的治本方案，其实就是容量规划和系统性隔离。

容量规划层面，要对核心 Topic 做生产流量峰值的预估，并按照这个峰值预留消费能力。一般建议消费端的处理能力要比预估峰值高出 30% 到 50%，再加上弹性扩容的能力，保证突发流量增长时能快速补充消费实例。这里我推荐定期对消费端做压测，用压测工具向指定 Topic 灌入平时流量的 2 到 3 倍消息，观察消费 TPS、积压曲线和消费耗时，把每个业务链路的容量基准摸出来。有了基线，后面再谈扩容和告警阈值才有参考意义。

隔离层面，我提倡把一个大的 Topic 按业务重要性拆开。比如订单系统可以拆成“订单核心状态消息 Topic”和“订单营销通知消息 Topic”，前者消费端配备了更高的机器规格和更完善的监控，后者消费端即便堆积也不影响主流程。这种拆分的本质是把资源隔离和治理边界划清楚，避免一条慢业务拖垮所有消费组。你如果做过 RocketMQ 选型对比就会发现，类似这种基于 Topic 进行业务隔离的能力，RocketMQ 相比另一些消息队列更灵活，这也是当时很多人选它的原因之一。

链路治理层面，要把消费端对下游的依赖做分级。能降级的降级，能异步的异步，能做成轮询补偿的就别用同步强依赖。我在一家公司做技术负责人那会儿，团队约定所有消费逻辑不能超过三个依赖调用，每多一个依赖就得写一个独立降级方案。这个约定后来挽救了无数个大促夜，因为真正引起积压的从来不是消息中间件自己，而是消费逻辑里那些脆弱的远程调用。

4. 实战案例复盘和日常预防体系

4.1 一次大促消息堆积处置流程复盘

讲一个很典型的场景。某次大促预热期，订单系统流量瞬间翻了三倍，用 Dashboard 看消息积压数字从个位数一路涨到近 80 万，消费组的消费 TPS 却在持续探底。当时负责的同学第一反应是给消费者集群扩容，但扩容完 15 分钟，积压不但没降反而还在涨。后来排查发现，Topic 队列数只有 8，扩容后的 20 个应用实例有一大半是空闲的，真正干活的只有 8 个实例。

处置过程我尽量还原，大家看这个顺序：先看 Dashboard 确认积压分布，发现每个队列积压都很高，排除单个队列异常；再查消费者实例状态，发现部分实例 CPU 使用率长时间超过 80%，消费线程大量阻塞；随后抓线程栈，定位到消费逻辑中调用的库存服务接口耗时飙升，单次调用从 50ms 涨到了 2 秒以上。这时候做两件事：一是在配置中心打开降级开关，让消费端跳过几个非核心的校验逻辑和营销同步；二是把 Topic 队列数提升到 32，然后给消费者集群扩容，触发一次平滑 rebalance。

降级开关一打开，单条消息耗时就降下来了，消费 TPS 从 200 涨到接近 1500。队列扩容后，32 个消费者实例各占一个队列，整体并行能力也上来了。差不多 40 分钟以后，80 万积压被彻底消化完，系统恢复平稳。这次复盘让我拿到的教训很深刻：扩容前不看队列数，等于白花钱；消费逻辑里的非核心依赖，在流量尖峰时要能一键摘除。

4.2 日常可落地的监控告警和预防措施

处理完了一次事故，接下来要做的是不让同样的问题在下次发生。消息堆积的监控体系，我建议至少包含三个维度：积压量、消费能力、异常率。

RocketMQ 自身提供的 Dashboard 可以看消费组的 diff 数据，但更推荐把指标接入 Prometheus，搭配 rocketmq-exporter 采集 Broker 端的消息积压、生产速率、消费速率等指标。rocketmq-exporter 的安装其实不复杂，准备好 nameserver 地址和 exporter 的配置文件，部署成一个单独服务，然后在 Prometheus 里添加抓取任务即可。这个过程官网文档挺清楚，照着做基本没坑，唯一要注意的是 exporter 版本和 RocketMQ 服务端版本最好保持一个大版本内一致，否则偶尔会出现指标抓取不到的兼容问题。

监控面板搭好之后，告警规则要定得有层次。最核心的几条我通常这样配：消费组积压量超过 5000 条且持续 5 分钟告警一次；消费组消费 TPS 掉到 0 时秒级告警；消费失败率或重试次数在短时间内翻倍时告警。积压量这种指标不要设置太低的阈值，否则系统一抖动就告警，告警轰炸反而让人麻木；消费 TPS 为 0 这种指标则必须配置秒级或分钟级告警，因为这意味着消费链路完全瘫痪。

除了监控告警，日常也要做定期的存量巡检。我建议每周挑一个业务低峰时段，自动跑一遍主题消费组位点巡检脚本，把积压量超过阈值的消费组列表拉出来给研发同学确认原因。这么做的好处是很多小问题在变成事故前就被发现了，比如某个消费组由于代码发布失败一直没启动，如果没有巡检，它可能会在你大促前几天才被注意到，那种被动局面大家都不想经历。

4.3 消息堆积问题速查表

最后整理一个速查表，大家可以把这张表贴在团队文档里，线上出问题时照着对一遍，能省不少排查时间。

这张表不可能覆盖所有场景，但覆盖了我在实际运维中遇到的大多数问题。大家在做技术方案、写复盘文档时，也可以把类似表格放进去，让新人接到告警时知道从哪里入手。

最后再分享一个经验。消息堆积处理得多了之后你会发现，真正需要你直接用“重置位点跳过消息”来救场的场景很少，绝大多数情况下是消费逻辑本身有退化点，或者容量预估远远不足。所以与其练一手骚操作，不如老老实实把消费链路做可靠，把监控做灵敏，把预案做细。RocketMQ 消息堆积这道面试题，能回答到“从原理分析到应急处理、再到预防体系”这个颗粒度，面试官看到的就不只是你会用工具，而是你在真实系统里扛得住事。