实时一致性
在 TCC 模式中，我们会把原来的一个接口分为 Try 接口、Confirm 接口、Cancel 接口。
-
Try 接口用来检查数据、预留业务资源。
-
Confirm 接口用来确认实际业务操作、更新业务资源。
-
Cancel 接口是指释放 Try 接口中预留的资源。
所以 TCC 模式是一个很麻烦的方案，除了每个业务代码的工作量 X3 之外，出错的概率也高，因为我们需要通过相应逻辑保证上面的注意事项都被处理。
06 六、Seata 中 AT 模式的自动回滚
对于使用 Seata 的人来说操作比较简单，只需要在触发整个事务的业务发起方的方法中加入@GlobalTransactional 标注，且使用普通的 @Transactional 包装好分布式事务中相关服务的相关方法即可。
在 Seata 内在机制中，AT 模式的自动回滚往往需要执行以下步骤：
（一）一阶段
-
解析每个服务方法执行的 SQL，记录 SQL 的类型（Update、Insert 或 Delete），修改表并更新 SQL 条件等信息；
-
根据前面的条件信息生成查询语句，并记录修改前的数据镜像；
-
执行业务的 SQL；
-
记录修改后的数据镜像；
-
插入回滚日志：把前后镜像数据及业务 SQL 相关的信息组成一条回滚日志记录，插入 UNDO_LOG 表中；
-
提交前，向 TC 注册分支，并申请相关修改数据行的全局锁 ；
-
本地事务提交：业务数据的更新与前面步骤生成的 UNDO LOG 一并提交；
-
将本地事务提交的结果上报给事务控制器。
收到事务控制器的分支回滚请求后，我们会开启一个本地事务，并执行如下操作：
-
查找相应的 UNDO LOG 记录；
-
数据校验：拿 UNDO LOG 中的后镜像数据与当前数据进行对比，如果存在不同，说明数据被当前全局事务之外的动作做了修改，此时我们需要根据配置策略进行处理；
-
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成回滚语句并执行；
-
提交本地事务，并把本地事务的执行结果（即分支事务回滚的结果）上报事务控制器。
-
收到事务控制器的分支提交请求后，我们会将请求放入一个异步任务队列中，并马上返回提交成功的结果给事务控制器。
-
异步任务阶段的分支提交请求将异步地、批量地删除相应 UNDO LOG 记录。
推荐阅读：
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69949806/viewspace-2902748/ ，如需转载，请注明出处，否则将追究法律责任。
