最近在写一本关于阿里巴巴分布式事务中间件 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 数据库不支持。
最后,欢迎大家支持这本电子书,后面我会逐渐完善第二部分,我个人非常推荐。
号内回复 Seata 可以提取。