是个少女早上 11 点 32 分，钉钉群突然被告警刷屏——订单支付成功消息的 MQ 队列深度从不到 1 万条，十分钟内飙到了 30 万。我扔下刚打开的早餐盒去翻监控，当时以为只是某个消费者实例挂掉了，心里还想着“重启一下就能解决”。结果短短一个小时，积压量冲到了 150 万，整个交易链路的支付回调、积分发放、消息通知全部被拖慢，连带着数据库连接池也开始报警。
这篇文章就记录这次生产环境 MQ 队列积压 150W 的完整排查过程与解决方案。里面没有玄学，只有一步步的监控比对、日志分析、线程栈定位和最终根因确认。如果你也负责生产环境的中间件运维，或者正在被“消费者明明活着、消息就是消费不下去”这类问题折磨，这篇文章应该能给你一些可落地的排查思路。
1. 故障初现：监控面板上的数据让我后背发凉
1.1 告警是怎么报出来的
我们的监控体系用的是 Prometheus + Alertmanager，RabbitMQ 的 messages 指标做了自定义采集，默认阈值是队列深度超过 5 万持续 5 分钟就触发 P1 告警。那天 11:32 的告警消息弹出来的时候，我第一反应是“是不是又有人手动往队列里塞测试数据了”，因为上一个版本刚上线了一个批量重发功能，专门用来处理历史脏消息。
但打开 Grafana 面板我就知道情况不对。订单支付成功队列的 messages_ready（等待被消费的消息数）曲线几乎是垂直拉升的，从 9,000 多一路冲到了 30 万，而且完全没有回头的意思。旁边另一个核心业务队列虽然也在涨，但斜率明显低很多。也就是说，这不是整体流量突增导致的普遍性排队，而是某一个消费链路出了问题。
1.2 我最初的三个猜测与快速验证
遇到队列积压，我脑子里冒出来的无非就三种常见情况：
- 消费者实例批量宕机，或者触发了优雅停机逻辑但没有正常消费完毕；
- 消费逻辑里某段代码出现异常，导致消息一直 ack 失败，陷入无限重试；
- 消息体解析出问题或下游依赖的某个接口超时，消费线程被卡死。
我先去看了消费者服务的实例数量和健康检查状态，Spring Boot 的 Actuator 显示 8 个实例全部 UP，JVM 内存和 CPU 也都在正常范围。这排除了第一种情况。接着我又去翻消费者日志，结果刚打开就发现了一大片 Retrying to consume message, attempt 3/5 之类的日志，以及大量 Connection timed out 异常。
到这里基本可以锁定问题不在 RabbitMQ 本身，而是消费者处理消息的时候，某个外部依赖变慢了。但到底是什么依赖、为什么变慢，还得继续往下挖。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 顺着消费链路逐层定位：从队列到线程再到下游依赖
2.1 第一眼：消息是堆积在待消费队列还是未确认区
排查 RabbitMQ 队列积压，第一步一定要分清 messages_ready 和 messages_unacknowledged 的区别。ready 表示消息还在队列里等着被投递给消费者；unacknowledged 表示消息已经投递出去了，但消费者还没回复 ack。这两个数字代表完全不同的故障类型。
我执行了 RabbitMQ 管理命令：
bash复制rabbitmqctl list_queues name messages messages_ready messages_unacknowledged consumers
输出结果大概是这样：
text复制order.payment.success 1502381 1000083 502298 16
这个数据非常关键。ready 有 100 万，说明积压的大部分消息根本没被消费到；但 unacknowledged 也有 50 万，而且 consumers 显示 16 个（8 个实例 × 2 个并发消费者），说明有大量消息已经投递给消费者了，但消费者的处理线程全部卡住了，根本没有回 ack。
这个现象基本推翻了“消费者宕机”的假设，问题出在消费处理逻辑的瓶颈上。
2.2 线索转向：日志里的高频重试
我打开消费者服务的日志文件，用关键字做了聚合统计：
bash复制grep -c "Retrying to consume message" app.log
grep -c "Read timed out" app.log
数量都在几十万级别。顺着日志往上看具体的异常堆栈，发现报错集中在调用用户中心的一个 HTTP 接口上，异常是 Read timed out。我们消费者代码里配置了 RestTemplate 的连接超时和读取超时分别是 2 秒和 5 秒，按理说超时之后会抛异常，消息会被 nack 并进入重试，不应该出现 50 万条消息全部卡在 unacknowledged。
这里就要解释一下 RabbitMQ 的 prefetch 机制了。我们在消费者配置里设置了 prefetch = 20，意思是每个消费者同时预取 20 条消息到本地缓存，处理完一条 ack 一条才会继续从队列拉取。如果下游接口超时是偶发的，5 秒后异常抛出，message 会回到队列，后续还能继续消费。但如果超时的接口调用占据了消费线程并且长时间不返回——比如连接池被打满、线程池队列堆满——那消费线程就会一直阻塞在等待响应上，既不会 ack 也不会 nack，消息就全部滞留在了 unacknowledged 区。
2.3 决定性的 jstack 输出
为了确认消费线程的阻塞状态，我用 jstack 抓了消费者服务的线程栈：
bash复制jstack 28471 > jstack_$(date +%H%M%S).log
在输出里搜关键字 consumeMessage，看到了非常典型的阻塞场景：
text复制"pool-12-thread-3" #17 prio=5 os_prio=0 tid=0x00007f4a840f6800 nid=0x7f3a waiting on condition [0x00007f4a5f5f3000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:1338)
...
这个输出其实还看不出根因，只是确认消费者线程被阻塞在等待条件上。接着我又搜了 http-nio 相关的线程栈，发现大量线程处于：
text复制java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.CompletableFuture.await...
这就对上了。消费线程在调用下游 HTTP 接口时，因为底层连接池没有可用连接，进入等待状态。下游接口不是偶尔超时，而是完全拖死，导致连接池被占满，消费线程只能排队等待。
3. 真正的坑：一个索引缺失引发的雪崩式连锁反应
3.1 慢 SQL 浮出水面
到这里，排查方向已经很明确了——问题在下游用户中心的接口。我拉上用户中心的同事查数据库慢查询日志，果然发现了一条执行时间高达 3.5 秒的 SQL 反复出现：
sql复制SELECT balance, points, status
FROM user_points_account
WHERE user_id = ? AND biz_date = ?
ORDER BY id DESC
LIMIT 1;
当时执行 EXPLAIN 看了一下执行计划：
sql复制EXPLAIN SELECT balance, points, status
FROM user_points_account
WHERE user_id = 123456 AND biz_date = '2025-06-18'
ORDER BY id DESC
LIMIT 1;
结果让人血压上升：
text复制type: ALL
possible_keys: NULL
key: NULL
rows: 1856340
Extra: Using where; Using filesort
全表扫描，连索引都没走到，还在 Using filesort。这个表里已经积累了 180 多万行数据，user_id 和 biz_date 上竟然没有任何联合索引。平时查询量小的时候还能靠缓存和运气扛过去，一旦消息消费速度加快、高频触发这条 SQL，数据库就直接被打穿。
3.2 为什么平时不炸、偏偏这次炸
很多朋友可能会问：这条 SQL 如果一直这么慢，为什么之前没出事？
说实话，之前确实没出事，但原因是“刚好在临界值以内”。平时队列流量稳定，消费者每秒钟处理的消息量不大，这条 SQL 大概执行几百上千次，单次 100 多毫秒虽然慢，但线程池还扛得住。加上用户中心的接口有本地缓存，很多重复 user_id 的请求直接命中缓存。
那天的情况完全不同。当时业务方在上线一个新的大促活动，流量比平时高了一个量级。消息的 producer 从单线程批量发送改成了多线程并发发送，消费者收到的消息量立刻暴涨。查询量翻倍之后，原本卡在临界值的 MySQL 开始出现行锁竞争和 CPU 飙升，慢 SQL 从 100 多毫秒恶化到 3 秒以上。
最致命的是，我们消费者代码里调用户中心接口拿积分余额时，没有做超时熔断，只是被动的等 RestTemplate 的 5 秒读取超时。一旦接口响应变慢，消费线程就全部阻塞在等待上，消息的 unack 堆积引发了 RabbitMQ 的流量控制机制，反过来又影响了生产者发送，整个链路进入恶性循环。
3.3 雪崩是怎么一步步演进的
我来画一下当时的时间线，这个演进过程比任何文档都生动：
- 11:20 大促流量上来，生产者发送速率从 300 msg/s 涨到 2,000 msg/s；
- 11:25 用户中心接口耗时从 50ms 缓慢爬升到 500ms，数据库 CPU 开始上升；
- 11:30 慢 SQL 累计到一定数量，MySQL 连接数接近上限，接口响应飙到 3s 以上；
- 11:32 消费者线程大面积阻塞在 HTTP 调用上，消费速率骤降，队列 ready 快速堆积；
- 11:35 RabbitMQ 检测到 consumer 处理不过来，开始对连接启用 TCP backpressure，生产者发送也变慢；
- 11:40 消息积压突破 50 万，数据库连接池被打满，其他依赖同一数据库的业务也开始受影响。
所谓“150W 积压”，本质上不是 MQ 的问题，而是下游数据库索引缺失 + 无熔断保护 + 流量突增三者叠加后的必然结果。MQ 只是忠实地把问题暴露了出来。
4. 从止血到根治：三阶段处理积压消息
4.1 阶段一：紧急止血，用扩容和调参把消费速度拉起来
定位到根因之后，第一件事不是急着改代码，而是先把积压的量降下来，恢复业务可用性。我们分了三个操作同时进行。
第一步，快速调整消费者线程数。原 Spring Boot 配置里 concurrency 是 2（每个实例 2 个消费线程），8 个实例总共 16 个消费者。我先把它调到了 concurrency=8，并通过动态配置中心热更新，不需要重启服务。
yaml复制spring:
rabbitmq:
listener:
simple:
concurrency: 8
max-concurrency: 16
prefetch: 50
acknowledge-mode: auto
第二步，把 prefetch 从 20 调高到 50。这样每个消费者一次可以多拿一些消息到本地，减少客户端和服务端之间频繁拉取的网络开销。要注意的是，prefetch 调高之后 unacknowledged 也会增多，一旦消费者处理异常，消息丢失的风险窗口会变大。但要解决的是积压，这是必须做的权衡。
第三步，临时扩容消费者实例。我们在 K8s 里把用户服务相关的消费副本从 8 个扩容到 20 个，同时给消费者服务所在的节点加了资源配额。这一步尽快做，不需要等代码发布。
这样一波操作下来，消费速率从 80 msg/s 提升到了 1,200 msg/s，虽然还是赶不上生产速率 2,000 msg/s，但至少积压的增长速度被遏制住了。
提示：紧急扩容前先确认下游数据库的承受能力。如果下游数据库已经打满，盲目扩容消费者只会让数据库更快崩溃。优先从根因侧止血，再扩容。
4.2 阶段二：根因修复，索引与代码双管齐下
止血之后，我们同步推进根因修复。
首先和 DBA 确认，在 user_points_account 表上对 user_id 和 biz_date 建联合索引：
sql复制ALTER TABLE user_points_account
ADD INDEX idx_user_biz_date (user_id, biz_date);
这条 DDL 执行了大概 30 秒，因为表里 180 万行数据，在低峰期执行并没有阻塞线上。索引建好之后再次执行 EXPLAIN：
text复制type: ref
possible_keys: idx_user_biz_date
key: idx_user_biz_date
rows: 1
Extra: NULL
查询直接从全表扫描变成了走索引查一行，耗时从 3.5 秒降到了不到 10 毫秒。接口响应恢复正常，消费者线程也不再有大量阻塞。
除了建索引，我们还做了一件很重要的事：在用户中心的接口调用侧加了熔断降级。之前的是“死等 5 秒超时”，现在是当接口错误率超过阈值或者耗时超过 1 秒时，直接返回一个默认的积分余额，同时把这次请求记入降级日志，后续再通过补偿任务把实际数据补齐。
java复制@CircuitBreaker(name = "userCenterService", fallbackMethod = "getPointsFallback")
public PointsInfo getPoints(String userId) {
// 调用用户中心接口
}
public PointsInfo getPointsFallback(String userId, Throwable t) {
log.warn("调用用户中心失败，走降级，userId={}, error={}", userId, t.getMessage());
return PointsInfo.defaultPoints();
}
这个改造非常关键。它保证了即使将来用户中心再次抖动，消费者线程也不会被卡死，最多是部分消息消费到的是降级数据，后续通过对账任务修正。
4.3 阶段三：积压追平与数据一致性核对
根因修复后，消费速率上来了，但这时候积压已经维持在 110 万左右。要让积压继续下降，光靠正常消费还不够，因为生产流量还在持续进来。
我们采取的办法是“窗口期追数”。当天夜里业务低峰期，我们把消费者服务的并发临时调到了 32（带 max-concurrency 64），并联动 DBA 确认数据库负载正常。在凌晨 2 点到 4 点之间，把积压的 110 万消息全部消费完毕。
这里有一个重要的细节：积压消息中有一部分是活动开始初期，因为降级或异常已经处理过一遍的消息，如果直接消费会重复发放积分。好在我们从一开始就设计了消费幂等。消息体里带了一个全局唯一的 event_id，消费前先去 Redis 查 SETNX event_id，如果已经存在就直接 ack 跳过。
java复制Boolean first = redisTemplate.opsForValue().setIfAbsent("msg:event:" + eventId, "1", Duration.ofHours(24));
if (first == null || !first) {
// 已消费过，直接 ack
return MessageAck.ACK;
}
最终在凌晨 3 点 50 分左右，队列深度归零，整个链路恢复正常。第二天我们根据日志和数据比对，把降级期间被跳过或写了默认值的积分数据做了一轮补偿，确保账实一致。
5. 事后复盘：这次故障暴露的四个管理死角
5.1 监控和告警：我们当时“看得见”什么
这次故障之后我最大的感触是：有监控不代表看得见。我们当时只对 messages_ready 做了告警，但这个指标反映的是结果，不是原因。等队列深度大到触发告警的时候，整条链路已经“病入膏肓”了。
现在我们的 MQ 监控增加了三个维度：
- 消费速率与生产速率的差值趋势，制作成速率差额曲线；
- 消费者线程阻塞耗时分布，采集
manage接口里的线程池活跃数； - 下游依赖接口 P99 耗时，并且在 P99 超过 800ms 时提前告警。
告警阈值也不再是固定的 5 万，而是结合容量基线的动态阈值。比如正常情况下队列深度在 1 万左右，那告警线设置为 3 万并持续 3 分钟，比之前 5 万更早发现异常。
5.2 容量规划与压测：为什么 150W 这个数字不是偶然
复盘时我们把监控数据往回拉，发现这条链路从 11:20 就开始异常了，但直到 11:32 才触发告警——那 12 分钟里积压从 2 万涨到了 30 万，而从 30 万涨到 150 万只需要不到 40 分钟。如果告警阈值再保守一点，我们完全可以在积压 10 万的时候介入，处理的难度和影响面会小得多。
更根本的问题是，我们从没针对这条核心链路做过完整的全链路压测。大促前只压测了用户中心和订单服务单独的 TPS，没有验证过“订单服务 → MQ → 消费服务 → 用户中心 → MySQL”这条完整链路在流量翻倍时的表现。结果数据库索引缺失的问题被流量放大到雪崩，压测要是早做，这条慢 SQL 一定会被查出来。
现在我们的规矩很简单：任何核心交易链路过活动大促之前，必须做全链路压测，并且要用线上的实时数据量做基线，不能只拿测试库里几千条数据糊弄。
5.3 落地改进：我在这次故障后坚持做的几件事
针对这次排查学到的教训，我在团队里推动了几个改进项，很多已经成为日常开发规范：
- 消费者代码必须要有超时控制和熔断降级。RestTemplate/OpenFeign 调用外部服务的超时时间不能靠默认值，必须显式配置，并且对下游服务的错误率做熔断保护。
- 消费幂等是硬要求。不管你用的是 RabbitMQ、Kafka 还是 RocketMQ，都建议在消息体里带上唯一的业务键，消费前做幂等判断。积压恢复、消息重投这些场景下，幂等是保命的底线。
- 数据库索引治理要日常化。慢查询日志要定期扫描，对执行计划中
type=ALL的 SQL 建立工作项。这次如果早一点发现这条慢 SQL，150W 的积压根本不会发生。 - 队列积压应急预案要写进手册。明确了什么条件下扩容消费者、什么条件下调 prefetch、什么条件下允许人工丢弃非关键消息，并且把操作步骤在测试环境演练过一遍。
这些工作不复杂，但每一条都在关键时刻救过我们。
最后再分享一个我自己养成的排查习惯：拿到“MQ 积压”这个结论后，不要只盯着 MQ 看。先看消费者的线程状态，再看日志里的异常率，然后顺着调用链往下游找。大部分积压问题的根子根本不在 MQ，而在某个接口变慢、某条 SQL 没走索引、某个连接池被打满。MQ 只是替所有下游背了锅。以后你再遇到队列告警，记住这句话，排查效率会高很多。