分布式事务(二)：Seata概述
Seata官方文档地址：https://seata.apache.org/zh-cn/。
1、Seata引入
用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：
仓储服务：对给定的商品扣除仓储数量。
订单服务：根据采购需求创建订单。
帐户服务：从用户帐户中扣除余额。
在上述架构图中有仓储服务、订单服务、账户服务，用户购买商品时，每个服务内部数据一致性可由本地事务来保证，全局数据的一致性问题就需要用Seata来解决。
2、什么是Seata
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
3、Seata的核心概念
Seata分TC、TM和RM三个角色，TC（Server端）为单独服务端部署，TM和RM（Client端）由业务系统集成。
3.1、TM - 事务管理器（事务创建）
TM (Transaction Manager) - 事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。
用于创建和决议事务结果的实体，一般集成于业务调用链路的上游。
3.2、RM - 资源管理器（分支事务）
RM (Resource Manager) - 资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
其中，TC为单独部署的Server服务端，TM 和 RM 为嵌入到应用中的Client客户端。
用于管理资源的实体，一般情况下等同于微服务中的提供方(provider)，管理其所在服务中的资源，如数据库资源等。
3.3、TC - 事务协调者（事务决议）
TC (Transaction Coordinator) - 事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。
Seata 中用于2pc方式的事务模式统一协调事务的实体(SAGA除外),其可由事务管理者驱动或自身驱动进行事务的二阶段行为.
3.3.1、Commit
Seata 中当事务管理器决议为提交时,TC才会进行对事务的二阶段提交行为下发,如TCC模式中的confirm,AT模式的undolog delete,XA模式的XA Commit。
3.3.2、Rollback
Seata 中当事务管理器决议为回滚时,TC会进行对事务的二阶段回滚行为下发,如TCC模式中的cancel,AT模式的undo,XA模式的XA Rollback。
3.3.3、TimeoutRollback
Seata 中当事务管理器创建事务时指定的Timeout时间到达后还未决议时,TC会主动将已超时的事务进行超时回滚,其超时行为等同上述Rollback行为。
4、分布式事务生命周期
· TM 请求 TC 开启一个全局事务。TC 会生成一个 XID 作为该全局事务的编号
XID，会在微服务的调用链路中传播，保证多个微服务的子事务关联在一起
· RM 请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联
· TM 请求 TC 告诉 XID 对应的全局事务是进行提交还是回滚
· TC 驱动 RM 们将 XID 对应的自己的本地事务进行提交还是回滚
5、Seata的事务模式
5.1、AT模式
AT模式是一非侵入式的分布式事务解决方案，Seata在内部做了对数据库操作的代理层。使用Seata AT模式实际上用的是Seata自带的数据源代理 DataSourceProxy，Seata在这层代理中加入了很多逻辑，比如插入回滚undo_log日志、检查全局锁等。
AT模式 提供无侵入自动补偿的事务模式，目前已支持MySQL、Oracle、PostgreSQL、TiDB、MariaDB、DaMeng、SQLServer。
5.1.1、整体机制
两阶段提交协议：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：提交异步化，非常快速地完成；回滚通过一阶段的回滚日志进行反向补偿。
5.1.2、基于数据库实现
AT模式基于 支持本地 ACID 事务的关系型数据库：
一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录
二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志
三阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚
5.2、TCC模式
一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自身的两阶段。
|
阶段一
|
prepare 行为
|
|
阶段二
|
commit 或 rollback 行为
|
原理图如下：
根据两阶段行为模式的不同，分支事务可划分为 Automatic (Branch) Transaction Mode 和 TCC (Branch) Transaction Mode。
5.2.1、TCC模式
TCC 模式，不依赖于底层数据资源的事务支持。
一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
二阶段 commit 行为：调用 自定义 的 commit 逻辑。
二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
5.2.2、优缺点
优势：TCC完全不依赖底层数据库，能够实现跨数据库、跨应用资源管理，可以提供给业务方更细粒度的控制；
缺点：TCC是一种侵入式的分布式事务解决方案，需要业务系统自行实现 Try、Confirm、Cancel 三个操作，对业务系统有着非常大的入侵性，设计相对复杂。
5.2.3、使用场景
TCC模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
5.2.4、TCC模式整体机制
在两阶段提交协议中，资源管理器（RM，Resource Manager）需要提供 prepare、commit 和 rollback 三个操作；而事务管理器（TM，Transaction Manager）分两阶段协调所有资源管理器，在第一阶段询问所有资源管理器 prepare 是否成功，若所有资源均 prepare 成功则在第二阶段执行所有资源的 commit 操作，否则在第二阶段执行所有资源的 rollback 操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。
TCC是资源管理器的一种服务化的实现，TCC是一种比较成熟的分布式事务解决方案，可以用于解决跨数据库、跨服务业务操作的数据一致性问题。TCC其 Try、Confirm、Cancel 三个方法均由业务编码实现，所以 TCC 可以被称为是服务化的资源管理器。
TCC的 Try 操作作为一阶段，负责资源的检查和预留；Confirm 操作作为二阶段提交操作，执行真正的业务；Cancel 是二阶段回滚操作，执行预留资源的取消，使资源回到初始状态。
5.3、Saga模式
为长事务提供有效的解决方案，提供编排式与注解式。
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
5.3.1、适用场景
业务流程长、业务流程多；
参与者包含其他公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
5.3.2、优缺点
缺点：不保证隔离性
优点：一阶段提交本地事务，无锁，高性能；事件驱动架构，参与者可异步执行，高吞吐；补偿服务易于实现
5.3.3、Saga的实现
基于状态机引擎的Saga实现，目前SEATA提供的Saga模式是基于状态机引擎来实现的，整体机制如下：
1、通过状态图来定义服务调用的流程并生成json状态语言定义文件
2、状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
3、状态图json由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚。（异常发生时是否进行补偿也可由用户自定义决定）
4、可以实现服务编排需求，支持单向选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能。
5.4、XA模式
支持已实现XA接口的数据库XA模式，目前已支持MySQL、Oracle和MariaDB。
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。
5.4.1、优缺点
优点 => 与 Seata 支持的其他事务模式不同，XA协议要求事务资源本身提供对规范和协议的支持，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。此外的一些优势还包括：1、业务无侵入：和 AT 一样，XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担；2、数据库的支持广泛：XA协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。
缺点 => 使用于想要迁移到 Seata 平台基于 XA 协议的老应用，使用 XA 模式将更平滑，还有 AT 模式未适配的数据库应用。
