Seata 分布式事务控制

本文主要是介绍Seata 分布式事务控制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

概述

Seata 是阿里巴巴和蚂蚁集团内部开发了分布式事务中间件，用于解决电商、支付、物流等业务场景中应用数据的一致性问题，2023 年 10 月，为了更好的通过社区驱动技术的演进，阿里和蚂蚁集团正式将 Seata 捐赠给 Apache 基金会。

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

一. Seata 核心组件

1. TC 事务协调器

TC (Transaction Coordinator) 维护全局和分支事务的状态，驱动全局事务提交或回滚。

2. TM 事务管理器

TM (Transaction Manager) 定义全局事务的范围：开始全局事务、提交或回滚全局事务。

3. RM 资源管理器

RM (Resource Manager) 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

二. Seata 事务模式

1. Seata 定义了全局事务的框架，全局事务定义为若干分支事务的整体协调：

TM 向 TC 请求发起（Begin）、提交（Commit）、回滚（Rollback）全局事务
TM 把代表全局事务的 XID 绑定到分支事务上
RM 向 TC 注册，把分支事务关联到 XID 代表的全局事务中
RM 把分支事务的执行结果上报给 TC（可选）
TC 发送分支提交（Branch Commit）或分支回滚（Branch Rollback）命令给 RM

2. Seata 的全局事务处理过程，分为两个阶段：

执行阶段：
执行分支事务，并保证执行结果满足是可回滚的（Rollbackable）和持久化的（Durable）。
完成阶段：
根据执行阶段结果形成的决议，应用通过 TM 发出的全局提交或回滚的请求给 TC， TC 命令 RM 驱动分支事务进行 Commit 或 Rollback。

3. Seata 所谓事务模式是指：

运行在 Seata 全局事务框架下的分支事务的行为模式。准确地讲，应该叫作分支事务模式。不同的事务模式区别在于分支事务使用不同的方式达到全局事务两个阶段的目标。即，回答以下两个问题：执行阶段：如何执行并保证执行结果满足是可回滚的（Rollbackable）和持久化的（Durable）。完成阶段：收到 TC 的命令后，做到事务的回滚/提交

三. Seata 四种事务模式

1. AT 模式：

这是一种无侵入的分布式事务解决方案。用户只需关注自己的业务 SQL，Seata 框架会自动生成事务的二阶段提交和回滚操作。在一阶段，Seata 会拦截业务 SQL，解析 SQL 语义，找到要更新的业务数据，并保存快照数据和行锁。二阶段如果是提交，Seata 只需清理数据；如果是回滚，则用快照数据还原业务数据。

使用场景：

原理：基于二阶段提交协议（2PC）的变种，通过记录数据的全局锁、前镜像和后镜像来实现分布式事务。
第一阶段：是本地事务的执行和准备提交，记录数据快照；
第二阶段：是根据一阶段的结果来决定是提交还是回滚。AT模式避免了全局锁和阻塞的问题，从而提高了系统的并发性能。
在AT模式中：参与者的本地事务执行成功后即可提交，而不需要等待其他参与者的状态。AT模式需要配合数据库的undo_log数据表一起实现。

适用场景：适用于对数据一致性要求较高，且业务操作可以容忍一定延迟的场景。
主要区别：代码侵入性低，实现复杂度相对较低，性能优于XA模式，主要用于替代XA模式的场景。
启用配置：

添加配置：seata:data-source-proxy-mode: AT
在需要分布式事务的业务代码上添加注解@GlobalTransactional

2. TCC 模式：

TCC（Try-Confirm-Cancel）模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作。Try 阶段是资源的检测和预留；Confirm 阶段执行业务操作提交；Cancel 阶段是预留资源释放。

主要原理：

基于补偿事务的思想，分为三个操作阶段：尝试（Try）、确认（Confirm）、取消（Cancel）。每个业务操作都需要实现这三个操作，以确保分布式事务的最终一致性。

适用场景：

适用于业务逻辑较为复杂，要求较高的业务处理流程。需要开发者针对每个业务操作，明确实现Try、Confirm和Cancel三个方法；还需要需要考虑Confirm和Cancel的失败情况下做好幂等处理。

主要区别：

相较于AT模式，TCC模式对业务侵入性更高，需要开发者明确定义补偿逻辑，但它提供了更高的灵活性和性能。

3. Saga 模式：

Saga 模式适用于长事务，由事件驱动，各个参与者之间异步执行。如果任何一个正向操作执行失败，Saga 模式会执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

主要原理：

通过长事务来维护各个微服务之间的数据一致性。Saga 分为多个子事务，每个子事务执行完成后都会发布事件，触发下一个子事务，如果某个子事务失败，则执行补偿操作以回滚之前的操作。
Saga模式的执行过程如下：
执行正向操作：按照事务的逻辑顺序，依次执行正向操作。每个正向操作都会记录事务的执行状态。如果所有的正向操作都成功执行，则事务提交完成。如果某个正向操作失败，将会触发相应的补偿操作。补偿操作会撤销或修复正向操作的影响。
执行补偿操作：按照逆序依次执行已经触发的补偿操作。补偿操作应该具备幂等性，以便可以多次执行而不会造成副作用。如果所有的补偿操作都成功执行，则事务回滚完成。如果补偿操作也失败，需要人工介入或其他手段来解决事务的一致性问题。

适用场景：

适用于长事务场景，特别是那些无法使用TCC或AT模式的场景。

主要区别：

Saga 模式通过定义一系列的本地事务和补偿操作来保证整体事务的一致性，适合于长事务处理。与TCC相比，Saga模式可能会有更长的事务持续时间，但对业务的侵入性较小。

4. XA 模式：

XA 模式是 Seata 支持的另一种分布式事务解决方案，它利用事务资源对 XA 协议的支持，以 XA 协议的机制来管理分支事务。XA 模式是两阶段提交协议，通过资源管理器和事务协调者来保证事务的原子性。

主要原理：

基于XA接口的分布式事务实现，遵循两阶段提交协议。XA模式通过资源管理器（RM）、事务管理器（TM）和应用程序（AP）三者的协作，完成分布式事务的管理。从编程模型上，XA 模式与 AT 模式保持完全一致。只需要修改数据源代理，即可实现 XA 模式与 AT 模式之间的切换。

适用场景：

适用于需要严格遵守ACID原则的分布式事务管理场景。

主要区别：

XA是一种较为传统的解决方案，支持严格的ACID事务，但性能较低，资源消耗较大。

代码配置：

添加配置 seata:data-source-proxy-mode: XA
在需要分布式事务的业务代码上添加注解 @GlobalTransactional