Seata-AT模式案例分享

• AT模式

在上次说到Seata的三个组成部分 TM、RM、TC。可以简单的分配下角色

TM相当于业务代码逻辑、RM相当于持久层的JDBC数据库、TC就是seata单独部署的客户端。

AT 说到底就是实现对资源操作的代理，并记录原先 & 变更后的状态，并用锁保证该数据的隔离性。在调用链中出现异常时，还原所有分支数据，达到分布式事务下的“原子性”。

而AT模式下 的执行流程

1. TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
2. 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
3. TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
4. TC 汇总事务信息，决定分布式事务是提交还是回滚；
5. TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。

• 使用方式

相比于TCC的使用方式，在nacos上AT配置是一样的，区别在于TM（业务代码部分）,

业务数据库需要插入一张undo_log的表用于回滚数据或者提交。

对比起来

在数据库

AT 整个业务库只需要一张undo_log表

TCC 需要表里有预留字段

在代码上

AT 只需要使用一个GlobalTransactional 注解，就可以了

TCC 则需要手动去写 二阶段的提交、回滚操作

性能上

AT 低（需要全局锁）

TCC 高 （无锁）

• 缺点

1. Seata没有一个可视化的界面，没有控制台，无法人工干预
2. TC客户端，如果客户端挂了，那整个业务也无法进行，需要弄成集群（维护成本高）
3. 如果一阶段操作的数据多且大的话，那么undo_log 表也会很大，可能造成资源不足，入库缓慢

• 代码实践

参考：

Seata-AT 如何保证分布式事务一致性【图文】_阿里巴巴云原生_51CTO博客

http://doc.ruoyi.vip/ruoyi-cloud/cloud/seata.html#domain