事务消息（Transactional Message）是一种高级的消息队列机制，它主要用于解决分布式系统中的数据最终一致性问题。
在微服务和分布式架构中，当一个核心业务操作（例如用户下单）需要同时触发多个下游系统（例如库存扣减、积分增加、邮件通知）的变更时，事务消息能够确保核心操作和消息发送是原子性的，从而保证整体业务数据的一致性。
核心问题：分布式系统中的"两难"
在分布式系统中，你不能在一个数据库事务中同时包含本地数据库操作和消息发送操作，因为它们是两个独立的服务。这就会产生一个问题：
| 场景 | 风险 |
|---|---|
| 先发消息，后执行本地事务 | 如果消息发出后，本地事务失败并回滚，下游系统已经开始处理消息，导致数据不一致。 |
| 先执行本地事务，后发消息 | 如果本地事务成功提交后，发送消息失败（例如网络故障），下游系统永远收不到通知，导致数据不一致。 |
事务消息机制就是为了确保 "本地事务成功，消息必达" 或 "本地事务失败，消息必不达"。
事务消息的工作原理（以 RocketMQ 为例）
事务消息通常采用一个两阶段提交（Two-Phase Commit）的变种来保障一致性：
阶段一：半事务消息 (Half Message / Prepare)
- 生产者发送半消息： 生产者（例如订单系统）将消息发送给消息队列服务器（Broker），但将消息标记为 "半事务消息" 或 "预提交" 状态。
- 消息不可见： Broker 接收并持久化消息，但不将其投递给消费者。
阶段二：执行本地事务
- 执行本地事务： 生产者开始执行自己的本地数据库事务。
- 提交或回滚判断：
- 如果本地事务成功提交 (Commit)，生产者向 Broker 发送 Commit 指令。
- 如果本地事务失败回滚 (Rollback)，生产者向 Broker 发送 Rollback 指令。
阶段三：消息投递与回查
- Broker 处理：
- 如果收到 Commit 指令，Broker 将半消息标记为 "可投递"，此时下游消费者才能收到并处理消息。
- 如果收到 Rollback 指令，Broker 将丢弃该半消息。
- 事务回查 (Transaction Check)： 如果生产者在执行本地事务后宕机 ，或者因网络问题未及时发送 Commit/Rollback 指令，Broker 会启动回查机制。Broker 会主动向生产者发起请求，查询该半消息对应的本地事务的真实状态（是已提交、已回滚还是未知），然后根据查询结果来决定是投递还是丢弃消息。
整体流程如下所示：
总结
事务消息是解决数据最终一致性的柔性事务方案中最常用且优雅的方式之一。它牺牲了严格的实时性（最终一致性）来换取更高的系统性能、可用性和吞吐量，特别适用于电商、金融等对数据一致性要求高的场景。