分布式数据管理架构有哪些 分布式管理模式

Seata四种分布式事务解决方案

1.XA模式原理

• 首先我们先来了解一下TC、TM、RM

• TC（事务协调器）：

• 事务协调器是Seata架构中的核心组件之一。它负责协调和管理分布式事务的整个过程。事务协调器协调各个参与者（包括事务管理器和资源管理器）的行为，确保事务的一致性和隔离性。它接收事务请求，协调各个参与者的事务操作，并最终决定事务的提交或回滚。

• TM（事务管理器）：

• 事务管理器是Seata架构中的组件之一，负责管理和控制事务的生命周期。事务管理器与业务系统进行交互，接收事务请求，并根据事务协调器的指令执行相应的操作。它负责开启、提交或回滚事务，并保证事务的一致性和持久性。

• RM（资源管理器）：

• 资源管理器是Seata架构中的组件之一，负责管理和操作特定资源（如数据库、消息队列等）。它与事务管理器进行交互，接收事务操作的请求，并执行相应的数据库操作或资源操作。资源管理器负责事务的本地资源管理，以保证事务的原子性和持久性。

• XA规范是x/Open组织定义的分布式事务处理( DTP，Distributed Transaction Processing)标准，XA规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对XA规范提供了支持。

• seata的XA模式做了一些调整，但大体相似:

• RM一阶段的工作:

• 注册分支事务到TC
• 执行分支 业务sql但不提交.
• 报告执行状态到TC

• TC二阶段的工作:

• TC检测各分支事务执行状态

• 如果都成功，通知所有RM提交事务
• 如果有 失败，通知所有RM回滚事务

• RM二阶段的工作:

• 接收TC指令,提交或回滚事务

• 优点

• 事务的强一致性,满足ACID原则。
• 常用数据库都支持，实现简单，并且没有代码侵入

• 缺点

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

• 实现
• Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下:

• 1.修改application.yml文件( 每个参与事务的微服务)，开启XA模式:

seata:
	data-source-proxy-mode: XA #开启数据源代理的XA模式

• 给发起全局事务的入口方法添加@GlobalTransactional注解，本例中是OrderServicelmpl中的create方法:

@Override
@GlobalTransactional
public Long create(Order order) {
    // 创建订单
    orderMapper.insert(order);
    //扣余额...略
    //扣减库存...略
    return order.getId() ;
}

2.AT模式

• AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
• 这里第四步直接提交事务，并且形成了一个快照undo-log,成功后通知TC提交事务，这次的提交是去删除这个undo-log，如果失败就可以根据这个undo-log回滚事务

• 阶段一RM的工作:

• 注册分支事务
• 记录undo-log ( 数据快照)
• 执行业务sql并提交
• 报告事务状态

• 阶段二提交时RM的工作:

• 删除undo-log即可
• 阶段二回滚时RM的工作:
• 根据undo-log恢复数据到更新前

• AT模式与XA模式最大的区别是什么?

• XA模式一阶段不提交事务，锁定资源; AT模式一阶段直接提交，不锁定资源。
• XA模式依赖数据库机制实现回滚; AT模式利用数据快照实现数据回滚。
• XA模式强一致; AT模式最终一致（如果提交时有的成功有的失败，数据不一致）

2.1 AT模式的脏写问题

• 如果事务1执行释放锁后，事务二执行也释放锁后，这时事务由于一些原因回滚，导致事务二的提交丢失

• 为了解决这个问题，我们引入了全局锁，具体流程如下：

• 事务二不能获取全局锁，等待超时后自动释放DB锁，这样就可以避免这个问题

• 但是如果其事务，没有被Seata管理的事务，不需要获取全局锁就能修改表，这也会导致脏写

• 我们就可以生成两个快照，修改之前的和修改之后的快照，发现修改之后，就可以进行及时的恢复：

• AT模式的优点:

• 一阶段完成直接提交事务,释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成回滚和提交

• AT模式的缺点:

• 两阶段之间属于软状态，属于最终一致
• 框架的快照功能会影响性能，但比XA模式要好很多

• AT实现
• AT模式中的快照生成、回滚等动作都是由框架自动完成，没有任何代码侵入，因此实现非常简单。

• 导入Sql文件: seata-at.sql, 其中lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库:
• 修改application.yml文件，将事务模式修改为AT模式即可:

seata:
	data-source-proxy-mode: AT #开启数据源代理的XA模式

3.TCC模式

• TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:

• Try:资源的检测和预留;
• Confirm:完成资源操作业务;要求Try成功Confirm一定要能成功。
• Cancel:预留资源释放，可以理解为try的反向操作。

• 举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。

• 阶段一( Try ) :检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30

• 阶段二:假如要提交(Confirm) ,则冻结金额扣减30

• 阶段二:如果要回滚(Cancel) ，则冻结金额扣减30，可用余额增加30

• TCC的工作模型图:

• TCC的优点

• 阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

• TCC缺点

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
• 软状态，事务是最终一致
• 需要考虑Confirm和Cancel的失败情况，做好幂等处理

3.1 TCC的空回滚和业务悬挂

• 当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

• 对于已经空回滚的业务，如果以后继续执行try,就永远不可能confirm或cancel,这就是业务
  悬挂。应当阻止执行空回滚后的try操作，避免悬挂

• TCC的Try、Confirm、 Cancel方法都需要在接口中基于注解来声明，语法如下:

@LocalTCC
public interface TCCService {
    /**
    * Try逻辑，@TwoPhaseBusinessAction中的name属性要与当前方法名一致，用于指定Try逻辑对应的方法
    */
    @TwoPhaseBusinessAction(name = "prepare", commitMethod = "confirm"，rollbackMethod = "cancel")
    //使用@BusinessActionContextParameter标记的参数，在BusinessActionContext可以拿到
    void prepare(@BusinessActionContextParameter (paramName = "param") String param) ;
    /**
    *二阶段confirm确认方法、 可以另命名，但要保证与commitMethod一致
    *
    * @param context. 上下文，可以传递try方法的参数
    * @return boolean 执行是否成功
    boolean confirm (BusinessActionContext context) ;
    /**
    *二阶段回滚方法，要保证与rollbackMethod一致
    */
    boolean cancel (BusinessActionContext context) ;
}

• RootContext.getXID()可以获取全局事务id

4.SAGA模式

• Saga模式是SEATA提供的长事务解决方案。也分为两个阶段:

• 一阶段:直接提交本地事务
• 二阶段:成功则什么都不做;失败则通过编写补偿业务来回滚

• Saga模式优点:

• 事务参与者可以基于事件驱动实现异步调用，吞吐高
• 一阶段直接提交事务，无锁，性能好
• 不用编写TCC中的三个阶段，实现简单;

• 缺点:

• 软状态持续时间不确定，时效性差
• 没有锁，没有事务隔离，会有脏写

5.四种对比

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务	基于关系型数据库的大多数分布式事务场景都可以	对性能要求较高的事务。有非关系型数据库要参与的事务。	业务流程长、业务流程多 参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口