项目中消息队列有哪些作用，QPS 情况如何？

核心回答

下面以“订单创建后异步发送通知”为参考项目，说明消息队列的作用和 QPS 的回答口径。

业务上，MySQL 保存订单，MQ 传递订单事件，独立消费者处理通知。 下单接口完成必要校验和订单事务后返回订单创建结果，不同步等待通知渠道；通知成功与否通过后续状态跟踪。MQ 在这里主要承担三件事：

• 异步处理：把不影响本次订单创建结果的通知移出主链路，减少等待下游的时间。
• 解耦：订单服务发布有明确契约的事件，由通知服务订阅；新增其他订阅方时，不必把它们都接进下单接口的同步调用链。
• 缓冲短时峰值：消费者按通知渠道和数据库能承受的速率处理积压，同时保留失败重试、告警和补偿入口。

QPS 要分口径回答：入口接口每秒多少请求、每秒成功发布多少消息、每秒成功完成多少业务处理，并说明平均值还是峰值、观察窗口、部署规模、消息大小及可靠性配置。一条请求可能产生多条消息，重试也可能产生多次投递，这几个速率不能直接当成同一个数字。

进一步解释

如何把“订单已提交”可靠地通知出去？

参考设计可以在同一个 MySQL 事务内写订单和 Outbox 事件记录；事务提交后，由投递程序读取事件并发送到 MQ，确认发送结果后推进投递状态。这样，进程即使在订单提交后、发布消息前退出，仍有持久记录可继续投递。

发送超时并不一定表示消息没有到达 Broker，因此重试可能带来重复。消费者应以稳定的业务事件标识处理幂等，记录业务处理状态，成功后再确认消费或推进消费进度。需要外部通知渠道时，还应使用其幂等请求能力或结果查询，处理“通知已发出、响应却丢失”的情况。

发送确认与业务完成是不同阶段。例如 RabbitMQ 的 publisher confirm 表示 Broker 已按相应语义接管消息，并不表示消费者已经发完通知；consumer acknowledgement 则由消费者按实际处理结果发出。不同 MQ 的存储、确认与重试机制应分别说明。

MQ 削峰，为什么还会出现积压？

削峰只是用时间换瞬时处理能力，不会凭空增加消费者或下游容量。短时流入高于消费能力，可以在允许的延迟范围内排队；如果长期流入大于有效消费能力，积压就会持续增长。

因此，这个参考项目还需要限制在途任务、观察最老消息等待时间，并设置积压告警。渠道限速时，应控制消费并发；不可恢复的消息应进入可追踪的失败处理流程。队列容量、消息保留期和通知时效也要匹配，不能把消息放进 MQ 就认为已经解决了超载。

QPS 的数字具体从哪里来？

接口速率可从网关或服务监控获得；消息发布、投递、确认、重试及积压趋势，应结合 Broker 和应用指标观察。还要把“拉到消息”“确认了消息”和“业务真正完成”分开，批量处理也要统一按消息条数或业务动作统计。

报实际峰值时，说明它持续了多长时间、成功率和延迟怎样、当时有多少实例。报压测能力时，说明消息体大小、消费者处理逻辑、持久化与副本配置，以及是否接入真实下游。只测 Broker 空消息写入，不能代表订单通知整条链路的稳定吞吐。

如果尚未测得吞吐上限，可以先说明目前验证的功能链路和已有监控口径，再给出准备怎样测量，以及预期会受哪些瓶颈限制。

常见追问

用了 MQ，接口返回成功代表什么？

在上述设计中，代表订单事务已经成功，可靠事件已记录；不代表通知已经发送成功。如果核心业务也改成排队处理，接口应表达“已受理”，并提供结果查询或回调，不能把入队成功当成最终业务成功。

为什么不用线程池直接异步执行？

进程内线程池更简单，适合允许丢失或能从别处恢复的短任务。跨服务解耦、进程重启后继续处理、持久积压和独立扩缩容等要求，则更适合评估 MQ。但 MQ 同样增加了依赖、部署和故障处理成本，低流量简单链路未必需要它。

下游挂了，能一直重试吗？

应区分临时故障、参数错误和已经失去时效的消息。重试需要退避、次数或时间预算，并配合失败状态、死信或补偿流程。持续高频重试既可能压垮恢复中的下游，也可能挤占正常消息的处理能力。

参考资料