分布式事务详解3---Seata分布式事务框架

这边介绍下阿里开源分布式事务框架Seata。

1 Seata简介

Seata （原名 Fescar ）是阿里 18 年开源的分布式事务的框架。 Fescar 的开源对分布式事务框架领域影响很大。作为开源大户，Fescar 来自阿里的GTS（PS：当然如果成本允许，可以直接用GTS，按量收费），经历了好几次双十一的考验，一经开源便颇受关注。后来Fescar改名为Seata 。

Fescar 虽然是二阶段提交协议的分布式事务，但是其解决了 XA 的一些缺点 :

单点问题:
同步阻塞:Fescar的二阶段，其再第一阶段的时候本地事务就已经提交释放资源了，不会像XA会再两个prepare和commit阶段资源都锁住，并且Fescar,commit是异步操作，也是提升性能的一大关键。
数据不一致:如果出现部分commit失败，那么fescar-server会根据当前的事务模式和分支事务的返回状态的结果来进行不同的重试策略。并且fescar的本地事务会在一阶段的时候进行提交，其实单看数据库来说在commit的时候数据库已经是一致的了。
只能用于单一数据库: Fescar提供了两种模式，AT和MT。在AT模式下事务资源可以是任何支持ACID的数据库，在MT模式下事务资源没有限制，可以是缓存，可以是文件，可以是其他的等等。

当然这两个模式也可以混用。

同时 Fescar 也保留了接近 0 业务入侵的优点，只需要简单的配置 Fescar 的数据代理和加个注解，加一个Undolog表，就可以达到我们想要的目的。

2 实现原理

Fescar 将一个本地事务做为一个分布式事务分支，所以若干个分布在不同微服务中的本地事务共同组成了一个全局事务，结构如下：

Transaction Manager (TM) ：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。

Resource Manager (RM) ：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

一个典型的分布式事务过程：

TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
XID 在微服务调用链路的上下文中传播。
RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
TM 向 TC 发起针对 XID 的全局提交或回滚决议。
TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

3 Fescar模式

Fescar 对分布式事务的实现提供了 3 种模式， AT 模式、 MT 模式和混合模式：

3.1 AT模式

业务逻辑不需要关注事务机制，分支与全局事务的交互过程自动进行。

AT 模式：主要关注多 DB 访问的数据一致性，实现起来比较简单，对业务的侵入较小。

AT 模式部分代码如下：不需要关注执行状态，对业务代码侵入较小。类似代码如下，只需要为方法添加 @GlobalTransactional 注解即可。

AT 模式的核心是对业务无侵入，是一种改进后的两阶段提交，其设计思路如图：

第一阶段：

核心在于对业务 sql 进行解析，转换成 undolog ，两阶段提交往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第一阶段释放对资源的锁定，降低了锁范围，提高效率，即使第二阶段发生异常需要回滚，只需找对undolog 中对应数据并反解析成 sql 来达到回滚目的。Seata通过代理数据源将业务 sql 的执行解析成 undolog 来与业务数据的更新同时入库，达到了对业务无侵入的效果。

第二阶段：

如果决议是全局回滚， RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。

3.1 MT模式

业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分，形成一个 MT 分支，加入全局事务。

MT 模式一方面是 AT 模式的补充。另外，更重要的价值在于，通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。

3.2 混合模式

因为 AT 和 MT 模式的分支从根本上行为模式是一致的，所以可以完全兼容，即，一个全局事务中，可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的： AT 模式可以支持的，使用AT 模式； AT 模式暂时支持不了的，用 MT 模式来替代。另外，自然的， MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起，纳入同一个分布式事务的管理中。

斑马工

发布了41 篇原创文章 · 获赞 47 · 访问量 3万+

私信关注