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

Seata

官方文档：https://seata.apache.org/zh-cn/docs/user/configurations/

在单体服务中，一个请求只会在一个服务中，连接一个数据库，对事务的回滚就可以使用 @Transational 进行回滚，保证数据的一致性。
在微服务项目中，一个请求可能会涉及多个服务，每个服务会单独连接数据库，此时的 @Transactional 注解无法保证微服务下数据的一致性。

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

Seata——架构原理

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

Seata——实现分布式事务

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

Seata——原理

1. 二阶提交协议

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

2. 四种事务模式

官方文档：https://seata.apache.org/zh-cn/docs/user/mode/at

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