分布式事务之Seata

一、背景
随着业务发展，单体系统逐渐无法满足业务的需求，分布式架构逐渐成为大型互联网平台首选。伴随而来的问题是，本地事务方案已经无法满足，分布式事务相关规范和框架应运而生。
在这种情况下，大型厂商根据分布式事务实现规范，实现了不同的分布式框架，以简化业务开发者处理分布式事务相关工作，让开发者专注于核心业务开发。
Seata就是这么一个分布式事务处理框架，Seata是由阿里开源，前身为Fescar，经过品牌升级变身Seata。
二、分布式事务规范
1.分布式事务相关概念
事务： 一个程序执行单元，是用户定义的一组操作序列，需要满足ACID属性。
本地事务：事务由本地资源管理器管理。
分布式事务：事务的操作位于不同的节点。
分支事务：在分布式事务中，由资源管理器管理的本地事务。
全局事务：一次性操作多个资源管理器完成的事务，由一组分支事务组成。
2. 分布式事务实现规范
对于本地事务，可以借助DBMS系统来实现事务的管理，但是对于分布式事务，它就无能为力了。对于分布式事务，目前主要有2种思路：XA协议的强一致规范以及柔性事务的最终一致性规范。
2.1 XA
XA是基于2阶段提交协议设计的接口标准，实现了XA规范的资源管理器就可以参与XA全局事务。应用承担事务管理器TM工作，数据库承担资源管理器RM工作，TM生成全局事务id，控制RM的提交和回滚。

2.2 柔性事务的最终一致性
该规范主要有3种实现方式，TCC、MQ事务消息、本地消息表。（还存在其他一些不常用实现方式如Saga）。
三、Seata 架构

1. 系统组成
   Seata有三个核心组件：
   Transaction Coordinator(TC，事务协调器)—— 维护全局事务和分支事务的状态，驱动全局事务提交或回滚。
   Transaction Manager(TM，事务管理器) —— 定义全局事务的范围，开始事务、提交事务、回滚事务。
   Resource Manager(RM，资源管理器)：—— 管理分支事务上的资源，向TC注册分支事务，汇报分支事务状态，驱动分支事务的提交或回滚。
   三个组件相互协作，TC 以 Server 形式独立部署，TM和RM集成在应用中启动，其整体交互如下：

2.工作模式
Seata 支持四种工作模式：
2.1 AT（Auto Transaction）
AT模式是Seata默认的工作模式。需要基于支持本地 ACID 事务的关系型数据库，Java 应用，通过 JDBC 访问数据库。
2.1.1 整体机制
该模式是XA协议的演变，XA协议是基于资源管理器实现，而AT并不是如此。AT的2个阶段分别是：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：提交异步化，非常快速地完成；回滚通过一阶段的回滚日志进行反向补偿。
第一个阶段
比如：下边我们更新 user 表的 name 字段。
update user set name = ‘小富最帅’ where name = ‘程序员内点事’
首先 Seata 的 JDBC 数据源代理通过对业务 SQL 解析，提取 SQL 的元数据，也就是得到 SQL 的类型（UPDATE），表（user），条件（where name = ‘程序员内点事’）等相关的信息。

第一个阶段的流程图
先查询数据前镜像，根据解析得到的条件信息，生成查询语句，定位一条数据。
select name from user where name = ‘程序员内点事’
数据前镜像
紧接着执行业务 SQL，根据前镜像数据主键查询出后镜像数据
select name from user where id = 1
数据后镜像
把业务数据在更新前后的数据镜像组织成回滚日志，将业务数据的更新和回滚日志在同一个本地事务中提交，分别插入到业务表和 UNDO_LOG 表中。
回滚记录数据格式如下：包括 afterImage 前镜像、beforeImage 后镜像、 branchId 分支事务ID、xid 全局事务ID

这样就可以保证，任何提交的业务数据的更新一定有相应的回滚日志。
在本地事务提交前，各分支事务需向 全局事务协调者 TC 注册分支 ( Branch Id) ，为要修改的记录申请 全局锁（保证事务隔离性） ，要为这条数据加锁，利用 SELECT FOR UPDATE 语句。而如果一直拿不到锁那就需要回滚本地事务。TM 开启事务后会生成全局唯一的 XID，会在各个调用的服务间进行传递。
有了这样的机制，本地事务分支（Branch Transaction）便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源。相比于传统的 XA 事务在第二阶段释放资源，Seata 降低了锁范围提高效率，即使第二阶段发生异常需要回滚，也可以快速 从UNDO_LOG 表中找到对应回滚数据并反解析成 SQL 来达到回滚补偿。
最后本地事务提交，业务数据的更新和前面生成的 UNDO LOG 数据一并提交，并将本地事务提交的结果上报给全局事务协调者 TC。
第二个阶段
第二阶段是根据各分支的决议做提交或回滚：
如果决议是全局提交，此时各分支事务已提交并成功，这时 全局事务协调者（TC） 会向分支发送第二阶段的请求。收到 TC 的分支提交请求，该请求会被放入一个异步任务队列中，并马上返回提交成功结果给 TC。异步队列中会异步和批量地根据 Branch ID 查找并删除相应 UNDO LOG 回滚记录。

如果决议是全局回滚，过程比全局提交麻烦一点，RM 服务方收到 TC 全局协调者发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
注意：这里删除回滚日志记录操作，一定是在本地业务事务执行之后

2.1.2 AT 如何保证分布式事务一致性

这个就是无侵入式 AT 模式的做法示意图。首先用户还是从接口进入，到达事务发起方，此时对业务开发者来说，这个发起方入口就是一个业务接口罢了，一样地执行业务 sql，一样地 return 响应信息给客户端并没有什么改变。而背后就是用户的 sql 被 Seata 代理所托管，Seata-AT 模式能感知到用户的所有 sql，并对之进行操作，来保证一致性。

1. 写隔离
   一阶段本地事务提交前，需要确保先拿到全局锁 。
   拿不到全局锁，不能提交本地事务。
   拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
   以一个示例来说明：
   两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。
   tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待全局锁 。

tx1 二阶段全局提交，释放全局锁 。tx2 拿到全局锁提交本地事务。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
此时如果 tx2 仍在等待该数据的全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。
以上便是如何保证了事务的隔离性。
2.AT 模式二阶段处理

由上图可见，在二阶段提交时，TC 仅是下发一个通知 ：把之前一阶段做记录的 undoLog 删除，并把相关事务信息如：行锁删除，之后让因为在竞争锁被阻塞的事务顺利进行。
而二阶段是回滚时，则要多做一些处理。

首先在 Client 端收到 TC 告知的二阶段是回滚时，会去查到对应的事务的 undolog，取出后镜像，对比当前的数据（因为 SeataAT 是从业务应用层面进行保护分布式事务，如果此时在数据库层面直接修改了库内信息，这个时候 SeataAT 的行锁不起隔离性作用），如果出现了在全局事务以外的数据修改，此时判定为脏写，而 Seata 因为无法感知这个脏写如何发生，此时只能打印日志和触发异常通知，告知用户需要人工介入（规范修改数据入口可避免脏写）。
而如果没有发生脏写就比较简单了，拿出前镜像，众所皆知事务是需要有原子性的，要么一起发生，要么都不发生，此时前镜像记录了发生之前的数据，进行回滚后，就达到了类似本地事务那样的原子性效果。回滚后，再把事务相关信息，如 undolog，行锁进行删除。二阶段回滚算是告一段落了。
2.1.3 特点

优点：对代码无侵入；并发度高，本地锁在一阶段就会释放；不需要数据库对XA协议的支持。
缺点：只能用在支持ACID的关系型数据库；SQL解析还不能支持全部语法。

2.2 TCC
2.2.1 整体机制
该模式工作分为三个阶段：

上图中对于多个分支事务，省略了多次出现的 2.* 步骤。对于全局事务执行过程中业务应用宕机情况，业务应用集群中对等节点会通过从TC获取相关会话，从DB加载详细信息来恢复状态机。
2.2.2 特点

优点：一阶段提交本地事务，无锁，高性能；事件驱动架构，参与者可异步执行，高吞吐；补偿服务易于实现。
缺点：不保证隔离性。

2.3 XA模式
XA是基于二阶段提交设计的接口标准。对于支持XA的资源管理器，借助Seata框架的XA模式，会使XA方案更简单易用。使用前提：需要分支数据库支持XA 事务，应用为 Java应用，且使用JDBC访问数据库。
2.3.1 整体机制
在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。
执行阶段：业务sql在XA分支中执行，由分支事务的RM管理器管理，然后执行XA prepare。
完成阶段：TM根据各个分支执行结果通过TC通知各个分支执行XA commit或者XA rollback。

2.3.2 特点
优点：继承了XA协议的优势，事务具有强一致性。
缺点：同样继承了XA协议的劣势，由于分支事务长时间开启，并发度低。
2.4 Seata 各模式对比
分布式事务方案没有银弹，根据自己的业务特性选择合适的模式。例如追求强一致性，可以选择AT和XA，存在和外部系统对接，可以选择Saga模式，不能依赖本地事务，可以采用TCC等等。结合各模式的优缺点进行选择。

由于本人能力有限，此文章参考了多篇技术博客，版权归原作者所有如有侵权请立即与我联系,我将及时处理。