共计 2554 个字符，预计需要花费 7 分钟才能阅读完成。
一、Seata 概述
Seata 是 Simple Extensible Autonomous Transaction Architecture 的简写，由 feascar 改名而来。
Seata 是阿里开源的分布式事务框架，属于二阶段提交模式。
目前 github 上曾经有 12267 颗星了，也很沉闷，最新的提交工夫很多都是几天前。
首先咱们回顾一下在单体利用中，例如一个业务调用了 3 个模块，他们都应用同一个数据源，是靠本地事务来保障事务一致性。
但在微服务架构中，这 3 个模块会变为 3 个独立的微服务，各自有本人的数据源，调用逻辑就变为：
Seata 如何解决呢？
Business 是业务入口，在程序中会通过 注解 来阐明他是一个 全局事务，这时他的角色为 TM（事务管理者）。
Business 会申请 TC（事务协调器，一个独立运行的服务），阐明本人要开启一个全局事务，TC 会生成一个全局事务 ID（XID），并返回给 Business。
Business 失去 XID 后，开始调用微服务，例如调用 Storage。
（和下面的图一样，不便查看，避免滚到到这儿时曾经看不到下面的图片了）
Storage 会收到 XID，晓得本人的事务属于这个全局事务。Storage 执行本人的业务逻辑，操作本地数据库。
Storage 会把本人的事务注册到 TC，作为这个 XID 上面的一个 分支事务，并且把本人的事务执行后果也通知 TC。
此时 Storage 的角色是 RM（资源管理者），资源是指本地数据库。
Order、Account 的执行逻辑与 Storage 统一。
在各个微服务都执行实现后，TC 能够晓得 XID 下各个分支事务的执行后果，TM（Business）也就晓得了。
Business 如果发现各个微服务的本地事务都执行胜利了，就申请 TC 对这个 XID 提交，否则回滚。
TC 收到申请后，向 XID 下的所有分支事务发动相应申请。
各个微服务收到 TC 的申请后，执行相应指令，并把执行后果上报 TC。
重要机制
（1）全局事务的回滚是如何实现的呢？
Seata 有一个重要的机制：回滚日志。
每个分支事务对应的数据库中都须要有一个 回滚日志表 UNDO_LOG，在真正批改数据库记录之前，都会先记录批改前的记录值，以便之后回滚。
在收到回滚申请后，就会依据 UNDO_LOG 生成回滚操作的 SQL 语句来执行。
如果收到的是提交申请，就把 UNDO_LOG 中的相应记录删除掉。
（2）RM 是怎么主动和 TC 交互的？
是通过 监控拦挡 JDBC实现的，例如监控到开启本地事务了，就会主动向 TC 注册、生成回滚日志、向 TC 汇报执行后果。
（3）二阶段回滚失败怎么办？
例如 TC 命令各个 RM 回滚的时候，有一个微服务挂掉了，那么所有失常的微服务也都不会执行回滚，当这个微服务从新失常运行后，TC 会从新执行全局回滚。
1.3 外围组件
回顾一下其中的 外围组件：
- 事务协调器 TC
保护全局和分支事务的状态，批示全局提交或者回滚。
- 事务管理者 TM
开启、提交或者回滚一个全局事务。
- 资源管理者 RM
治理执行分支事务的那些资源，向 TC 注册分支事务、上报分支事务状态、管制分支事务的提交或者回滚。
1.4 具体工作过程
再从宏观上梳理一下 Seata 的工作过程：
- TM 申请 TC，开始一个新的全局事务，TC 会为这个全局事务生成一个 XID。
- XID 通过微服务的调用链传递到其余微服务。
- RM 把本地事务作为这个 XID 的分支事务注册到 TC。
- TM 申请 TC 对这个 XID 进行提交或回滚。
- TC 指挥这个 XID 上面的所有分支事务进行提交、回滚。
二、Seata 具体工作流程示例
上面咱们通过一个分支事务的执行过程来理解 Seata 的工作流程。
例如有一个业务表 product(id,name)，分支事务的业务逻辑：
update product set name = 'GTS' where name = 'TXC';2.1 一阶段
（1）解析 SQL
失去 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相干的信息。
（2）查问前镜像
依据解析失去的条件信息，生成查问语句，定位数据。
select id, name from product where name = 'TXC';失去前镜像：
| id | name |
|---|---|
| 1 | TXC |
（3）执行业务 SQL
执行本人的业务逻辑：
update product set name = 'GTS' where name = 'TXC';把 name 改为了 GTS。
（4）查问后镜像
依据前镜像的后果，通过 主键 定位数据。
select id, name from product where id = 1;失去后镜像：
| id | name |
|---|---|
| 1 | GTS |
（5）插入回滚日志
把前后镜像数据以及业务 SQL 相干的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
（6）提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁。
（7）本地事务提交：业务数据的更新和后面步骤中生成的 UNDO LOG 一并提交。
（8）将本地事务提交的后果上报给 TC。
2.2 二阶段 – 回滚
（1）收到 TC 的分支回滚申请，开启一个本地事务，执行如下操作。
（2）通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
（3）数据校验
拿 UNDO LOG 中的后镜与以后数据进行比拟，依据校验后果决定是否做回滚。
（4）依据 UNDO LOG 中的前镜像和业务 SQL 的相干信息生成并执行回滚的语句：
update product set name = 'TXC' where id = 1;（5）提交本地事务
并把本地事务的执行后果（即分支事务回滚的后果）上报给 TC。
二阶段 – 提交
（1）收到 TC 的分支提交申请，把申请放入一个异步工作的队列中，马上返回提交胜利的后果给 TC。
（2）异步工作阶段的分支提交申请，将异步和批量地删除相应 UNDO LOG 记录。
三、小结
下面介绍的是 Seata 的 AT 模式，就是自动化事务，应用非常简单，对业务代码没有侵入性。
有余的中央是目前文档比拟少，网上的相干资料也不是很多，所以应用过程中遇到问题时可能就须要本人查看源码，剖析原理。
Seata 还反对 TCC 和 Saga 模式，但反对的次要形式是 AT。
写在最初
欢送大家关注我的公众号【惊涛骇浪如码】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。
感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！
