SpringCloud Alibaba Seata 分布式事务 和 其 原理

学习建议去官网
官网：http://seata.io/zh-cn/

分布式事务问题

单体应用被拆分为微服务应用，原来三个模块被拆分成三个独立的应用，分别使用3个独立的数据源，
业务操作需要调用三个服务来完成。此时每个服务内部数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证

Seata 简介

官网：http://seata.io/zh-cn/

seata 是什么？

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

Seata术语

TC - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

处理过程

Seata 下载 安装 部署

下载安装

下载地址：https://github.com/seata/seata/releases

解压后：
![在这里插入图片描述](https://img-blog.csdnimg.cn/20200511152505177.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z5ajEzOTI1NDc1OTU3,size_16,color_FFFFFF,t_70)

部署

参考官方文档：
http://seata.io/zh-cn/docs/ops/deploy-guide-beginner.html

Seata 分布式事务原理

seata 的数据库会有以下3个表

业务数据库会有一个 undo_log 表

XID - 全局事务的唯一ID标识

TC - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

一阶段

1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
   查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。
2. 查询前镜，像得到前镜像：根据解析得到的条件信息，生成查询语句，定位数据。得到前镜像（即执行业务sql前该数据的副本）
3. 执行业务 SQL
4. 查询后镜像，得到后镜像：根据前镜像的结果，通过 主键 定位数据。得到后镜像（该业务sql执行后，该数据的副本）
5. 插入回滚日志：把前 后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
6. 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
7. 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8. 将本地事务提交的结果上报给 TC。

上面的步骤概况起来就是：
业务数据库 在执行update_sql 前 先保存一份 要更新数据的副本，然后再执行 update_sql，然后再把更新后的数据 保存一份。然后向TC注册它自己，最后提交本地事务（重点是保存了 更新前后的数据副本，用以回滚用）

二阶段 - 提交

1. 收到 TC 的分支提交请求（即业务数据库收到TC发过来的提交请求），把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。
   

二阶段 - 回滚

1. 收到 TC 的分支 回滚请求（即业务数据库收到TC发过来的回滚请求），业务数据库开启一个本地事务，执行如下操作。
2. 在undo_logo 表中通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。（即查找保存原数据前后镜像）
3. 数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。
4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：
5. 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

简单概况就是：
TC 发起了 回滚请求，业务数据库收到了回滚请求，就拿出原来保存的数据副本，执行原来的数据的副本，把数据恢复到原来的样子，