SpringCloud之Seata（一）
思维导图
1.概述
1.1 概念
Seata 是一款开源的分布式事务解决方案，提供高性能和简单易用的分布式事务服务。
2. 事务概述
2.1 角色
- TC（(Transaction Coordinator)）： 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
- TM(Transaction Manager)：事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
- RM (Resource Manager)：资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
2.2 工作图
3.Seata事务模式
3.1 AT 模式
3.1.1 概念
无侵入式的分布式事务解决方案，用户只需关注自己作为一阶段的业务SQL，Seata框架会自动生成事务进行二阶段提交和回滚操作。
3.1.2 两个阶段
一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段，提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
3.1.3 以订单服务为例
3.2 TCC 模式
3.2.1 概念
TCC 是分布式事务中的三阶段提交协议，它的全称为 Try-Confirm-Cancel，即资源预留（Try）、确认操作（Confirm）、取消操作（Cancel），具体含义如下：
Try尝试阶段：对业务资源的检查并预留；
Confirm确认阶段：对业务处理进行提交。即commit操作，只要 Try 成功，那么该步骤一定成功；
Cancel取消阶段：对业务处理进行取消。即回滚操作，该步骤回对Try预留的资源进行释放。、
3.2.2 优缺点
1. 优点
TCC 不需要依赖数据库，能够实现跨数据库、跨应用资源管理。对这些不同数据访问通过侵入式的编码方式实现一个原子操作。更好地解决了在各种复杂业务场景下的分布式事务问题。
2. 缺点
TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现。 对业务系统有着非常大的入侵性，设计相对复杂。
3.2.3 TCC和AT区别
1. AT 模式基于支持本地 ACID 事务的关系型数据库
一阶段 prepare 行为，在本地事务中，一并提交业务数据更新和相应回滚日志记录。
二阶段 commit 行为，马上成功结束，自动异步批量清理回滚日志。
二阶段 rollback 行为，通过回滚日志，自动生成补偿操作，完成数据回滚。
2. TCC 模式不依赖于底层数据资源的事务支持
一阶段 prepare 行为：调用自定义 的 prepare 逻辑。
二阶段 commit 行为：调用自定义 的 commit 逻辑。
二阶段 rollback 行为：调用自定义 的 rollback 逻辑。
3.3 Saga 模式
3.3.1 概念
Saga模式是SEATA提供的长事务解决方案，在Saga模式业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
3.3.2 工作图
3.3.3 适用场景
- 比如，老系统，封闭的系统（无法修改，同时没有任何分布式事务引入）。
- 或者事务参与者可能是其他公司的服务或者是遗留系统，无法改造。
- 那么AT、XA、TCC模型将全部不能使用，这时就可以使用Saga模式。
3.3.4 特点
Saga模式提供了异构系统的事务统一处理模型。所有的子业务都不在直接参与整体事务的处理（只负责本地事务的处理），而是全部交由了最终调用端来负责实现。而在进行总业务逻辑处理时，在某一个子业务出现问题时，则自动补偿全面已经成功的其他参与者。这样一阶段的正向服务调用和二阶段的服务补偿处理全部由总业务开发实现。
3.3.5 Saga状态机
1. 概述
目前Seata提供的Saga模式只能通过状态机引擎来实现。需要开发者通过Saga状态机手工进行Saga业务流程状态图的绘制，并且将其转换为Json配置文件。而后在程序运行时，将依据子配置文件实现业务处理以及服务补偿处理。
2. 基本原理
通过状态图来定义服务调用的流程并生成json定义文件。状态图中一个节点可以调用一个服务，节点可以配置它的补偿节点。状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚。可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能。
3.4 XA 模式
3.4.1 概念
XA模型用于解决分布式事务领域的问题，是最早的分布式事务处理方案。因为需要数据库内部也是支持XA模式的，比如MYSQL，XA模式具有强一致性的特点，因此他对数据库占用时间比较长，所以性能比较低。
3.4.2 特点
XA模式属于两阶段提交。第一阶段进行事务注册，将事务注册到TC中，执行SQL语句。第二阶段TC判断无事务出错，通知所有事务提交，否则回滚。在第一到第二阶段过程中，事务一直占有数据库锁，因此性能比较低。但是所有事务要么一起提交，要么一起回滚，所以能实现强一致性。无论是AT模式、TCC还是SAGA，这些模式的提出，都是源于XA规范对某些业务场景无法满足
3.4.3 XA规范
1. 描述了全局事务管理器和局部资源管理器之间的接口。
XA规范的目的是允许多个资源(如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。
2. XA 规范 使用两阶段提交（2PC，Two-Phase Commit）来保证所有资源同时提交或回滚任何特定的事务。
几乎所有的主流数据库都保有对XA规范的支持。
3. 分布式事务DTP模型定义的角色
1 AP：即应用程序。可以理解为使用DTP分布式事务的程序，例如订单服务、库存服务
RM：资源管理器。可以理解为事务的参与者，一般情况下是指一个数据库的实例（MySql。通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
TM：事务管理器。负责协调和管理事务，事务管理器控制着全局事务，管理实务生命周期，并协调各个RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。
4. DTP模式定义TM和RM之间通讯的接口规范叫XA。
- 简单理解为数据库提供的2PC接口协议，基于数据库的XA协议来实现的2PC又称为XA方案。
- 现在有应用程序(AP)持有订单库和库存库，应用程序(AP)通过TM通知订单库(RM)和库存库(RM)，进行扣减库存和生成订单。这个时候RM并没有提交事务，而且锁定资源。
- 当TM收到执行消息，如果有一方RM执行失败，分别向其他RM也发送回滚事务，回滚完毕，释放锁资源
- 当TM收到执行消息，RM全部成功，向所有RM发起提交事务，提交完毕，释放锁资源。
6. 分布式通信协议XA规范，具体执行流程如下所示：
- 第一步：AP创建了RM1,RM2的JDBC连接。
- 第二步：AP通知生成全局事物ID，并把RM1，RM2注册到全局事务ID。
- 第三步：执行二阶段协议中的第一阶段prepare。
- 第四步：根据prepare请求，决定整体提交或回滚。
7. 资源失联导致死锁
但是对于XA而言，如果一个参与全局事务的资源“失联”了，那么就意味着TM收不到分支事务结束的命令。那么它锁定的数据，将会一直被锁定，从而产生死锁。这个也是Seata需要重点解决的问题。
8. 管理分支事务
在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。
执行阶段：
可回滚：业务SQL操作在XA分支中进行，有资源管理器对XA协议的支持来保证可回滚。
持久化：ZA分支完成以后，执行 XA prepare，同样，由资源对XA协议的支持来保证持久化。
-完成阶段：
分支提交：执行XA分支的commit。
分支回滚：执行XA分支的rollback。
3.4.3 XA存在的意义
1. 三大事务无法保证真正的全局一致性
Seata 已经支持了三大事务模式AT\TCC\SAGA，这三个都是补偿型事务。补偿型事务处理你机制构建在 事务资源 之上(要么中间件层面，要么应用层)，事务资源本身对于分布式的事务是无感知的。这种对于分布式事务的无感知存在有一个根本性的问题，无法做到真正的全局一致性。
2. 示例
例如一个库存记录，在补偿型事务处理过程中，用80扣减为60。这个时候仓库管理员查询数据结果，看到的是60。之后因为异常回滚，库存回滚到原来的80。那么这个时候库存管理员看到的60，其实就是脏数据。而这个中间状态就是补偿型事务存在的脏数据。
3. XA满足全局数据的一致性。
和补偿型事务不同，XA协议要求事务资源 本身提供对规范和协议的支持。因为事务资源感知并参与分布式事务处理过程中，所以事务资源可以保证从任意视角对数据的访问有效隔离性，满足全局数据的一致性。
参考博客：https://blog.csdn.net/qq_45738250/article/details/129210294
