阿里分布式事务框架Seata,AT模式原理解析

什么是分布式事务

如今在分布式技术盛行下,许多公司都已经在使用分布式技术了,虽然分布式技术给我们项目带来了三高(高可用,高扩展,高性能)等优点,但是缺点也很明显,分布式项目一般都是分服务开发,且多个服务部署在不同的服务器上,这样就产了分布式事务, 使用本地事务技术处理分布式事务就无法生效,此时就需要一个优秀的分布式事务框架来处理

分布式事务基础原理

两阶段提交(2pc)方案

两阶段提交协议(Two Phase Commitment Protocol)中,基于数据库XA协议(mysql5.0.3支持此协议),特点是对代码无侵害,缺点数据库必须支持XA协议,且XA协议自身的特点,会对事物资源照成长时间不释放,锁定周期比较长,应用层面不干涉,因此它的性能很差

2pc实现分为两个角色
一个事务协调者(coordinator):负责协调多个参与者进行事务投票及提交(回滚)
多个事物参与者(participants):即本地事物执行者

处理步骤两个
1.投票阶段(voting phase):协调者将通知事务参与者准备提交或取消事务,然后进入表决过程,参与者叫高协调者自己的决策,同意(事务参与者本地事务执行成功,单未提交)或取消(本地事务执行故障)
2.阶段性提交(commit phase):收到参与者的通知后,协调者向参与者发出通知.根据反馈情况决定各参与者是否要提交还是回滚

如图所示 1-2位第一阶段.2-3为第二阶段

如果任一资源管理器在第一阶段返回准备失败,那么事务管理器会要求所以资源管理器在第二阶段执行回滚操作,通过事务管理器的两阶段协调,最终所有资源管理器要么全部提交,要么全部回滚,最终状态都是一致的

TCC方案

TCC三段式提交(Try-confirm-Cancel),事务控制交由业务实现,业务中的子模块都需要使用Try,Confirm,Cancel三个接口, 使用缺点业务会变得非常臃肿,维护成本高,但是TCC让应用程序自己定义数据库的粒度,使降低锁冲突,提高性能

TCC名称解释
T(Try):完成业务方面的检查,预留相关的资源,假设一个业务完成需要A,B,C三个子事务完成,这三个都需要调用Try
C(Confirm):成功预占资源(A,B,C三个Try都成功),真正执行业务
C(Cancel):事务执行失败(A,B,C三个Try只要有一个失败),释放Try阶段资源

Saga方案
将Try和confirm合成一个阶段,cancel变成功补偿阶段,官方定义
1:每个Saga将一个大的分布式事务拆分为若干sub-transaction Ti
2:每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果
当Saga事务中的任何一个本地事务执行失败之后，调用补偿方法恢复之前的事务，达到最终一致

恢复的方式:
向后恢复：按照调用顺序倒序调用Ci-1之后的补偿方法。之所以从Ci-1开始，因为Ci执行失败，已经从本地事务进行回滚了。

向前恢复：一直重试执行失败的事务，知道执行成功。

事务特征：
不具有隔离性，需要业务方法控制并发，保证某个执行失败的事务，所占有的资源不会业务上影响别的事务执行，
一致性：追中一致性

Seata框架

Seata简介
阿里中间间团队于2019.1月开源的分布式事务项目,原名Fescar,后改名Seata, 全程fast easy commit and rollback，中文直译就是：快速、简单地提交和回滚,并且Seata为提供了AT,TCC,SAGA和XA四种事务解决模式

AT模式(Seata默认使用)
Seata At 是基于XA事务演变而来的,XA是一个基于数据库实现的分布式事务协议, 但是Seata却不需要遵循 数据库XA协议

AT模式分为三个角色

官方介绍:
TC(Transaction Coordinator)-事务协调者:维护全局和分支事务的状态,驱动全局事务提交或回滚

TM(Transaction Manager)-事务管理器:定义全局事务范围,开始全局事务,提交或回滚全局事务

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

TM是一个分布式事务的发起者和终结者，TC负责维护分布式事务的运行状态，而RM则负责本地事务的运行。如下图所示：

Seata全局事务的执行步骤

1.TM先TC申请一个全局事务,全局事务创建成功并生成一个全局的XID;

2.XID在微服务调用链路的上下文中传播

3.RM向TC注册分支事务,接着执行这个分支事务并提交(重点:RM在第一阶段就已经执行了本地事务的提交/回滚),最后将执行结果汇报给TC

4.TM根据TC中所有的分支事务执行情况,发起全局提交或回滚决议

5.TC调度XID下管辖的全部分支事务完成提交或回滚请求

AT 模式如何做到对业务的无侵入 ：

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务

整体提交机制
两阶段提交协议的演变:
一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源
二阶段

1. 提交异步化,非常快速地完成
2. 回滚通过一阶段的回滚日志进行反向补偿

一阶段：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

Seata隔离级别

Seata由于一阶段RM自动提交本地事务的原因，默认隔离级别为Read Uncommitted。如果希望隔离级别为Read Committed，那么可以使用SELECT…FOR UPDATE语句。Seata引擎重写了SELECT…FOR UPDATE语句执行逻辑，SELECT…FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT…FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是已提交的才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。