在 Seata 项目中，最早由阿里巴巴中间件开源出的 AT 模式（Automatic Transaction） 是一套创新的、业务无侵入的分布式事务解决方案。
个人理解AT模式就是你只需要编写正常的业务逻辑,然后提交或者是回滚由Seata给你解决,如果是回滚的话,Seata会执行一个逆向的SQL给你把操作的数据补偿回来.
AT模式是基于XA二阶段提交演变过来的
AT 模式就是两阶段提交，两阶段提交有同步阻塞的问题，效率太低了.
AT 的一阶段直接就把事务提交了，直接释放了本地锁，这么草率直接提交的嘛？当然不是，这里和本地消息表有点类似，就是利用本地事务，执行真正的事务操作中还会插入回滚日志，然后在一个事务中提交。
这回滚日志怎么来的？
通过框架代理 JDBC 的一些类，在执行 SQL 的时候解析 SQL 得到执行前的数据镜像，然后执行 SQL ，再得到执行后的数据镜像，然后把这些数据组装成回滚日志。
再伴随的这个本地事务的提交把回滚日志也插入到数据库的 UNDO_LOG 表中(所以数据库需要有一张UNDO_LOG 表)。
这波操作下来在一阶段就可以没有后顾之忧的提交事务了。
然后一阶段如果成功，那么二阶段可以异步的删除那些回滚日志，如果一阶段失败那么可以通过回滚日志来反向补偿恢复。
这时候有细心的同学想到了，万一中间有人改了这条数据怎么办？你这镜像就不对了啊？
所以说还有个全局锁的概念，在事务提交前需要拿到全局锁（可以理解为对这条数据的锁），然后才能顺利提交本地事务。
如果一直拿不到那就需要回滚本地事务了。
和 XA 的关系
前面一直拿 AT 和 XA 做比较。
这里特别说明一下，并不是说 XA 协议本身有问题，只是说在某些场景的需求下，基于 XA 做不理想。
但同样，另外还有一些对内外部 一致性要求非常高 的场景，可能 XA 又是非常适合，甚至必需的。
这也是接下来 Seata 将提供 XA 模式的原因。
AT模式优点
- 低成本： 编程模型 不变，轻依赖 不需要为分布式事务场景做特定设计，业务像搭积木一样自然地构建成长。
- 高性能：协议 不阻塞；资源释放快，保证业务的吞吐。
- 高可用：极端的异常情况下，可以暂时 跳过异常事务，保证整个业务系统的高可用
详情参考:
若有收获，就点个赞吧
0 人点赞
