【SpringCloud | 第5篇】Seata分布式事务

Seata

在单体服务中，一个请求只会在一个服务中，连接一个数据库，对事务的回滚就可以使用 @Transational 进行回滚，保证数据的一致性。

在微服务项目中，一个请求可能会涉及多个服务，每个服务会单独连接数据库，此时的 @Transactional 注解无法保证微服务下数据的一致性。

Seata 用于解决分布式下的数据一致性。

TC（Transaction Coordinator）事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM（Transaction Manager）事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM（Resource Manager）资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

在项目中配置Seata之后，

只需要在 TM 事务管理器的方法上添加 @GlobalTransactional 注解，在其他本地事务加@EnableTransactionManagement，@Transactional，即可保证事务的一致性。

第一阶段------本地事务提交
（1）解析SQL
（2）生成前镜像：根据 SQL 中的 where 条件，查询修改操作前的数据，称为前镜像
（3）执行业务 SQL
（4）生成后镜像：根据 id 查询修改后的数据，称为后镜像
（5）插入回滚日志undo_log：将前镜像和后镜像保存到 undo_log 日志中
（6）注册分支事务：在TC中申请一个全局锁，锁定操作的数据防止其他人操作。TC的全局锁相当于MySQL的行级别锁，只锁操作的数据。
（7）本地事务提交：将业务数据和 undo_log 日志提交保存
（8）向 TC 汇报事务执行状态
第二阶段
-- 各事务分支均成功------分支提交
（1）收到 TC 提交响应请求，立即响应OK
（2）给异步任务队列添加异步任务
（3）异步和批量删除 undo_log 日志记录
-- 存在某个事务分支失败------分支回滚
（1）先找到uodo_log记录（通过XID，BranchID）
（2）数据校验，后镜像和当前数据是否一致，不一致说明当前数据被其他操作给篡改了，需要配置相应的策略；如果一致就说明一起ok，只需要回滚。
（3）回滚数据到前镜像的内容，完成后删除uodo_log记录。

AT 模式
默认模式。
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：（1）提交异步化，非常快速地完成。（2）回滚通过一阶段的回滚日志进行反向补偿。
XA 模式
第一阶段不会提交数据，阻塞事务请求 ，在第二阶段确认提交再提交或者回滚。全局锁+MySQL行锁在第一阶段就开启，事务一开始就用阻塞模式，性能差。
AT和XA区别：AT第一阶段执行完SQL释放行锁；XA是到第二阶段才提交SQL导致行锁从开始到最后，阻塞时间长性能差。但二者都是一直持有seata的全局锁的。
Saga 模式
Saga 模式是 SEATA 提供的长事务 解决方案。
对于短时间内执行不完的事务。例如请假审批，其他模式都用了锁，如果长期锁在那是对系统是非常大的阻塞。Saga是基于消息队列实现。
TCC 模式
主要是广义上的事务，需要写侵入式 的代码。需要业务系统自行实现 Try，Confirm，Cancel 三个操作 。
举例：业务需要三个事务，一个事务改数据库，一个发短信，一个发邮件，这就用AT和XA行不通了，无法回滚，如果全局事务失败，只能进行补偿性操作，例如再发邮件和短信提醒对方扣款失败或者订单失败等。