Seata学习笔记
目录
Seata的三大角色
角色
相关流程
相关事务模式
AT 模式（默认模式）
概述
整体机制
分析
XA 模式
概述
机制
分析
TCC 模式
概述
机制
分析
SAGA 模式
概述
机制
分析
参考：
Seata的三大角色
角色
TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
相关流程
1、TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
2、XID 在微服务调用链路的上下文中传播；
3、RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖；
4、TM 向 TC 发起针对 XID 的全局提交或回滚决议；
5、TC调度XID下管辖的全部分支事务完成提交或回滚请求。
相关事务模式
AT 模式（默认模式）
概述
AT 模式是 Seata 创新的一种非侵入式的分布式事务解决方案，Seata 在内部做了对数据库操作的代理层，我们使用 Seata AT 模式时，实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，比如插入回滚 undo_log 日志，检查全局锁等。
整体机制
- 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
- 二阶段：
- 提交异步化，非常快速地完成。
- 回滚通过一阶段的回滚日志进行反向补偿。
分析
解决了 XA 模式中锁占用时间过长的问题。它的主要特点是简单无侵入，强一致，学习成本低。缺点是需要遵守一定的开发规约，它并不是对所有的 SQL 类型都支持，有一定的使用限制。适用于通用的业务场景，但它并不适用与热点数据的高并发场景。需要额外的undo_log表
优点：简单、无业务侵入、事务强一致性、学习成本低、性能高于XA模式
缺点：需要数据库的支持、遵循一定的开发规范（Java应用、通过JDBC访问数据库）
适用场景：不适合用于连接的数据库不支持（本地事务）
XA 模式
概述
XA 模式是从 1.2 版本支持的事务模式。XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。
机制
- 执行阶段：
- 可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证 可回滚
- 持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证 持久化（即，之后任何意外都不会造成无法回滚的情况）
- 完成阶段：
- 分支提交：执行 XA 分支的 commit
- 分支回滚：执行 XA 分支的 rollback
分析
性能相比其他事务要差一点，但能保证最严格的数据一致性。XA 模式需要设置串行化隔离级别，相当于对数据添加了读写锁。另外连接资源需要在整个事务期间保持，这样可能会导致资源锁定问题，从而影响并发事务吞吐。
优点：实现简单、无业务侵入
缺点：性能差、必须实现 XA 协议、容易产生死锁；
XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，性能差。
适用场景：隔离级别要求高，强一致性分阶段事务模型，牺牲了一定的可用性（保证了强一致性）
TCC 模式
概述
TCC 模式是 Seata 支持的一种由业务方细粒度控制的侵入式分布式事务解决方案，是继 AT 模式后第二种支持的事务模式，最早由蚂蚁金服贡献。其分布式事务模型直接作用于服务层，不依赖底层数据库，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。
机制
在两阶段提交协议中，资源管理器（RM, Resource Manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, Transaction Manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。
资源管理器有很多实现方式，其中 TCC（Try-Confirm-Cancel）是资源管理器的一种服务化的实现；TCC 是一种比较成熟的分布式事务解决方案，可用于解决跨数据库、跨服务业务操作的数据一致性问题；TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现，故 TCC 可以被称为是服务化的资源管理器。
TCC 的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。
分析
一阶段 prepare 行为：调用自定义的 prepare 逻辑。
二阶段 commit 行为：调用自定义的 commit 逻辑。
二阶段 rollback 行为：调用自定义的 rollback 逻辑。
优点：灵活、性能高（不依赖全局锁、不需要生产快照）、不依赖数据库事务。
缺点：业务侵入大、实现难度高、事务最终一致性（不是强一致性）。
使用场景：连接的数据库不支持（本地）事务。
SAGA 模式
概述
Saga 模式是 SEATA 提供的长事务解决方案，在 Saga 模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
机制
- 通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
- 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
- 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚
注意: 异常发生时是否进行补偿也可由用户自定义决定
- 可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能
分析
业务层面的分布式解决方案。一个基于长事务的解决方案，Saga 模式解决的是在没有二阶段提交的情况下解决分布式事务。它的核心思想是将一个业务流程中的长事务拆分成多个本地短事务，当其中一个参与者的事务执行失败，则通过补偿机制补偿给前面已经执行成功的参与者。
优点：灵活、性能高、可异步化
缺点：无锁、不保证隔离性、业务侵入大
使用场景：长事务。
参考：
Seata官网
Seata 入门与实战-CSDN博客