分布式事务Seata

一、概述

     Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 AT模式是阿里首推的模式 ，阿里云上有商用版本的GTS（Global Transaction Service 全局事务服务）

二、工作流程

在 Seata 的架构中，一共有三个角色：

TC ：事务协调者 ，全称为 Transaction Coordinator，实际上指全局事务的发起者，维护全局和分支事务的状态，驱动全局事务提交或回滚。

RM ：资源管理器 全称为 Resource Manager,实际上一个全局事务中的各个本地事务，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

TM ：事务管理器，全称为 Transaction Manager，实际上指Seata服务器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。

工作流程图如下：

        如上图所示，在 Seata 中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。 一个分布式事务的生命周期如下：

1. TM 请求 TC 开启一个全局事务。TC 会生成一个 XID 作为该全局事务的编号。XID会在微服务的调用链路中传播，保证将多个微服务的子事务关联在一起。
2. RM 请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联。
3. TM 请求 TC 告诉 XID 对应的全局事务是进行提交还是回滚。
4. TC 驱动 RM 们将 XID 对应的自己的本地事务进行提交还是回滚。

三、工作模式

3.1 AT模式

Seata AT模式的设计思路

       Seata AT模式的核心是对业务无侵入，是一种改进后的两阶段提交。它本身依赖于数据库的事务实现，它也是 Seata 默认的工作模式。它的本质是在本地事务分支提交的同时，用一张数据库表记录对应的undo日志记录(此undo日志非mysql的undo日志)。在回滚阶段采用这条回滚日志记录进行反向补偿。

      其设计思路如下:

一阶段： 先要在各个本地事务相关的数据库中分别创建一张相同的undo日志记录表。在本地事务提交的同时记录本地事务操作对应的undo日志记录，同时还要释放本地锁和连接资源。

二阶段：事务协调者在通知各个资源管理器做相应的事务处理，具体表现为：如果事务是提交，则删除对应的undo记录即可。如果是回滚，则根据undo记录做相应的反向补偿操作。这个过程是异步进行的，效率较高。

3.1 TCC模式

      TCC 也是基于二阶段提交事务的实现，它的全称为 Try-Confirm-Cancel，即资源预留 （Try）、确认操作（Confirm）、取消操作（Cancel），他们的具体含义如下：

1. Try：对业务资源的检查并预留；

2. Confirm：对业务处理进行提交，即 commit 操作，只要 Try 成功，那么该步骤一定成功；

3. Cancel：对业务处理进行取消，即回滚操作，该步骤回对 Try 预留的资源进行释放。

     

     TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的入侵性，设计相对复杂，但优点是 TCC 完全不依赖数据库，能够实现跨数据库、跨应用资源管理，对这些不同数据访问通过侵入式的编码方式实现一个原子操作，更好地解决了在各种复杂业务场景下的分布式事务问题。它的特点即：复杂而灵活。