事务消息主要原理：解决售货柜下单、扣库存、支付数据一致性

一、分布式事务的难题

痛点一：售货柜业务涉及三个服务还有对应的数据库。一旦其中一个环节失败，程序就会出现“扣了库存却没有出货”或“出货却没有扣库存”的异常状态。

痛点二：网络抖动、服务宕机或数据库超时都可能导致操作结果不确定。按理说，传统方案如 2PC 必须持久化锁定资源，极大影响性能；TCC 需要编写三套业务逻辑，开发成本高。

场景示例：

• 使用者扫码开门 → 拿走商品 → 关门扣款
• 后台流程这方面，
• 订单服务的观点是，创建订单记录
• 说到库存服务，扣减可乐库存
• 出货服务这方面。向设备下发出货指令

传统方案的困境

二、RocketMQ 事务消息原理

主要思路这方面。两阶段提交 + 回查机制

• 第一阶段： 生产者发送 “Half 消息”到 Broker，Broker 存储但对使用者不可见。其实，
• 第二阶段： 生产者执行本地业务事务。返回 COMMIT 或 ROLLBACK，让 Broker 将半消息变为正常消息或删除它。

完整流程图解

Producer Broker Consumer
│ │ │
│ ① 发送 Half 消息 │ │
│─────────────────────────▶│ │
│ │ 存储 Half 消息 │
│ ├───────────────────────────►│
│ ② Half 成功确认 │◀───────────────────────────┤
│ │ │
│ ③ 执行本地事务 │ │
│ ├── 本地成功 → Commit │ │
│ └── 本地失败 → Rollback │◀───────────────────────────┤
├─────────────────────────────►│ ◄─┤
│ 若 Commit : │ ◄─┤
│ ⑤ 半消息变为正常 ├───────────────────────►▼
├─────────────────────────────►│ ◄─┤
│ 若 Rollback : │ ◄─┤
│ ⑤ 删除半消息 ├───────────────────────►▼
├─────────────────────────────►│ ◄─┤
| 若超时未确认 : |
| ⑥ Broker 主动回查 |
| |
| ➡ checkLocalTransaction |
| |
| 返回 COMMIT/ROLLBACK/UNKNOWN |
| |
| 若连续 UNKNOWN 超过阈值 ： |
| 自动回滚半消息 |
| |

事务回查机制

痛点三： 在网络抖动或生产者异常崩溃时如果生产者没有及时告知 Broker，就会出现半挂状态。Broker 必须主动回查以确保最终一致性。

• CURRENT_STATE_COMMIT_MESSAGE: 本地事务已成功，提交半消息。
• CURRENT_STATE_ROLLBACK_MESSAGE: 本地事务失败，回滚半消息。
• CURRENT_STATE_UNKNOWN: 当前无法确定状态，Broker 回查。默认回查次数为15次若仍 UNKNOWN 则强制回滚，以防悬挂死锁。

这个设计非常巧妙。即使生产者宕机也能通过定期回查最终确定状态，不会出现 “半信息永远悬挂” 的情况。

--

Three