延迟消息和事务消息适合什么场景

先说结论

• 延迟消息更适合“现在先不处理，过一段时间再处理”的场景
• 事务消息更适合“本地事务和消息投递要尽量绑在一起”的场景
• 两者都不是为了炫技，真正用的时候要先看业务是否真的需要这层语义

一、延迟消息到底适合什么

更常见的场景有：

• 订单超时关闭
• 支付超时检查
• 优惠券到期提醒
• 补偿任务延后触发

这类场景的共同点通常是：

• 不是立刻消费
• 需要“到点再执行”
• 容忍一定延迟误差

如果你的需求只是普通异步解耦，其实不一定需要延迟消息。

二、事务消息到底适合什么

事务消息更适合这种场景：

• 本地数据库事务成功了，才希望下游收到消息
• 本地事务失败了，就不想把消息发出去

典型例子包括：

• 订单创建成功后通知库存或积分
• 支付成功后通知履约
• 本地状态变更后驱动下游异步流程

它的核心价值是尽量缩小：

• 数据库改成功了，但消息没出去
• 消息出去了，但本地事务失败了

这两类不一致窗口。

三、两者最容易被误用的地方

1. 延迟消息被当成定时调度系统

它可以做轻量延迟触发，但如果你要做复杂编排、大量定时任务和可视化调度，专门的调度系统通常更合适。

2. 事务消息被当成“分布式事务万能药”

它解决的是“本地事务和消息投递”的协调问题，不是替你把整个跨服务事务都强一致化。

四、什么时候不一定要上它们

如果你的场景是：

• 失败后可重扫补偿
• 本地 outbox 已经足够
• 定时逻辑很简单

那很多时候并不一定非要用事务消息或延迟消息。

技术上能做，不代表业务上最划算。

五、最容易踩的坑

1. 事务消息回查逻辑没做好

一旦 broker 回查时应用不能明确回答本地事务状态，链路会很难收。

2. 延迟消息精度想得太理想

它更适合“接近某个时间点”，不是毫秒级精准调度工具。

3. 把复杂业务补偿全压给 MQ

最终一致性仍然要靠清晰的状态机、重试和补偿逻辑一起兜底。

总结

RocketMQ 的延迟消息更偏“延后触发”，事务消息更偏“本地事务与消息联动”。它们都有明确价值，但前提是业务真的需要这层语义。先分清问题，再决定要不要上高级消息能力，通常会更稳。