1、分布式事务
目前分布式事务的解决方案有 AT、TCC、Saga、MQ、XA、BED 六种。
1.1 两阶段提交
角色：事务管理器、资源管理器
通过事务管理器来协调多个资源服务的事务处理过程
刚性事务（保证强一致性）
image.png
过程：
- 第一阶段：
1.1. 事务管理器向所有资源服务发送事务内容，询问是否准备执行事务；
1.2. 所有资源服务器执行事务操作，记录redo和undo日志；（主要过程）
1.3. 资源服务器向事务管理器响应：事务已准备好（还没有提交）. - 第二阶段：
2.1.事务管理器想资源服务器发起提交事务指令；
2.2. 资源服务器commit事务（很快，出问题概率小）
2.3. 资源服务器向事务管理器响应：提交完毕；
2PC存在的问题
- 事务管理器单点问题
- 同步阻塞：在提交完成之前，资源服务器中的资源一直处于阻塞状态
- 数据不一致
1.2 三阶段提交（3PC）
为了阶段2PC的问题：3PC主要解决的单点故障问题，并减少阻塞
- 第一阶段：canCommit
- 第二阶段：preCommit
- 第三阶段：doCommit
1.2 柔性事务
包含：最终一致性、TCC事务、补偿机制、MQshi'x
刚性事务方式带来的问题太多，应该尽量避免分布式事务
1.3 TCC事务
基于业务层面的事务定义，它把事务运行过程分成 Try、Confirm / Cancel 两个阶段。在每个阶段（提交或者回滚）的逻辑由业务代码控制
image.png
// try
@Compensable(confirmMethod = "confirmRecord", cancelMethod = "cancelRecord", transactionContextEditor = MethodTransactionContextEditor.class)
public String record(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {}
// confirm
public void confirmRecord(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {}
// cancel
public void cancelRecord(TransactionContext transactionContext, CapitalTradeOrderDto tradeOrderDto) {}
对于基于XA规范实现的二阶段提交（如spring的JTA框架）和三阶段提交，一般应用于同一个服务操作不同数据库的分布式事务场景；（缺点：性能问题，数据不一致）
而跨服务的分布式事务一般使用TCC（缺点：代码侵入大）；
1.4 MQ事务消息
在分布式消息队列中，目前唯一提供完整的事务消息的，只有 RocketMQ
image.png
这种方式只能保证消息生产者方的事务性，无法保证消费者方的事务性，如果消费处理消息失败，无法回滚，只有人工介入；
从工程实践角度讲，这种整个流程自动回滚的代价是非常巨大的，不但实现复杂，还会引入新的问题。
比如自动回滚失败，又怎么处理？
对应这种极低概率的case，采取人工处理，会比实现一个高复杂的自动化回滚系统，更加可靠，也更加简单。
1.5 seata
阿里出品，业务无侵入
先提交方案，回滚靠日志反向更新SQL；
官方文档
