分布式事务解决框架Seata之AT模式源码解读

分布式事务解决框架Seata之AT模式源码解读

---

前言

随着微服务架构的发展，传统的单个工程里spring事务已经不能解决所有场景下的数据一致性问题了，引发出了分布式架构下的不同服务之间的数据一致性问题。同时技术也在不断发展，工程师们提出了不同的解决方案：两阶段提交方案、TCC方案、本地消息表方案、可靠性消息最终一致性方案、最大努力通知方案。每一个方案都有自己的优缺点，没有百分之百完美的方案，看是否符合自己公司的业务场景。本文将重点介绍阿里开源的分布式解决框架Seata之AT模式。不会讲怎么引入jar和怎么使用，这个去看其他博客或者官方文档有例子，本文讲解的是springboot整合Seata的过程以及Seata之AT模式的底层原理。

---

一、Springboot整合Seata的过程

为什么引入一个jar和加上一些配置文件或者配置项以及在某些service类的某个方法加上某个注解就拥有了分布式事务解决的能力？这是我们需要思考地，跟springboot整合其他功能一样，都用到了springboot启动器spi的思想和aop埋点的思想。下面是我画的一个引入时序图：

二、Seata之AT模式的底层原理

1.AT模式里的三种角色以及他们是如何协调工作的？

三种角色分别是：
TM:加上@GlobalTransactional注解的方法所在的工程就相当于一个TM,也是seata服务TC的客户端。
RM:各微服务里的本地分支事务（数据库层面上）
TC：seata的服务端，它是一个java项目部署在服务器上，跟tm和rm打交道，网络通信底层用的是netty框架。

2.Seata之AT模式地底层原理

底层原理以及其两阶段的执行过程通过如下时序图进行展示：

通过时序图我们可以知道seata在执行本地事务的时刻也是遵循了JDBC的这一套规划，都是重写了Resource、Connnection、Statement这些接口，进行原有功能的一些改装，目的就是为了引入分布式事务解决方案：比如在第一阶段时，关闭自动提交，准备undolog的时刻带上本地锁，以及在最后提交本地事物之前必须拿到全局锁。还有就是重试自旋的设计比较经典。

3.引入一些发散性思考问题

3.1 为什么需要引入全局锁?没有全局锁会会导致什么样的问题？

3.2 为什么在一阶段执行本地事务时引入重试次数有限地自旋设计？

3.3 为什么要在二阶段执行提交或者回滚时引入无限自旋操作直到成功为止？

---

总结

这里对文章进行总结：
读源码可以让我们了解作者的设计思想和设计经验，同时也会让我们深入理解到此方案的一些不足点。结合本文我们发现seata的AT模式引入了全局锁，所以性能还是有些影响的，不过比XA协议要好，比TCC解决方案性能次之。