XA方案
两阶段提交 | 三阶段提交
- 准备阶段的资源锁定，存在性能问题，严重时会造成死锁问题
- 提交事务请求后，出现网络异常，部分数据收到并执行，会造成一致性问
TCC方案
Try Confirm Cancel / 短事务
- Try 阶段：这个阶段说的是对各个服务的资源做检测以及对资源进行锁定或者预留
- Confirm 阶段：这个阶段说的是在各个服务中执行实际的操作
- Cancel 阶段：如果任何一个服务的业务方法执行出错，那么就需要进行补偿/回滚
Saga方案
事务性补偿 / 长事务
- 流程长、流程多、调用第三方业务
本地消息表（eBay）
MQ最终一致性
比如阿里的 RocketMQ 就支持消息事务（核心：双端确认，重试幂等）
- A (订单) 系统先发送一个 prepared 消息到 mq，prepared 消息发送失败则取消操作不执行了
- 发送成功后，那么执行本地事务，执行成功和和失败发送确认和回滚消息到mq
- 如果发送了确认消息，那么此时 B (仓储) 系统会接收到确认消息，然后执行本地的事务
- mq 会自动定时轮询所有 prepared 消息回调的接口，确认事务执行状态
- B 的事务失败后自动不断重试直到成功，达到一定次数后发送报警由人工来手工回滚和补偿
最大努力通知方案（订单 -> 积分）
- 系统 A 本地事务执行完之后，发送个消息到 MQ；
- 这里会有个专门消费 MQ 的最大努力通知服务，接着调用系统 B 的接口；
- 要是系统 B 执行失败了，就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃
你找一个严格资金要求绝对不能错的场景，你可以说你是用的 TCC 方案；
如果是一般的分布式事务场景，例如积分数据，可以用可靠消息最终一致性方案
如果分布式场景允许不一致，可以使用最大努力通知方案
