多数据源下@transactional事务踩坑实战指南

多数据源使用DynamicDatasource，再用@Transactiona注解，造成数据源会切换的BUG：

• 方法上写了 @DS("slave")
• 执行 SQL 时却仍然走了 master

情景浮现：

@DS("master")
public class DB1Service{
	public list<?> queryDB1()
}

@DS("slaver")
public class DB2Service{
	public list<?> queryDB2()
}

public class Main{

	@Transactional(rollbackFor = Exception.class)
	public void sync(){
		// 预期会走slaver库，⚠️ 但实际还是会查询 master DB
		var list2 = DB2Service.queryDB2()
		
		// .....
		var list1 = DB1Service.queryDB1()
	}
}

1 为什么？

先说结论 ：
在同一个本地事务里，第一次拿到的连接会绑定到当前线程。后续再切 @DS，通常只会改路由标识，不会替换已经绑定的连接。

调用 sync() 时，大致发生下面几步：

1. 进入 @Transactional 代理，事务开始
2. 事务管理器通过 DataSourceUtils.getConnection(...) 拿连接
3. 连接绑定到 TransactionSynchronizationManager（ThreadLocal）
4. 执行业务代码，进入 db2Service.queryDB2()
5. @DS("slave") 把当前线程的数据源 key 改成 slave
6. 但取连接时发现线程里已经有事务连接，于是直接复用
7. SQL 继续走原连接（常见是 master）

这里最重要的一点： @DS 决定的是 “下一次新建连接时选哪个数据源”，不是“把当前事务里的连接热切换”。

如果连接已经在事务里绑定好了，它不会换连接。

2 扩展：Dynamic-Datasource实现多数据源原理

1. 启动阶段装配
   • DynamicDataSourceAutoConfiguration 注册 DynamicRoutingDataSource 作为主 DataSource。
   • 把你配置的 spring.datasource.dynamic.datasource.* 加载成数据源池，维护在内部 dataSourceMap/groupDataSources 里。

2. AOP 拦截 @DS
   • DynamicDataSourceAopConfiguration 装配 DynamicDataSourceAnnotationAdvisor + Interceptor。
   • 方法进入时，DynamicDataSourceAnnotationInterceptor 解析 @DS 值（DataSourceClassResolver，支持方法/类、接口、继承等）。
   • 解析出的 key（如 master/doris）被 push 到
   DynamicDataSourceContextHolder（ThreadLocal，栈结构，支持嵌套调用）。
   • 方法退出后 poll，恢复上一个数据源上下文。

3. 真正路由发生在“取连接” • JdbcTemplate/MyBatis 最终都会走到当前主数据源取连接。
   • 主数据源是 DynamicRoutingDataSource，它在 determineDataSource() 里 peek 当前线程 key。
   • 然后 getDataSource(key)：
   • key 为空 -> 用 primary（默认 master）
   • key 是具体库名 -> 直连该库
   • key 是组名 -> 按策略（默认负载均衡）选组内某个库
   • 未命中时：strict=true 抛异常，strict=false 回退 primary

总结：

• @DS 只是改“路由上下文”

• DynamicRoutingDataSource 在取连接时按上下文选库

• 不是直接“切换已拿到的连接”

到此这篇关于多数据源下@transactiona事务踩坑实战指南的文章就介绍到这了,更多相关多数据源下@transactiona事务内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论