# 1 背景介绍因项目在外挂服务升级到3.9.0版本以上后，经常出现数据源切换失败的问题；特针对外挂的动态数据源组件进行原理说明，同时提供正确的使用方式。 # 2 事务基本概念 ## 2.1 什么是事务 **事务**：是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）。 **事务的四大特性：** > 1. 原子性 > 事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做。 > 2. 一致性 > 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。 > 3. 隔离性 > 一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。 > 4. 持续性 > 也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。 ## 2.2 原生JDBC处理事务 ```java try { connection.setAutoCommit(false); //这里用connection对数据库做了一系列操作，CRUD connection.commit();//没有异常就提交 } catch(Exception ex) { connection.rollback(); //异常回滚 } finally { connection.setAutoCommit(true); } ``` 以上是事务的核心，通过关闭自动提交，实现手动开启事务。所有操作要一起成功，只要出错就回滚。 ## 2.3 Spring处理事务 spring开启事务很简单，在需要事务的方法和类上添加 `@Transactional`注解。 ``` @Transactional public void test() { Aservice.dosometing(); Bservice.dosometing(); } ``` 使用了 `@Transactional`，**spring会保证整个事务下都复用同一个connection。** 在默认配置下，只要事务中发生RuntimeException，就会回滚。 ## 2.4 Spring事务的传播机制在方法嵌套调用的情况下，多个 `@Transactional`注解可以通过事务传播机制来控制事务。具体可以网上查询相关资料，此类资料比较多，以下是一篇相关的介绍文章： [图解spring中七种事务传播行为终于有人讲明白了\_spring 事务传播行为图解-CSDN博客](https://blog.csdn.net/qq_27184497/article/details/116525588) # 3 动态数据源组件切换原理 ## 3.1 动态数据源结构 ![image.png](http://tmpbbs.ztc.ztccloud.com.cn:6875/developers-server/rest/file/group1/2024/08/22/1830A2CE7940F479E820B1B7B2AE0200.png) 外挂服务里面最顶层的DataSource是动态数据源(DynamicRoutingDataSource)，其通过Map对象代理持有了多个实际的数据源。如果我们以下代码注入数据源对象，那么实际上拿到的就是DynamicRoutingDataSource对象： ```java @Autowired DataSource dataSource; ``` ## 3.2 切换流程 ### 3.2.1 @DS注解指定数据源 @DS注解是借助的Spring AOP机制，向线程本地变量存放数据源key，所以注解的有效范围仅在当前线程，并且要让注解生效，必须满足AOP切面条件。 **注意，@DS并不代表切换了数据源，只是告诉线程后续从动态数据源获取连接，需要从指定的实际数据源取。** 关键代码： com.baomidou.dynamic.datasource.toolkit.DynamicDataSourceContextHolder ```java /** * 为什么要用链表存储(准确的是栈) *

     * 为了支持嵌套切换，如ABC三个service都是不同的数据源
     * 其中A的某个业务要调B的方法，B的方法需要调用C的方法。一级一级调用切换，形成了链。
     * 传统的只设置当前线程的方式不能满足此业务需求，必须使用栈，后进先出。
     *

*/ private static final ThreadLocal> LOOKUP_KEY_HOLDER = new NamedThreadLocal>("dynamic-datasource") { @Override protected Deque initialValue() { return new ArrayDeque<>(); } }; /** * 设置当前线程数据源 *

* 如非必要不要手动调用，调用后确保最终清除 *

* * @param ds 数据源名称 * @return 数据源名称 */ public static String push(String ds) { String dataSourceStr = DsStrUtils.isEmpty(ds) ? "" : ds; LOOKUP_KEY_HOLDER.get().push(dataSourceStr); return dataSourceStr; } ``` ### 3.2.2 获取连接时切换数据源当应用程序需要从动态数据源获取连接时，会从线程本地变量获取当前最新的数据源key，然后找到实际数据源，获取其连接，从而实现数据源的切换。因此，这里最关键的点就是需要重新向动态数据源申请连接，才能完成数据源的切换工作，否则如果应用程序一直使用的是历史连接，那么就会出现切换数据源失败的情况。 **注意，如果线程本地变量没有数据源key，则取的是默认数据源连接(当前配置文件都是配置的zfs_sys库)。** 关键代码： com.baomidou.dynamic.datasource.DynamicRoutingDataSource ```java //获取连接 @Override public Connection getConnection() throws SQLException { String xid = TransactionContext.getXID(); if (DsStrUtils.isEmpty(xid)) { //现在一般都是走这一步获取连接 return determineDataSource().getConnection(); } else { String ds = DynamicDataSourceContextHolder.peek(); ds = DsStrUtils.isEmpty(ds) ? getPrimary() : ds; ConnectionProxy connection = ConnectionFactory.getConnection(xid, ds); return connection == null ? getConnectionProxy(xid, ds, determineDataSource().getConnection()) : connection; } } //确定实际数据源 @Override public DataSource determineDataSource() { String dsKey = DynamicDataSourceContextHolder.peek(); return getDataSource(dsKey); } /** * 获取数据源 * * @param ds 数据源名称 * @return 数据源 */ public DataSource getDataSource(String ds) { if (DsStrUtils.isEmpty(ds)) { return determinePrimaryDataSource(); } else if (!groupDataSources.isEmpty() && groupDataSources.containsKey(ds)) { log.debug("dynamic-datasource switch to the datasource named [{}]", ds); return groupDataSources.get(ds).determineDataSource(); } else if (dataSourceMap.containsKey(ds)) { log.debug("dynamic-datasource switch to the datasource named [{}]", ds); return dataSourceMap.get(ds); } if (strict) { throw new CannotFindDataSourceException("dynamic-datasource could not find a datasource named " + ds); } return determinePrimaryDataSource(); } ``` # 4 常见数据源切换失败场景分析 ## 4.1 @DS注解没有满足AOP切面因为@DS注解依赖Spring AOP机制，因此如果不满足切面条件，例如服务方法内部调用，则无法向线程本地变量存入数据源key，从而导致数据源切换失败。示例代码： ```java @Service public class UserService { @DS("boe") public void test1() { // do something test2(); } @DS("op") public void test2() { // do something } } ``` 解决方法：把test2()方法提到另外一个service,单独调用。 ## 4.2 开启了Spring的事务 Spring开启事务后会维护一个ConnectionHolder，保证在整个事务下，都是用同一个数据库连接。没有重新拿数据库连接，就会导致数据源切换失败。示例代码： ```java @Service public class UserService { @Autowired private OrderService orderService; @DS("boe") @Transactional public void test1() { // do something orderService.test2(); } } @Service public class OrderService { @DS("op") public void test2() { // do something } } ``` 解决办法：使用独立事务或者使用新线程，见后续章节的推荐用法。 ## 4.3 请求内部存在多个平级事务(无嵌套事务) 一个Controller请求进来，存在多个平级的本地事务，且这些平级事务外层并没有本地事务注解开启事务。因为JPA的事务管理器会缓存数据库连接，当平级事务的前置事务结束后，并不会立即释放此连接，当有新的平级事务开启时会直接使用缓存连接，而不是从DataSource重新拿连接，最终导致数据源切换失败。注意JPA的默认方法都是带@Transactional注解的，因此都是隐藏的事务方法。示例代码： ```java @RestController public class TestController{ @Autowired private OrderService orderService; @GetMapping("test") public String test() { orderService.order(); } } @Service public class OrderService { @Autowired private UserService userService; @Autowired private DeliverService deliverService; public void test1() { //此处是两个平级事务方法 userService.test1(); deliverService.test2(); } } @Service public class UserService { @DS("op") @Transactional public void test1() { // do something } } @Service public class DeliverService { @DS("op") @Transactional public void test2() { // do something } } ``` 解决办法：使用独立事务或者使用新线程，见后续章节的推荐用法。 # 5 推荐用法 ## 5.1 一个请求对应一个数据源整个http请求中，即Controller方法内部都只使用一个数据源，不涉及操作多个数据源的表，这种方式可以降低事务的复杂度。示例代码： ```java @RestController public class TestController{ @Autowired private OrderService orderService; @GetMapping("test") public String test() { orderService.order(); } } @Service public class OrderService { @Autowired private UserService userService; @Autowired private DeliverService deliverService; @DS("boe") @Transactional public void test1() { userService.test1(); deliverService.test2(); } } @Service public class UserService { public void test1() { // do something } } @Service public class DeliverService { public void test2() { // do something } } ``` ## 5.2 使用独立事务请求入口处，一般是Controller方法调用的入口Service方法处(如果没有可以封装一个)，先加上一个外层事务，然后在内部如果有任何需要切换数据源的地方，都使用新的独立事务处理。 **建议独立事务注解和@DS注解放一起，让切换数据源和获取连接同时生效。** 注意：多个本地事务无法保证事务一致性问题，需要配合Seata分布式事务才能实现。示例代码： ```java @RestController public class TestController{ @Autowired private OrderService orderService; @GetMapping("test") public String test() { orderService.order(); } } @Service public class OrderService { @Autowired private UserService userService; @Autowired private DeliverService deliverService; //外层事务入口，此处可切换数据源，也可以不切，不切的话使用的是默认数据源zfs_sys //@DS("boe") @Transactional public void test1() { //此处是两个平级事务方法 userService.test1(); deliverService.test2(); } } @Service public class UserService { //使用传播机制参数REQUIRES_NEW开启新事物 @DS("op") @Transactional(propagation = Propagation.REQUIRES_NEW) public void test1() { // do something } } @Service public class DeliverService { //使用传播机制参数REQUIRES_NEW开启新事物 @DS("ip") @Transactional(propagation = Propagation.REQUIRES_NEW) public void test2() { // do something } } ``` ## 5.3 使用新线程因为@DS以及事务注解都是只在当前线程生效，如果想开启新事务，可以通过将新事务的方法放到另外一个线程执行，也可以实现数据源的切换，因为新线程获重新获取数据源的连接。示例代码： ``` @RestController public class TestController{ @Autowired private OrderService orderService; @GetMapping("test") public String test() { orderService.order(); } } @Service public class OrderService { @Autowired private UserService userService; @Autowired private DeliverService deliverService; @Autowired private Executor asyncExecutor; @Transactional public void test1() { //放到线程池中执行，会开启新事物 asyncExecutor.execute(() -> userService.test1()); asyncExecutor.execute(() -> deliverService.test2()); } } @Service public class UserService { @DS("op") @Transactional public void test1() { // do something } } @Service public class DeliverService { @DS("ip") @Transactional public void test2() { // do something } } ``` # 6 历史项目升级指引因3.9.0以前的动态数据源架构和现在不一样，原来是基于sharding改造的，而升级后的sharding架构存在非常大的变动，因此3.9.0版本开始引入了第三方的dynamic-datasource组件。 **新旧版本区别**： 1. 旧版本只需要获取到连接，不管是获取一次，还是获取多次，都是拿到的ShardingConnection，实际的数据源切换是在ShardingConnection内部做的。 2. 新版本需要通过重新获取连接才能实现数据源的切换，如果没有重新获取连接，则无法切换数据源。 **新版本改造步骤：** 1. 给所有涉及多数据源的Controller接口的入口Service方法添加一个外层事务，如果没有统一入口方法，可以封装一个。 2. 搜索所有加了@DS注解的方法，统一给这些方法加上注解@Transactional(propagation = Propagation.REQUIRES_NEW)，以便能开启新的独立事务。 3. 代码案例请参考：(采用独立事务方式)，

外挂服务动态数据源组件之切换失败

外挂服务动态数据源组件之切换失败

关于作者

目录