对于Seata的内在机制，AT模式的自动回滚往往需要执行以下步骤（分为3个阶段） 。
阶段1
1）解析每个服务方法执行的SQL，记录SQL的类型（Update、Insert或Delete），修改表并更新SQL条件等信息 。
2）根据前面的条件信息生成查询语句，并记录修改前的数据镜像 。
3）执行业务的SQL 。4）记录修改后的数据镜像 。
5）插入回滚日志：把前后镜像数据及业务SQL相关的信息组成一条回滚日志记录，插入UNDOLOG表中 。
6）提交前，向TC注册分支，并申请相关修改数据行的全局锁 。
7）本地事务提交：业务数据的更新与前面步骤生成的UNDOLOG一并提交 。
8）将本地事务提交的结果上报给事务控制器 。
阶段2
收到事务控制器的分支回滚请求后，开启一个本地事务，执行如下操作 。
1）查找相应的UNDOLOG记录 。
2）数据校验：将UNDOLOG中的后镜像数据与当前数据进行对比，如果存在不同，说明数据被当前全局事务之外的动作做了修改，此时需要根据配置策略进行处理 。
3）根据UNDOLOG中的前镜像数据和业务SQL的相关信息生成回滚语句并执行 。
4）提交本地事务，并把本地事务的执行结果（即分支事务回滚的结果）上报事务控制器 。
阶段3
1）收到事务控制器的分支提交请求后，将请求放入一个异步任务队列
中，并马上返回提交成功的结果给事务控制器 。
2）异步任务阶段的分支提交请求将异步、批量地删除相应的UNDOLOG记录 。
以上就是Seata AT模式的简单介绍 。
尝试Seata
当时，虽然Seata还没有更新到1.0，且官方也不推荐线上使用，但是项目组最终还是使用了它，原因如下 。
1）因为实时一致性的场景很少，而且发生频率低，所以并不会大规模使用，影响面在可控范围内 。如果实时一致性的场景发生频率高，并发量就高，业务人员对性能的要求也高，此时就会与业务沟通，采用最终一致性的方案 。
2）Seata AT模式与TCC模式相比，只有增加一个@GlobalTransactional的工作量，因此两者的工作量相差很多，也就是说，对项目组来说，投入产出比更高，值得冒险 。这可能也是Seata发展很快的原因之一 。
虽然Seata AT模式有些小缺陷，但是瑕不掩瑜 。
小结
最终一致性与实时一致性的解决方案设计完成后，不仅没有给业务开发人员带来额外工作量，也没有影响业务项目进度的日常推进，还大大减少了数据不一致的出现概率，因此数据不一致的痛点得到了较大缓解 。
【微服务进阶场景实战：最终一致性与实时一致性解决方案如何设计？】
推荐阅读
- 自己想要开发微信小程序其实也不难
- 微信背景视频怎么设置？
- 为什么微信状态会消失？
- 微信状态怎么打字？
- 微信8.0状态视频别人能看到吗？
- 微信8.0状态背景视频怎么设置？
- 微信8.0状态可以持续多久？
- 微博id在哪里查看？
- 微波炉可以用的容器有哪些？
- 塑料盒能在微波炉加热吗？