5. 消息积压怎么发现和定位
消息积压是 MQ 测试和线上问题排查中非常常见的现象。所谓消息积压，就是消息生产速度大于消费速度，队列里的消息越来越多，导致业务处理延迟。例如支付成功后订单迟迟不更新、短信很久才收到、库存状态延迟变化、报表数据长时间不同步，这些都可能和消息积压有关。
面试中问“消息积压怎么发现和定位”，测试工程师不能只说“看 MQ 控制台”。更完整的回答应该包括：从业务现象发现延迟，通过 MQ 控制台或监控查看堆积量，通过生产者和消费者日志确认消息发送与消费情况，再分析消费者是否异常、消费能力是否不足、下游依赖是否慢、是否有某条脏数据阻塞、是否扩容消费者或做补偿。测试要能把技术现象和业务结果联系起来。
一、消息积压会造成什么业务影响
消息积压的核心影响是异步结果延迟。
常见表现：
- 支付成功后订单仍显示待支付；
- 下单成功后库存迟迟不扣减；
- 退款申请后状态长时间不更新；
- 用户很久才收到短信或站内信；
- 报表数据延迟；
- 搜索结果没有同步新数据；
- 优惠券发放延迟；
- 自动化用例等待异步结果超时。
如果测试只验证接口立即返回，会漏掉这些问题。
二、消息积压怎么发现
1. 从业务现象发现
最直观的是业务结果延迟。例如支付回调成功，但订单 5 分钟后仍未更新。
测试要记录操作时间和业务 ID，例如订单号、用户 ID、消息 ID。
2. 从 MQ 控制台发现
很多 MQ 平台可以查看：
- 队列堆积数量；
- 消费者状态；
- 消费速率；
- 生产速率；
- 消费延迟；
- 死信队列数量。
测试环境如果有权限，可以直接查看。
3. 从监控告警发现
成熟系统会对队列积压设置告警，比如堆积超过阈值或消费延迟超过阈值。
4. 从日志发现
生产者日志显示消息正常发送，但消费者日志没有消费记录，或者消费很慢。
三、消息积压定位思路
可以按下面链路排查：
是否生产过快 -> 消费者是否在线 -> 消费是否报错 -> 下游依赖是否慢 -> 是否单条消息阻塞 -> 消费能力是否不足
四、消费者是否正常
第一步看消费者是否在线、是否有异常日志。
常见问题：
- 消费者服务没启动；
- 消费者进程挂了；
- 消费者连接 MQ 失败；
- 消费者订阅 topic 或 queue 错误；
- 消费者版本部署错误；
- 消费者权限配置错误。
如果消费者不在线，消息自然会积压。
五、消费是否报错
消费者在线但一直消费失败，也会造成积压。
常见原因：
- 消息格式不符合预期；
- 数据库异常；
- 业务数据不存在；
- 接口调用失败；
- 字段为空导致异常；
- 幂等校验异常；
- 下游服务超时。
测试要查看消费者日志中是否有 ERROR、Exception、messageId、订单号等关键字。
六、下游依赖是否慢
消费者处理消息时，可能需要写数据库、调用第三方接口、更新缓存、调用其他服务。如果这些依赖慢，消费速度就会下降。
比如：
- 消费支付消息时调用订单服务慢；
- 消费通知消息时短信服务慢；
- 消费库存消息时数据库锁等待；
- 消费报表消息时大 SQL 慢。
这类问题表现为消费者在线，但消费速率很低。
七、是否生产速度过快
活动、秒杀、批量导入、压测时，生产消息速度可能突然升高。
如果消费者数量和处理能力不足，消息会积压。
测试要关注：
- 活动高峰时消息量；
- 消费者实例数；
- 单条消息处理耗时；
- 队列堆积增长趋势；
- 是否支持扩容消费者。
八、是否单条脏消息阻塞
有些队列或消费模式下，一条异常消息反复失败，会影响后续消息消费。
例如某条订单消息字段缺失，消费者每次处理都报错，重试后仍失败。
测试要关注：
- 是否有死信队列；
- 是否跳过异常消息；
- 是否记录失败原因；
- 是否有人工补偿入口。
九、消息积压测试场景
场景 1：消费者停止
- 停止消费者服务；
- 触发大量业务消息；
- 查看队列积压；
- 恢复消费者；
- 验证消息是否继续消费；
- 验证最终业务结果是否正确。
场景 2：消费者处理慢
模拟下游数据库或接口慢，观察消费延迟是否增加，系统是否告警。
场景 3：异常消息
构造字段异常或业务数据缺失的消息，验证是否重试、进入死信队列、记录日志。
场景 4：高峰消息
压测或批量操作，观察生产速率、消费速率和堆积变化。
十、Bug 怎么描述
一个好的消息积压 Bug 要包含：
操作时间：10:30
业务 ID：订单 NO10001
现象：支付成功后 10 分钟订单仍为待支付
MQ 观察：payment-success topic 堆积从 0 增长到 5000
消费者日志：OrderConsumer 连接数据库超时
影响：订单状态更新延迟，用户无法查看支付结果
这样比“订单状态没更新”清楚很多。
十一、面试回答模板
如果面试官问“消息积压怎么发现和定位”，可以这样回答：
消息积压可以从业务现象、MQ 控制台、监控告警和日志中发现。比如支付成功后订单状态长时间不更新，就要怀疑支付消息是否积压。定位时我会先看消息是否正常生产，再看消费者是否在线、是否有消费日志、是否报错；如果消费者在线但消费慢，就看下游数据库、接口、缓存等依赖是否变慢；如果有异常消息反复失败，要看是否进入死信队列或有补偿机制。测试时还会模拟消费者停止、消费失败、高峰消息和恢复消费，验证系统最终一致性。
十二、常见追问
追问：消息积压一定是 MQ 问题吗？
不一定。可能是消费者挂了、消费逻辑报错、下游数据库慢、第三方接口慢或生产速度太快。
追问：积压恢复后要测什么？
要验证积压消息是否全部消费，业务状态是否最终正确，是否重复处理，是否有数据丢失。
追问：怎么防止消息积压？
扩容消费者、优化消费逻辑、限流、批量消费、异步处理、死信队列、监控告警。
十三、练习清单
- 准备支付消息积压案例；
- 准备短信消息积压案例；
- 查看队列堆积量；
- 查看消费者日志；
- 分析消费失败原因；
- 模拟消费者停止；
- 恢复消费者验证最终结果；
- 验证重复消费幂等；
- 理解死信队列；
- 准备消息积压面试回答。
消息积压测试的关键是业务结果延迟和最终一致性。测试要能从用户现象追到消息队列，再追到消费者和下游依赖。
配套刷题：