Seata 1.5.2 源码学习

文章有点长，我决定用半个小时来和你分享~😂 废话不多说，上代码。。。

​基于Seata 1.5.2，项目中用 seata-spring-boot-starter

SeataDataSourceAutoConfiguration

SeataDataSourceAutoConfiguration 主要是配置数据源自动代理，可以看到：

1. 默认seata.enabled、seata.enableAutoDataSourceProxy、seata.enable-auto-data-source-proxy都是true
2. 只有当classpath中有DataSource时才会进行此配置
3. 创建了一个SeataAutoDataSourceProxyCreator，用于自动代理数据源

先记一下，SeataAutoDataSourceProxyCreator是一个BeanPostProcessor

​刚才new了一个SeataAutoDataSourceProxyCreator，继续看构造方法，默认useJdkProxy是false，excludes为空，dataSourceProxyMode是AT

构造方法中最重要的一件事情是构造AOP通知（拦截器），这里new了一个SeataAutoDataSourceProxyAdvice

SeataAutoDataSourceProxyAdvice是一个MethodInterceptor。

​MethodInterceptor是aop中的一个接口，当目标方法被调用时就会调用与之关联的MethodInterceptor的invoke方法

至此，在构造方法中完成了advisors的赋值，advisors[]中有一个DefaultIntroductionAdvisor，DefaultIntroductionAdvisor中引用了SeataAutoDataSourceProxyAdvice

​前面说过，SeataAutoDataSourceProxyCreator是一个BeanPostProcessor，而BeanPostProcessor是BeanFactory中的一个钩子（回调），称之为后置处理器

AbstractAutoProxyCreator#postProcessBeforeInstantiation()

AbstractAutoProxyCreator#postProcessAfterInitialization()

AbstractAutoProxyCreator#wrapIfNecessary()

AbstractAutoProxyCreator#getAdvicesAndAdvisorsForBean()

SeataAutoDataSourceProxyCreator#getAdvicesAndAdvisorsForBean()

SeataAutoDataSourceProxyCreator#wrapIfNecessary()

DataSourceProxyHolder维护了数据源对象与数据源代理对象的映射

至此，数据源代理部分就看完了，下面总结一下：

1. ​启动的时候自动配置数据源代理，创建了一个SeataAutoDataSourceProxyCreator
2. ​SeataAutoDataSourceProxyCreator在构造方法中创建AOP通知，并赋值给其属性
3. ​AbstractAutoProxyCreator是一个抽象类不能被实例化，能实例化的只有SeataAutoDataSourceProxyCreator
4. ​SeataAutoDataSourceProxyCreator从AbstractAutoProxyCreator那里继承了很多属性和方法，其中就包括postProcessBeforeInstantiation()、postProcessAfterInitialization()、createProxy()等等
5. ​SeataAutoDataSourceProxyCreator间接实现了BeanPostProcessor接口，也就是说它也是BeanPostProcessor的一个实现类
6. ​BeanFactory回调所有的BeanPostProcessor#postProcessAfterInitialization()时，就会调用SeataAutoDataSourceProxyCreator的postProcessAfterInitialization()方法，最终会调用wrapIfNecessary()方法
7. ​wrapIfNecessary()只关心DataSource对象，它负责为DataSource对象生成代理对象，并且在SeataAutoDataSourceProxyCreator中维护了DataSource对象与SeataDataSourceProxy对象之间的映射关心
8. ​创建代理对象时，会给DataSource对象应用AOP拦截器。用AOP的话来讲，就是给目标对象DataSource织入通知，并创建一个被增强的代理对象
9. ​通知（拦截器）是SeataAutoDataSourceProxyAdvice，它实现了MethodInterceptor接口
10. ​SeataAutoDataSourceProxyAdvice#invoke()方法所做的事情就是，拿到原始DataSource的代理对象，并且在代理对象上调用目标方法​

​综上所述，以上做的所有工作都是为了将来调用 javax.sql.DataSource 上的任意方法时都会被拦截，然后调用其代理对象上对应的方法。而DataSource中最重要的一个方法就是getConnection()

​划重点：将来，所有调用 javax.sql.DataSource#getConnection() 都会被拦截，然后在代理对象上执行getConnection()，因此可以这样说

调 javax.sql.DataSource#getConnection() 实际上执行的是 io.seata.rm.datasource.SeataDataSourceProxy#getConnection()，AT模式下返回的是DataSourceProxy

​SeataAutoConfiguration

​SeataAutoConfiguration里面主要是配置GlobalTransactionScanner（全局事务扫描器）

​seata.enabled=true 才会开启 SeataAutoConfiguration

​GlobalTransactionScanner 也继承自 AbstractAutoProxyCreator，同时还实现了InitializingBean接口。BeanFactory在设置了所有bean属性之后会调用InitializingBean的afterPropertiesSet()方法

​GlobalTransactionScanner#afterPropertiesSet()

io.seata.common.DefaultValues中定义了很多默认值

同样地，因为实现了BeanPostProcessor接口，所以在启动时BeanFactory实例化Bean之后，会调用GlobalTransactionScanner的postProcessAfterInitialization()，尽管这个postProcessAfterInitialization()方法时从AbstractAutoProxyCreator那里继承来的，但是不影响啊，还是会调用GlobalTransactionScanner这个bean的postProcessAfterInitialization()方法。于是，最终又会调wrapIfNecessary()方法。

​GlobalTransactionScanner#wrapIfNecessary()

这里面有一个很重要的逻辑就是，创建了一个GlobalTransactionalInterceptor对象，并赋值给interceptor

​AbstractAutoProxyCreator#getAdvicesAndAdvisorsForBean()是一个抽象方法，实现在子类GlobalTransactionScanner中

因此，所有在GlobalTransactionScanner#wrapIfNecessary()中被代理的对象，都被应用GlobalTransactionalInterceptor

​GlobalTransactionalInterceptor也是一个MethodInterceptor

​也就是说，目标方法的调用都会转到GlobalTransactionalInterceptor#invoke()上

GlobalTransactionalInterceptor#handleGlobalTransaction()

事务执行直接调用TransactionalTemplate的execute()方法

​io.seata.tm.api.TransactionalTemplate#execute()

io.seata.tm.api.GlobalTransactionContext#getCurrent() 获取当前事务

io.seata.tm.api.TransactionalTemplate#beginTransaction()

tx是DefaultGlobalTransaction

​io.seata.tm.api.DefaultGlobalTransaction#begin()

​DefaultGlobalTransaction中的TransactionManager是DefaultTransactionManager

DefaultTransactionManager中提供了事务相关的底层操作

io.seata.tm.api.DefaultGlobalTransaction#commit()

io.seata.tm.api.DefaultGlobalTransaction#rollback()的逻辑与commit()类似，都是重试调用transactionManager.rollback(xid)

​全局事务扫描器部分的代码就看到这里，下面总结一下：

1. ​配置项seata.enabled=true 会触发 SeataAutoConfiguration 自动配置
2. ​SeataAutoConfiguration中创建了一个GlobalTransactionScanner
3. ​GlobalTransactionScanner继承了AbstractAutoProxyCreator，并实现InitializingBean接口
4. ​初始化TM、RM
5. ​由于继承了AbstractAutoProxyCreator，所以BeanFactory会调用GlobalTransactionScanner#方法postProcessAfterInitialization()，最终会调用GlobalTransactionScanner#wrapIfNecessary()来为目标对象创建代理对象
6. ​GlobalTransactionScanner#wrapIfNecessary()中创建了一个GlobalTransactionalInterceptor，GlobalTransactionalInterceptor是一个MethodInterceptor
7. ​在创建代理对象的时候，在AbstractAutoProxyCreator#wrapIfNecessary()方法中，为代理对象应用GlobalTransactionalInterceptor，于是所有目标对象上的方法调用就会转为调用GlobalTransactionalInterceptor#invoke()
8. ​GlobalTransactionalInterceptor#invoke()方法中，首先获取被调用的目标对象的Class和Method对象，然后检查目标方法或类上是否有@GlobalTransactional或@GlobalLock注解，而且配置项中不能禁用全局事务
9. ​如果加了@GlobalTransactional注解，则创建一个AspectTransactional，然后开始处理全局事务，默认传播特性是REQUIRED
10. ​如果加了@GlobalLock注解，则开始处理全局锁
11. ​处理全局事务就是直接调用事务模板中的execute方法，TransactionalTemplate#execute()是一个模板方法，其中定义了事务处理的流程。首先开启事务，然后执行业务逻辑，最后提交事务，异常回滚事务。
12. ​事务操作是在DefaultGlobalTransaction中处理的，最终处理在DefaultTransactionManager。DefaultTransactionManager负责同步远程调用，向TC发请求来开启、提交、回滚事务等操作​

数据库操作执行SQL语句

RM执行本地事务

​通过Java自带的JDBC操作数据库通常是这样的：

Class.forName(driverClass);
// 获取Connection
Connection connection = DriverManager.getConnection(url,user,password);
// 创建Statement或者PreparedStatement
Statement stmt = connection.createStatement();
stmt.execute(sql);

// PreparedStatement ps = connection.prepareStatement(sql);
// ps.execute();

​MyBatis底层也是这一套

接下来看Seata是如何做的

首先是获取数据库连接Connection，前面已经说过了，调用DataSource的getConnection()方法底层是在代理对象SeataDataSourceProxy上调用getConnection()。SeataDataSourceProxy是接口，如果是AT模式，则这个数据源代理对象是DataSourceProxy

DataSourceProxy#getConnection()获取数据库连接

ConnectionProxy#createStatement()

ConnectionProxy#prepareStatement()

PreparedStatementProxy 继承自 StatementProxy，因此下面就直接看PreparedStatementProxy如何执行SQL

​PreparedStatementProxy#execute()

ExecuteTemplate#execute()  是一个模板方法

挑一个看看吧，就挑UpdateExecutor

UpdateExecutor构造方法中一直调父类的构造法，既然如此，那么直接看BaseTransactionalExecutor

UpdateExecutor#execute()

这个方法是从BaseTransactionalExecutor那里继承来的，又是一个模板方法，可见设计模式是多么重要

AbstractDMLBaseExecutor#doExecute()

AbstractDMLBaseExecutor#executeAutoCommitTrue()

ConnectionProxy#changeAutoCommit()

现在事务自动提交已经被Seata改成false了

UpdateExecutor#beforeImage()

BaseTransactionalExecutor#prepareUndoLog()

接下来，提交事务

ConnectionProxy#processGlobalTransactionCommit() 处理全局事务提交

分支事务提交以后，业务数据更改和undo_log就都提交了

回想一下，为什么在执行业务修改前要先将默认的自动提交改成手动提交，最后再改成自动提交呢？

因为，要将业务数据修改和插入undo_log放在同一个事务里，一起提交

这一切都归功于代理

回顾一下整个调用链

结合之前的案例，AT模式TC、TM、RM三者的交互应该是这样的：

问题一：为什么在执行的时候，先将数据库自动提交autoCommit设为false，最后再改成true呢？

答：因为，需要将undo_log和业务数据修改放到同一个事务中，这样可以保证业务数据修改成功后undo_log必然插入成功，所以Seata要将其改为手动提交。最后再改成true是因为默认autoCommit就是true，这样可以不影响其它业务。

问题二：什么情况下ConnectionContext中xid=null，且isGlobalLockRequire=true呢？或者换一种问法，什么情况下不在全局事务中，当仍然需要全局锁呢？

答：当业务方法上不加@GlobalTransactional，而是只加了@GlobalLock注解的情况下，就会出现上述情况，也就会执行 ConnectionProxy#processLocalCommitWithGlobalLocks()方法，在事务提交前检查全局锁，这样设计的目的是在AT模式下，不出现脏读、脏写。由于数据源被代理了，当一个加了@GlobalTransactional的全局事务，与另一个加了@GlobalTransactional或@GlobalLock注解的事务在本地事务提交前就会检查全局锁，要先获得全局锁才能提交本地事务，这样就避免了脏读脏写，从而相当于实现了全局事务的读已提交隔离级别。参见：​​https://seata.io/zh-cn/blog/seata-at-lock.html​​

关于Seata 1.5.2 Client端的源码学习就先到这里，欢迎交流~

如果你都已经看到了这里，不妨给我点个赞吧😄

原文：​​Seata 1.5.2 源码学习 - 废物大师兄 - 博客园​​