分布式事务

1、分布式事务

目前分布式事务的解决方案有 AT、TCC、Saga、MQ、XA、BED 六种。

1.1 两阶段提交

角色：事务管理器、资源管理器
通过事务管理器来协调多个资源服务的事务处理过程
刚性事务（保证强一致性）

image.png

过程：

1. 第一阶段：
   1.1. 事务管理器向所有资源服务发送事务内容，询问是否准备执行事务；
   1.2. 所有资源服务器执行事务操作，记录redo和undo日志；（主要过程）
   1.3. 资源服务器向事务管理器响应：事务已准备好（还没有提交）.
2. 第二阶段：
   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；
官方文档