- AT模式
在上次说到Seata的三个组成部分 TM、RM、TC。可以简单的分配下角色
TM相当于业务代码逻辑、RM相当于持久层的JDBC数据库、TC就是seata单独部署的客户端。
AT 说到底就是实现对资源操作的代理，并记录原先 & 变更后的状态，并用锁保证该数据的隔离性。在调用链中出现异常时，还原所有分支数据，达到分布式事务下的“原子性”。
而AT模式下 的执行流程
- TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
- 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
- TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
- TC 汇总事务信息，决定分布式事务是提交还是回滚；
- TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。
- 使用方式
相比于TCC的使用方式，在nacos上AT配置是一样的，区别在于TM（业务代码部分）,
业务数据库需要插入一张undo_log的表用于回滚数据或者提交。
对比起来
在数据库
AT 整个业务库只需要一张undo_log表
TCC 需要表里有预留字段
在代码上
AT 只需要使用一个GlobalTransactional 注解，就可以了
TCC 则需要手动去写 二阶段的提交、回滚操作
性能上
AT 低（需要全局锁）
TCC 高 （无锁）
- 缺点
- Seata没有一个可视化的界面，没有控制台，无法人工干预
- TC客户端，如果客户端挂了，那整个业务也无法进行，需要弄成集群（维护成本高）
- 如果一阶段操作的数据多且大的话，那么undo_log 表也会很大，可能造成资源不足，入库缓慢
- 代码实践
参考：
Seata-AT 如何保证分布式事务一致性【图文】_阿里巴巴云原生_51CTO博客
http://doc.ruoyi.vip/ruoyi-cloud/cloud/seata.html#domain
