一文简要概述Seata AT与TCC的区别

AT与TCC的比较

首先，先了解一下Seata分布式事务的工作原理（见下图）

Seata分布式事务

我们可以将Seata分布式事务的参与角色分为三个：TC（事务协调者，即Seata-Server），TM（事务管理器），RM（资源管理器）。了解完参与角色之后，我们还需要先了解下每个角色在分布式事务中负责的内容

各个角色职责

此处为各个角色职责的简要介绍

• TC：事务协调者，负责事务的协调，根据TM最后的指令决定提交/回滚全局事务

• TM：事务管理器，负责开启全局事务，调用其他的RM资源以及通知TC是要提交/回滚全局事务

• RM：资源管理器，负责管理分支事务设计到的资源（即不属于TC本地事务中，但属于全局事务中的那部分资源）

介绍完各个角色职责后，我们回到之前的Seata分布式事务的工作原理中，AT与TCC都遵循两阶段提交协议，并在此基础上进行了演变。

Seata两阶段提交协议

在Seata分布式事务中，两阶段可以分为以下的两阶段

• 一阶段（prepare）：资源准备阶段

• 二阶段（commit/rollback）：根据全局事务执行的结果，将一阶段冻结的资源提交或回滚

那么，参照一开始的图片及Seata两阶段的流程，我们便可以简要的概括Seata它到底是怎么执行的了：

此处摘抄Seata官网的执行流程

1. TM asks TC to begin a new global transaction. TC generates an XID representing the global transaction.

2. XID is propagated through microservices' invoke chain.

3. RM registers local transaction as a branch of the corresponding global transaction of XID to TC.

4. TM asks TC for committing or rollbacking the corresponding global transaction of XID.

5. TC drives all branch transactions under the corresponding global transaction of XID to finish branch committing or rollbacking.

翻译成中文并加一些自己的理解

1. TM向TC请求开启全局事务，TC生成一个XID代表此次全局事务并返回给TM

2. XID会在微服务的调用链传递

3. RM将本地事务作为一个分支，通过XID注册到全局事务中，有TC来负责协调该分支

4. TM通过XID来告诉TC去提交/回滚该XID绑定的全局事务

5. TC通过XID找到对应的每一个分支事务，去协调RM去提交/回滚每个分支事务（此处的分支事务不是刚刚一阶段的本地事务，而是TM角度上的一个全局事务try+commit/cancel）

那么，回到最开始的话题，AT模式和TCC模式到底有什么区别呢？

官网有一段关于两种模式比较的描述：

AT 模式基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。

• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。

• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。

• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。

• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

另外，我也自己总结了一份我认为这两种模式的差别点（具体差别点导致的原因，留到后续再进行讨论）

	AT	TCC
全局锁	需要	不需要
回滚日志	需要	不需要
commit/cancel阶段代码实现	不需要	需要
是否需要开发者解决悬挂和空回滚问题	不需要	需要
性能	低（需要全局锁导致）	高（无锁）