分布式事务Seata框架的AT模式

大纲

• 分布式事务
• seata架构

1.分布式事务

在分布式系统架构中，复杂的业务需要跨库操作，要保证全局的事务一致性问题就得需要解决分布式事务问题。

1.1 XA规范

XA规范中，规定了三种角色：AP应用程序、RM资源管理器(数据库)、TM事务管理器。XA规范定义了RM-TM的通信接口。

1.2 2PC两阶段提交

2PC和XA规范没有必然联系，但是2PC模式是对XA规范的一种抽象实现和优化。2PC一共有2个阶段：预提交和commit。

     1. TM通知每个RM准备提交各自的本地事务。
     1. TM根据步骤1各个RM反馈的预提交结果来决定是否下达commit的命令。

2PC存在几个严重的问题：

     - 阻塞延迟较大。
     - TM的单点故障问题。
     - 全局数据不一致问题，在阶段二中，TM下达了commit操作，但是只有一部分RM接收到了commit，一部分没有接收到，就产生了不一致的问题。

1.3 3PC三阶段提交

3PC是2PC的改进版本，但是没有本质区别，和2PC不同的是：

     - 引入了超时机制，在TM和RM都存超时机制。
     - 在2PC的预提交和commit中间穿插了一个准备阶段，所以3PC有3个阶段：CanCommit、PreCommit、Commit。

1.4 TCC

Try-Confirm-Cancel，本质也是业务服务化的两阶段提交协议，TCC一共有3个步骤，第一阶段需要由应用程序来进行对资源的预留，当所有参与者的try接口都成功了，那么事务管理器就会提交事务进行confirm，否则进行cancel回滚资源释放。TCC的try阶段一般需要将资源进行一个前置快照将事务数据的改变记录下来，后续在提交或者回滚的时候基于这个记录进行一致性对齐操作。

1.5 柔性事务

柔性事务指的是服务基本可用、软状态/中间态、最终一致；核心思想就是分布式环境下无法保证强一致性，而是结合自身的业务场景做一些妥协。常见的柔性事务解决方案有：最大努力通知、补偿、最终一致性/异步确保、两阶段提交式。

2.Seata

Seata是一个阿里开源的分布式事务解决框架。它支持AT、TCC、Saga、XA多种模式。Seata的组织架构中有三个角色：

• TC（Transaction Coordinator）事务协调器：维护全局的事务和分支事务的信息，控制全局事务的提交或者回滚，TC是需要独立部署的一个服务，而TM和RM是一个client客户端依赖到项目里。
• TM（Transaction Manager）事务管理器：全局事务的开启和边界的定义。
• RM（Resource Manager）资源管理器：对本地分支事务的管理，负责和TC交互和报告事务状态，执行具体的提交或者回滚。

3.Seata AT模式(主流)

Seata支持多种分布式事务模式，官方主推的是AT模式，AT模式是一种无侵入式的、类似于自动化的隐式TCC模式。AT模式一共分为2个阶段：

1. 业务数据和undoLog记录在同一个事务中并提交，随后释放本地锁和连接资源。
2. 如果需要提交，则异步提交。如果需要回滚，则本地执行undoLog进行反向补偿。

3.1 AT模式的优点

  - 自动化的代理了DataSource，自动化实现了补偿逻辑，降低了业务代码入侵。
  - TC事务协调者的引入，简化了一些事务控制逻辑。
  - 分布式事务的隔离性通过全局锁和本地锁来保证实现了写隔离和读隔离。

一阶段本地事务Commit之前需要拿到全局事务锁； 如果没有拿到全局锁则提交不了本地事务，尝试获取全局锁有时间次数限制，超过阈值则执行本地事务的回滚。

3.2 AT模式的不足

     - 性能，事务过程中涉及多次的RPC远程调用和各种SQL解析和快照落库。
     - 对于热点数据的隔离性问题存在性能问题。
     - 因为引入了锁的机制，可能会造成死锁，虽然有超时时间，但是对性能还是有影响。

原文链接：https://juejin.cn/post/7123890107966292005