阿里分布式中间件Seata从入门到精通

最近在写一本关于阿里巴巴分布式事务中间件 Seata 的电子书，Seata可以说是分布式事务中间件中最完善的了，包括了 AT、TCC、Saga、XA 四种模式，目前 Seata 已经更新到了 1.4.2 版本。

这本电子书主要分成两部分，第一部分是入门学习，目前已经更新完成，第二部分是源码解读，Seata 的源代码写的还可以，值得阅读。

整本书目前的目录结构如下：

喜欢的朋友欢迎下载学习。获取方式：关注公众号，后台回复：Seata。

下面简要介绍 Seata 的四种模式。

AT 模式

AT 模式参考了单数据库的事务原理，我们可以把分布式事务中每个数据库看做是单数据库的表。首先每个事务有一个全局的事务 id，叫做 xid。有了这个 xid 后，我们就可以记录undo_log 了，undo_log 中记录了这个 xid 对应回滚数据，每次提交事务前都要先写 undo_log，后提交事务，这参考了 mysql 中的 WAL 机制。而rollback_info 字段记录了要回滚的表的记录中的每个字段和对应值，这样就可以方便的回滚了。

AT模式的两阶段提交体现如下：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：异步 commit，非常快速地完成。rollback 则通过一阶段的回滚日志进行反向补偿

AT 模式读写都有隔离性，这里简单描述。

写隔离

• 一阶段本地事务提交前，需要确保先拿到**全局锁* 。
• 拿不到全局锁 ，不能提交本地事务。
• 拿全局锁的尝试会有超时时间限制，超出范围将放弃，并回滚本地事务，释放本地锁。

上面是官网的描述，非常容易理解，如果获取不到全局锁，就不能提交本地事务，只能等待全局锁直到超时。

读隔离

AT模式的读隔离需要本地事务隔离级别在读已提交或以上，AT 模式默认的全局隔离级别是读未提交 。

如果应用在特定场景下，必需要求全局的读已提交 ，Seata 需要通过 SELECT FOR UPDATE 语句代理来实现。

SELECT FOR UPDATE 语句的执行会申请全局锁 ，如果全局锁被其他事务持有，则释放本地锁并重试。这个过程中，查询是被 block 住的，直到全局锁拿到。

TCC 模式

简单来讲，TCC模式就是将整个事务分成两个阶段来提交，try阶段进行预留资源，如果所有分支都预留成功，则进入commit阶段提交所有分支事务，否则执行cancel取消所有分支事务。

以电商系统为例，假如有订单、库存和账户3个服务，客户购买一件商品，订单服务增加订单，库存服务扣减库存，账户服务扣减金额，这三个操作必须是原子性的，要么全部成功，要么全部失败。

try阶段

如下图：

订单服务增加一个订单，库存服务冻结订单上的库存，账户服务冻结订单上的金额。这个阶段数据进入中间态。

commit阶段

如下图：

commit阶段，数据从中间态转入终态，比如订单金额从中间账户转到最终账户。

cancel阶段跟commit阶段类似，比如订单金额从中间账户退回到客户账户。

Saga 模式

Saga 模式适用于长流程的业务场景，用状态机来控制整个事务的执行。它使用状态图定义服务调用流程并生成 Json 状态语言定义文件，状态图的节点可以是一个服务，也可以是补偿节点。

下面这张图定义了电商系统的业务流程，根据这个流程图可以定义出 Json 文件中供状态机使用。

XA 模式

XA 模式需要分支事务数据库支持 XA 原语，看一下官方这张图：

XA 模式的两阶段提交跟 TCC 模式的两阶段提交类似，都是由 TM 开启全局事务，RM 向 TC注册分支事务并且报告分支事务状态，TC 根据全局事务的状态来提交或回滚分支事务。

而在代码实现上，XA 模式使用的是数据源代理来实现的。跟 TCC 模式不同的是，XA 模式只要有 prepare 方法即可。

Seata 对XA做了优化，把 Start | SQL | Prepare 合成了一个阶段。这对 MySQL 数据库是支持的，但是对 Oracle 数据库不支持。