1. 项目概述为什么多数据源配置是后端开发的硬核技能在前后端分离的架构下后端服务作为数据中枢其灵活性和健壮性直接决定了整个应用的边界。我接手过不少从单体应用向微服务或复杂业务系统演进的项目一个高频出现的痛点就是业务数据散落在多个不同的数据库中。可能是历史遗留的SQL Server库需要与新开发的MySQL模块共存也可能是核心交易数据在A库而日志、报表数据在B库。这时候如果还在代码里写死一个数据库连接或者用各种“土法炼钢”的切换方式不仅代码难以维护性能和数据一致性更是噩梦。若依框架RuoYi作为一个基于Spring Boot的快速开发平台其前后端分离版本提供了优雅的解决方案骨架。它内置了多数据源的支持但官方文档往往点到为止真正要在生产环境稳稳落地里面有不少门道。这个教程我就结合自己趟过的坑把从原理到配置再到避坑的完整流程拆解清楚。无论你是需要接入多个同构数据库如多个MySQL实例还是异构数据库如MySQL PostgreSQL都能从这里找到可复用的路径。核心就一句话让不同的Service方法像调用本地函数一样透明地操作各自背后的数据源且保证事务的边界清晰。2. 核心设计思路抽象与动态路由的艺术多数据源的本质不是一个技术炫技而是一个设计问题。其核心思路是在应用启动时创建多个数据源DataSource对象在执行SQL操作前通过一个拦截机制动态地将当前操作路由到正确的数据源上。若依框架的实现正是基于这一经典模式。2.1 技术栈选型与底层原理若依前后端分离版默认集成了MyBatis作为ORM框架并依赖Spring Boot的自动配置。实现多数据源社区主流有两种做法基于AbstractRoutingDataSource的动态数据源这是Spring框架提供的一个抽象类允许我们自定义一个数据源在每次获取数据库连接时根据某个“键”Lookup Key动态返回真实的数据源。这是若依框架采用的方式也是本教程的核心。它的好处是与Spring事务管理Transactional集成度好对业务代码侵入小。多套独立的MyBatis SqlSessionTemplate为每个数据源配置一套独立的SqlSessionFactory和SqlSessionTemplate在DAO层或Service层手动注入和使用对应的Template。这种方式更直接但需要手动管理事务传播代码侵入性强不适合在若依这种约定大于配置的框架中大规模使用。为什么若依选择第一种因为它更符合Spring的“习惯”。通过一个注解如DataSource来标记数据源在AOP切面中设置当前线程的Lookup KeyAbstractRoutingDataSource在获取连接时就能自动切换。业务开发者几乎无感知。2.2 若依多数据源模块结构解析在若依的源码中多数据源相关代码主要位于ruoyi-common模块下的datasource包内。理解这个结构是后续一切配置和调试的基础DynamicDataSource类继承自AbstractRoutingDataSource。这是“路由器”本身。你需要重写它的determineCurrentLookupKey()方法告诉它当前应该返回哪个数据源的名字如“master”, “slave”。DataSourceType枚举类定义数据源名称的常量。例如MASTER、SLAVE。这是为了避免在代码中硬编码字符串提升可维护性。DynamicDataSourceContextHolder类这是一个关键的上下文持有者。它使用ThreadLocal来保存当前线程对应的数据源键值。DynamicDataSource的determineCurrentLookupKey()方法就是从这里获取值的。ThreadLocal保证了线程间的隔离这是实现正确路由的基石。DataSourceAspect切面类这是“调度员”。它拦截被DataSource注解标记的方法在方法执行前将注解指定的数据源名称设置到DynamicDataSourceContextHolder中在方法执行后包括异常情况清理上下文避免内存泄漏和上下文污染。这个“注解 - 切面 - 上下文持有者 - 动态数据源”的链条就是若依多数据源的核心工作原理。我们的配置就是为这个链条提供“燃料”——即真实的数据源Bean。3. 详细配置步骤从零到一的实战假设我们的场景是主业务数据在master数据源MySQL一些运营报表数据在slave数据源另一个MySQL实例也可以是其他数据库。3.1 依赖确认与数据源配置首先确保你的pom.xml中已经包含了数据库驱动和连接池依赖。若依默认使用HikariCP这是目前性能最好的连接池之一。!-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 若依框架已经集成了HikariCP通过spring-boot-starter-jdbc引入 --接下来是重头戏在application.yml(或application-druid.yml若依默认使用Druid配置) 中配置多个数据源。这里有个关键点Spring Boot默认的spring.datasource配置只会自动创建一个数据源Bean。我们要禁用这个自动配置改为手动定义多个。# application.yml spring: # 1. 首先关闭默认的数据源自动配置重要 autoconfigure: exclude: - com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceAutoConfigure # 如果不用Druid也需要排除对应的自动配置类 # 2. 定义多个数据源的连接信息前缀可以自定义 datasource: druid: master: url: jdbc:mysql://localhost:3306/ry_master?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver slave: url: jdbc:mysql://192.168.1.100:3306/ry_slave?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: report_user password: report_password driver-class-name: com.mysql.cj.jdbc.Driver # 以下是Druid连接池的通用配置可选但建议 type: com.alibaba.druid.pool.DruidDataSource initialSize: 5 minIdle: 5 maxActive: 20 maxWait: 60000 # ... 其他Druid监控、过滤器配置注意这里以Druid为例。如果你使用HikariCP配置前缀是spring.datasource.hikari并且属性名有所不同如maximum-pool-size对应maxActive。务必保持连接池配置与你的实际依赖一致。3.2 核心Java配置类编写配置完YAML我们需要在Java代码中将这些配置“实例化”为Spring Bean。通常会在com.ruoyi.framework.config包下创建一个DataSourceConfig类。package com.ruoyi.framework.config; import com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceBuilder; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Primary; import javax.sql.DataSource; import java.util.HashMap; import java.util.Map; Configuration public class DataSourceConfig { /** * 主数据源 (默认数据源) * ConfigurationProperties 注解将 spring.datasource.druid.master 下的属性绑定到DataSource */ Bean(name masterDataSource) ConfigurationProperties(prefix spring.datasource.druid.master) Primary // 标记为默认数据源当找不到指定数据源时使用 public DataSource masterDataSource() { return DruidDataSourceBuilder.create().build(); } /** * 从数据源 */ Bean(name slaveDataSource) ConfigurationProperties(prefix spring.datasource.druid.slave) public DataSource slaveDataSource() { return DruidDataSourceBuilder.create().build(); } /** * 动态数据源核心配置 * 将多个数据源注入到 DynamicDataSource 中 */ Bean(name dynamicDataSource) public DataSource dynamicDataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); // 配置默认数据源必须 dynamicDataSource.setDefaultTargetDataSource(masterDataSource()); // 配置多数据源映射 MapObject, Object dataSourceMap new HashMap(); dataSourceMap.put(DataSourceType.MASTER.name(), masterDataSource()); dataSourceMap.put(DataSourceType.SLAVE.name(), slaveDataSource()); dynamicDataSource.setTargetDataSources(dataSourceMap); return dynamicDataSource; } }这个配置类做了三件事创建了名为masterDataSource和slaveDataSource的两个具体数据源Bean。将masterDataSource标记为Primary这是Spring的“保底”机制。当系统无法确定用哪个数据源时例如某些框架内部初始化就会使用这个默认的。创建了关键的dynamicDataSourceBean。它把前面两个具体数据源包装成一个Map并设置了默认数据源。这样DynamicDataSource类就能根据Key从这个Map里拿到真正的连接。3.3 MyBatis与事务管理器配置数据源准备好了接下来要告诉MyBatis和Spring事务管理器使用我们刚刚创建的动态数据源。package com.ruoyi.framework.config; import org.mybatis.spring.annotation.MapperScan; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.jdbc.datasource.DataSourceTransactionManager; import org.springframework.transaction.PlatformTransactionManager; import org.springframework.transaction.annotation.EnableTransactionManagement; import javax.sql.DataSource; Configuration EnableTransactionManagement // 启用注解式事务管理 MapperScan(basePackages com.ruoyi.**.mapper) // MyBatis mapper扫描路径 public class MyBatisConfig { /** * 配置事务管理器注意这里注入的是 dynamicDataSource */ Bean public PlatformTransactionManager transactionManager(DataSource dynamicDataSource) { return new DataSourceTransactionManager(dynamicDataSource); } // 如果你的MyBatis配置需要指定SqlSessionFactory也需要注入dynamicDataSource // Bean // public SqlSessionFactory sqlSessionFactory(DataSource dynamicDataSource) throws Exception { // SqlSessionFactoryBean sessionFactory new SqlSessionFactoryBean(); // sessionFactory.setDataSource(dynamicDataSource); // // ... 其他配置如typeAliasesPackage, mapperLocations // return sessionFactory.getObject(); // } }这里有一个至关重要的细节PlatformTransactionManager的Bean注入的是dynamicDataSource而不是任何一个具体的数据源。因为Spring的事务管理是基于一个DataSource的。如果我们注入masterDataSource那么所有的事务包括标记为DataSource(“slave”)的方法都会在master库上开启和提交这会导致严重的数据错乱。让事务管理器绑定到动态数据源上它才能感知到路由变化并在正确的物理连接上管理事务。4. 业务层使用与注解驱动开发配置完成后在业务代码中使用就非常优雅了。4.1 在Service层方法上使用DataSource注解假设有一个查询报表的服务package com.ruoyi.system.service.impl; import com.ruoyi.common.annotation.DataSource; import com.ruoyi.common.enums.DataSourceType; import com.ruoyi.system.domain.ReportData; import com.ruoyi.system.mapper.ReportMapper; import com.ruoyi.system.service.IReportService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import java.util.List; Service public class ReportServiceImpl implements IReportService { Autowired private ReportMapper reportMapper; /** * 此方法使用从库数据源 */ Override DataSource(DataSourceType.SLAVE) // 关键注解 public ListReportData selectReportList(ReportData reportData) { // 这个方法内部的所有数据库操作都会自动路由到 slave 数据源 return reportMapper.selectReportList(reportData); } /** * 此方法使用主库数据源默认可不加注解或显式指定DataSource(DataSourceType.MASTER) */ Override // DataSource(DataSourceType.MASTER) // 可加可不加 public void updateMasterData(SomeData data) { // 这里的操作会在 master 数据源上执行 someMapper.update(data); } }对应的Mapper接口和XML文件无需任何特殊改动就像平时写单数据源一样。MyBatis的SqlSession会从dynamicDataSource获取连接而后者已经通过切面设置好了正确的路由键。4.2 注解生效范围与继承性DataSource注解是基于Spring AOP实现的这意味着它只对Spring代理对象的方法调用生效。以下情况需要特别注意同类方法调用失效在同一个Service类中一个未加注解的方法A直接调用加了DataSource注解的方法B注解是不会生效的。因为A调用B是this.B()绕过了Spring的代理。解决方法是将方法B抽取到另一个Service中或者使用AopContext.currentProxy()来获取当前代理对象再调用不推荐侵入性强。事务注解的协同DataSource和Transactional可以同时使用。执行顺序是先进入DataSource切面设置数据源键再进入Transactional切面开启事务。务必确保这两个注解修饰的是同一个方法并且事务管理器绑定的是dynamicDataSource。无注解默认行为如果一个方法没有标注DataSource那么DynamicDataSourceContextHolder中就没有值DynamicDataSource会返回其设置的默认数据源即我们在配置中设置的setDefaultTargetDataSource通常是master。5. 生产环境进阶配置与深度避坑指南把多数据源跑起来只是第一步要让它稳定可靠地服务于生产环境还需要考虑更多。5.1 连接池参数精细化调优不同业务的数据源其访问模式可能天差地别。主库可能写多读少连接要求高可用、低延迟从库或报表库可能主要用于复杂查询连接占用时间长。切忌使用同一套连接池参数。spring: datasource: druid: master: url: ... # 主库连接池快速响应连接复用率高 initialSize: 10 minIdle: 10 maxActive: 50 # 根据应用服务器线程数和QPS估算 maxWait: 1000 # 等1秒拿不到连接就抛异常避免雪崩 validationQuery: SELECT 1 testWhileIdle: true timeBetweenEvictionRunsMillis: 60000 slave: url: ... # 报表库连接池允许长时间占用但总量控制 initialSize: 5 minIdle: 5 maxActive: 20 # 防止复杂查询拖垮从库 maxWait: 5000 # 查询可以多等一会儿 validationQuery: SELECT 1 testWhileIdle: true timeBetweenEvictionRunsMillis: 120000 # 空闲检查可以慢一些5.2 多数据源下的分布式事务难题这是多数据源架构中最棘手的问题之一。Spring的Transactional在单数据源下是本地事务但在多数据源下它无法保证跨数据源的原子性。例如Transactional public void transfer() { // 操作master数据源 masterAccountMapper.deductMoney(); // 操作slave数据源或另一个master slaveRecordMapper.addRecord(); // 如果这里抛出异常master上的扣款会回滚但slave上的记录不会 }解决方案取决于你的业务容忍度最终一致性推荐接受短时间的不一致通过消息队列、定时任务或日志补偿机制在事后达成一致。这是互联网高并发场景下的主流选择。Seata等分布式事务框架引入中间件通过AT、TCC等模式实现强一致性。这会带来一定的性能损耗和架构复杂度适用于金融、交易等核心场景。若依框架本身不集成Seata需要自行引入和配置。尽量避免跨库事务从业务设计上规避将相关操作收敛到同一个数据源中。5.3 监控与健康检查多个数据源意味着更多的监控点。除了应用本身的监控每个数据库实例、每个连接池的健康状态都需要关注。Druid监控如果使用Druid其内置的监控页面/druid非常强大。你需要为每个DataSourceBean配置StatFilter和WallFilter并在监控页上查看各自的SQL执行情况、连接池状态。Spring Boot Actuator通过/actuator/health端点可以集成数据库健康检查。你需要自定义一个HealthIndicator遍历所有数据源执行validationQuery来检查连通性。关键指标告警对每个数据源的activeCount活跃连接数、waitThreadCount等待线程数设置告警。如果某个数据源的等待线程数持续过高很可能遇到了慢查询或连接泄漏。5.4 常见问题排查实录报错”No qualifying bean of type ‘javax.sql.DataSource’ available”原因Spring容器中存在多个DataSource类型的Bean而某些自动配置类如JPA、MyBatis AutoConfiguration期望只有一个。或者你的MapperScan、EntityManager等注入错了数据源。解决检查是否排除了数据源自动配置spring.autoconfigure.exclude。确保MapperScan、SqlSessionFactoryBean、TransactionManager等Bean明确注入了dynamicDataSource。报错”Could not open JDBC Connection for transaction”原因事务管理器使用了错误的数据源。典型症状是在标记了DataSource(“slave”)的方法上开启事务但连接却尝试从master获取而master的配置可能不对。解决百分百确认你的PlatformTransactionManagerBean定义中DataSource参数注入的是dynamicDataSource。数据源切换偶尔失效全部跑到默认库原因线程上下文污染。DynamicDataSourceContextHolder使用ThreadLocal如果在切面中设置后没有及时清理当线程被线程池复用时残留的数据源键会导致后续无关操作路由错误。或者在异步任务Async中上下文没有正确传递。解决确保DataSourceAspect切面在finally块中清理了ThreadLocal。对于异步场景需要自定义任务装饰器在任务执行前传递并设置数据源键。性能问题在循环中频繁切换数据源场景在一个方法里循环调用多个不同DataSource注解的Service方法。分析每次切换数据源都有微小开销AOP拦截、ThreadLocal操作。虽然不大但在高频循环中会累积。建议重构业务逻辑尽量将访问同一数据源的操作批量执行。或者在更高层的方法上标注数据源在内部通过DataSourceAspect的子切面控制更细粒度的切换较复杂。多数据源与MyBatis-Plus共用时的冲突现象引入了MyBatis-Plus后多数据源配置不生效。原因MyBatis-Plus有自己的自动配置和SqlSessionFactoryBean它会使用Primary的数据源而忽略我们的动态数据源。解决需要手动配置MyBatis-Plus的MybatisSqlSessionFactoryBean并将其数据源设置为我们的dynamicDataSource。同时可能需要排除MyBatis-Plus的部分自动配置。
1. 项目概述为什么多数据源配置是后端开发的硬核技能在前后端分离的架构下后端服务作为数据中枢其灵活性和健壮性直接决定了整个应用的边界。我接手过不少从单体应用向微服务或复杂业务系统演进的项目一个高频出现的痛点就是业务数据散落在多个不同的数据库中。可能是历史遗留的SQL Server库需要与新开发的MySQL模块共存也可能是核心交易数据在A库而日志、报表数据在B库。这时候如果还在代码里写死一个数据库连接或者用各种“土法炼钢”的切换方式不仅代码难以维护性能和数据一致性更是噩梦。若依框架RuoYi作为一个基于Spring Boot的快速开发平台其前后端分离版本提供了优雅的解决方案骨架。它内置了多数据源的支持但官方文档往往点到为止真正要在生产环境稳稳落地里面有不少门道。这个教程我就结合自己趟过的坑把从原理到配置再到避坑的完整流程拆解清楚。无论你是需要接入多个同构数据库如多个MySQL实例还是异构数据库如MySQL PostgreSQL都能从这里找到可复用的路径。核心就一句话让不同的Service方法像调用本地函数一样透明地操作各自背后的数据源且保证事务的边界清晰。2. 核心设计思路抽象与动态路由的艺术多数据源的本质不是一个技术炫技而是一个设计问题。其核心思路是在应用启动时创建多个数据源DataSource对象在执行SQL操作前通过一个拦截机制动态地将当前操作路由到正确的数据源上。若依框架的实现正是基于这一经典模式。2.1 技术栈选型与底层原理若依前后端分离版默认集成了MyBatis作为ORM框架并依赖Spring Boot的自动配置。实现多数据源社区主流有两种做法基于AbstractRoutingDataSource的动态数据源这是Spring框架提供的一个抽象类允许我们自定义一个数据源在每次获取数据库连接时根据某个“键”Lookup Key动态返回真实的数据源。这是若依框架采用的方式也是本教程的核心。它的好处是与Spring事务管理Transactional集成度好对业务代码侵入小。多套独立的MyBatis SqlSessionTemplate为每个数据源配置一套独立的SqlSessionFactory和SqlSessionTemplate在DAO层或Service层手动注入和使用对应的Template。这种方式更直接但需要手动管理事务传播代码侵入性强不适合在若依这种约定大于配置的框架中大规模使用。为什么若依选择第一种因为它更符合Spring的“习惯”。通过一个注解如DataSource来标记数据源在AOP切面中设置当前线程的Lookup KeyAbstractRoutingDataSource在获取连接时就能自动切换。业务开发者几乎无感知。2.2 若依多数据源模块结构解析在若依的源码中多数据源相关代码主要位于ruoyi-common模块下的datasource包内。理解这个结构是后续一切配置和调试的基础DynamicDataSource类继承自AbstractRoutingDataSource。这是“路由器”本身。你需要重写它的determineCurrentLookupKey()方法告诉它当前应该返回哪个数据源的名字如“master”, “slave”。DataSourceType枚举类定义数据源名称的常量。例如MASTER、SLAVE。这是为了避免在代码中硬编码字符串提升可维护性。DynamicDataSourceContextHolder类这是一个关键的上下文持有者。它使用ThreadLocal来保存当前线程对应的数据源键值。DynamicDataSource的determineCurrentLookupKey()方法就是从这里获取值的。ThreadLocal保证了线程间的隔离这是实现正确路由的基石。DataSourceAspect切面类这是“调度员”。它拦截被DataSource注解标记的方法在方法执行前将注解指定的数据源名称设置到DynamicDataSourceContextHolder中在方法执行后包括异常情况清理上下文避免内存泄漏和上下文污染。这个“注解 - 切面 - 上下文持有者 - 动态数据源”的链条就是若依多数据源的核心工作原理。我们的配置就是为这个链条提供“燃料”——即真实的数据源Bean。3. 详细配置步骤从零到一的实战假设我们的场景是主业务数据在master数据源MySQL一些运营报表数据在slave数据源另一个MySQL实例也可以是其他数据库。3.1 依赖确认与数据源配置首先确保你的pom.xml中已经包含了数据库驱动和连接池依赖。若依默认使用HikariCP这是目前性能最好的连接池之一。!-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 若依框架已经集成了HikariCP通过spring-boot-starter-jdbc引入 --接下来是重头戏在application.yml(或application-druid.yml若依默认使用Druid配置) 中配置多个数据源。这里有个关键点Spring Boot默认的spring.datasource配置只会自动创建一个数据源Bean。我们要禁用这个自动配置改为手动定义多个。# application.yml spring: # 1. 首先关闭默认的数据源自动配置重要 autoconfigure: exclude: - com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceAutoConfigure # 如果不用Druid也需要排除对应的自动配置类 # 2. 定义多个数据源的连接信息前缀可以自定义 datasource: druid: master: url: jdbc:mysql://localhost:3306/ry_master?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver slave: url: jdbc:mysql://192.168.1.100:3306/ry_slave?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: report_user password: report_password driver-class-name: com.mysql.cj.jdbc.Driver # 以下是Druid连接池的通用配置可选但建议 type: com.alibaba.druid.pool.DruidDataSource initialSize: 5 minIdle: 5 maxActive: 20 maxWait: 60000 # ... 其他Druid监控、过滤器配置注意这里以Druid为例。如果你使用HikariCP配置前缀是spring.datasource.hikari并且属性名有所不同如maximum-pool-size对应maxActive。务必保持连接池配置与你的实际依赖一致。3.2 核心Java配置类编写配置完YAML我们需要在Java代码中将这些配置“实例化”为Spring Bean。通常会在com.ruoyi.framework.config包下创建一个DataSourceConfig类。package com.ruoyi.framework.config; import com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceBuilder; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Primary; import javax.sql.DataSource; import java.util.HashMap; import java.util.Map; Configuration public class DataSourceConfig { /** * 主数据源 (默认数据源) * ConfigurationProperties 注解将 spring.datasource.druid.master 下的属性绑定到DataSource */ Bean(name masterDataSource) ConfigurationProperties(prefix spring.datasource.druid.master) Primary // 标记为默认数据源当找不到指定数据源时使用 public DataSource masterDataSource() { return DruidDataSourceBuilder.create().build(); } /** * 从数据源 */ Bean(name slaveDataSource) ConfigurationProperties(prefix spring.datasource.druid.slave) public DataSource slaveDataSource() { return DruidDataSourceBuilder.create().build(); } /** * 动态数据源核心配置 * 将多个数据源注入到 DynamicDataSource 中 */ Bean(name dynamicDataSource) public DataSource dynamicDataSource() { DynamicDataSource dynamicDataSource new DynamicDataSource(); // 配置默认数据源必须 dynamicDataSource.setDefaultTargetDataSource(masterDataSource()); // 配置多数据源映射 MapObject, Object dataSourceMap new HashMap(); dataSourceMap.put(DataSourceType.MASTER.name(), masterDataSource()); dataSourceMap.put(DataSourceType.SLAVE.name(), slaveDataSource()); dynamicDataSource.setTargetDataSources(dataSourceMap); return dynamicDataSource; } }这个配置类做了三件事创建了名为masterDataSource和slaveDataSource的两个具体数据源Bean。将masterDataSource标记为Primary这是Spring的“保底”机制。当系统无法确定用哪个数据源时例如某些框架内部初始化就会使用这个默认的。创建了关键的dynamicDataSourceBean。它把前面两个具体数据源包装成一个Map并设置了默认数据源。这样DynamicDataSource类就能根据Key从这个Map里拿到真正的连接。3.3 MyBatis与事务管理器配置数据源准备好了接下来要告诉MyBatis和Spring事务管理器使用我们刚刚创建的动态数据源。package com.ruoyi.framework.config; import org.mybatis.spring.annotation.MapperScan; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.jdbc.datasource.DataSourceTransactionManager; import org.springframework.transaction.PlatformTransactionManager; import org.springframework.transaction.annotation.EnableTransactionManagement; import javax.sql.DataSource; Configuration EnableTransactionManagement // 启用注解式事务管理 MapperScan(basePackages com.ruoyi.**.mapper) // MyBatis mapper扫描路径 public class MyBatisConfig { /** * 配置事务管理器注意这里注入的是 dynamicDataSource */ Bean public PlatformTransactionManager transactionManager(DataSource dynamicDataSource) { return new DataSourceTransactionManager(dynamicDataSource); } // 如果你的MyBatis配置需要指定SqlSessionFactory也需要注入dynamicDataSource // Bean // public SqlSessionFactory sqlSessionFactory(DataSource dynamicDataSource) throws Exception { // SqlSessionFactoryBean sessionFactory new SqlSessionFactoryBean(); // sessionFactory.setDataSource(dynamicDataSource); // // ... 其他配置如typeAliasesPackage, mapperLocations // return sessionFactory.getObject(); // } }这里有一个至关重要的细节PlatformTransactionManager的Bean注入的是dynamicDataSource而不是任何一个具体的数据源。因为Spring的事务管理是基于一个DataSource的。如果我们注入masterDataSource那么所有的事务包括标记为DataSource(“slave”)的方法都会在master库上开启和提交这会导致严重的数据错乱。让事务管理器绑定到动态数据源上它才能感知到路由变化并在正确的物理连接上管理事务。4. 业务层使用与注解驱动开发配置完成后在业务代码中使用就非常优雅了。4.1 在Service层方法上使用DataSource注解假设有一个查询报表的服务package com.ruoyi.system.service.impl; import com.ruoyi.common.annotation.DataSource; import com.ruoyi.common.enums.DataSourceType; import com.ruoyi.system.domain.ReportData; import com.ruoyi.system.mapper.ReportMapper; import com.ruoyi.system.service.IReportService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import java.util.List; Service public class ReportServiceImpl implements IReportService { Autowired private ReportMapper reportMapper; /** * 此方法使用从库数据源 */ Override DataSource(DataSourceType.SLAVE) // 关键注解 public ListReportData selectReportList(ReportData reportData) { // 这个方法内部的所有数据库操作都会自动路由到 slave 数据源 return reportMapper.selectReportList(reportData); } /** * 此方法使用主库数据源默认可不加注解或显式指定DataSource(DataSourceType.MASTER) */ Override // DataSource(DataSourceType.MASTER) // 可加可不加 public void updateMasterData(SomeData data) { // 这里的操作会在 master 数据源上执行 someMapper.update(data); } }对应的Mapper接口和XML文件无需任何特殊改动就像平时写单数据源一样。MyBatis的SqlSession会从dynamicDataSource获取连接而后者已经通过切面设置好了正确的路由键。4.2 注解生效范围与继承性DataSource注解是基于Spring AOP实现的这意味着它只对Spring代理对象的方法调用生效。以下情况需要特别注意同类方法调用失效在同一个Service类中一个未加注解的方法A直接调用加了DataSource注解的方法B注解是不会生效的。因为A调用B是this.B()绕过了Spring的代理。解决方法是将方法B抽取到另一个Service中或者使用AopContext.currentProxy()来获取当前代理对象再调用不推荐侵入性强。事务注解的协同DataSource和Transactional可以同时使用。执行顺序是先进入DataSource切面设置数据源键再进入Transactional切面开启事务。务必确保这两个注解修饰的是同一个方法并且事务管理器绑定的是dynamicDataSource。无注解默认行为如果一个方法没有标注DataSource那么DynamicDataSourceContextHolder中就没有值DynamicDataSource会返回其设置的默认数据源即我们在配置中设置的setDefaultTargetDataSource通常是master。5. 生产环境进阶配置与深度避坑指南把多数据源跑起来只是第一步要让它稳定可靠地服务于生产环境还需要考虑更多。5.1 连接池参数精细化调优不同业务的数据源其访问模式可能天差地别。主库可能写多读少连接要求高可用、低延迟从库或报表库可能主要用于复杂查询连接占用时间长。切忌使用同一套连接池参数。spring: datasource: druid: master: url: ... # 主库连接池快速响应连接复用率高 initialSize: 10 minIdle: 10 maxActive: 50 # 根据应用服务器线程数和QPS估算 maxWait: 1000 # 等1秒拿不到连接就抛异常避免雪崩 validationQuery: SELECT 1 testWhileIdle: true timeBetweenEvictionRunsMillis: 60000 slave: url: ... # 报表库连接池允许长时间占用但总量控制 initialSize: 5 minIdle: 5 maxActive: 20 # 防止复杂查询拖垮从库 maxWait: 5000 # 查询可以多等一会儿 validationQuery: SELECT 1 testWhileIdle: true timeBetweenEvictionRunsMillis: 120000 # 空闲检查可以慢一些5.2 多数据源下的分布式事务难题这是多数据源架构中最棘手的问题之一。Spring的Transactional在单数据源下是本地事务但在多数据源下它无法保证跨数据源的原子性。例如Transactional public void transfer() { // 操作master数据源 masterAccountMapper.deductMoney(); // 操作slave数据源或另一个master slaveRecordMapper.addRecord(); // 如果这里抛出异常master上的扣款会回滚但slave上的记录不会 }解决方案取决于你的业务容忍度最终一致性推荐接受短时间的不一致通过消息队列、定时任务或日志补偿机制在事后达成一致。这是互联网高并发场景下的主流选择。Seata等分布式事务框架引入中间件通过AT、TCC等模式实现强一致性。这会带来一定的性能损耗和架构复杂度适用于金融、交易等核心场景。若依框架本身不集成Seata需要自行引入和配置。尽量避免跨库事务从业务设计上规避将相关操作收敛到同一个数据源中。5.3 监控与健康检查多个数据源意味着更多的监控点。除了应用本身的监控每个数据库实例、每个连接池的健康状态都需要关注。Druid监控如果使用Druid其内置的监控页面/druid非常强大。你需要为每个DataSourceBean配置StatFilter和WallFilter并在监控页上查看各自的SQL执行情况、连接池状态。Spring Boot Actuator通过/actuator/health端点可以集成数据库健康检查。你需要自定义一个HealthIndicator遍历所有数据源执行validationQuery来检查连通性。关键指标告警对每个数据源的activeCount活跃连接数、waitThreadCount等待线程数设置告警。如果某个数据源的等待线程数持续过高很可能遇到了慢查询或连接泄漏。5.4 常见问题排查实录报错”No qualifying bean of type ‘javax.sql.DataSource’ available”原因Spring容器中存在多个DataSource类型的Bean而某些自动配置类如JPA、MyBatis AutoConfiguration期望只有一个。或者你的MapperScan、EntityManager等注入错了数据源。解决检查是否排除了数据源自动配置spring.autoconfigure.exclude。确保MapperScan、SqlSessionFactoryBean、TransactionManager等Bean明确注入了dynamicDataSource。报错”Could not open JDBC Connection for transaction”原因事务管理器使用了错误的数据源。典型症状是在标记了DataSource(“slave”)的方法上开启事务但连接却尝试从master获取而master的配置可能不对。解决百分百确认你的PlatformTransactionManagerBean定义中DataSource参数注入的是dynamicDataSource。数据源切换偶尔失效全部跑到默认库原因线程上下文污染。DynamicDataSourceContextHolder使用ThreadLocal如果在切面中设置后没有及时清理当线程被线程池复用时残留的数据源键会导致后续无关操作路由错误。或者在异步任务Async中上下文没有正确传递。解决确保DataSourceAspect切面在finally块中清理了ThreadLocal。对于异步场景需要自定义任务装饰器在任务执行前传递并设置数据源键。性能问题在循环中频繁切换数据源场景在一个方法里循环调用多个不同DataSource注解的Service方法。分析每次切换数据源都有微小开销AOP拦截、ThreadLocal操作。虽然不大但在高频循环中会累积。建议重构业务逻辑尽量将访问同一数据源的操作批量执行。或者在更高层的方法上标注数据源在内部通过DataSourceAspect的子切面控制更细粒度的切换较复杂。多数据源与MyBatis-Plus共用时的冲突现象引入了MyBatis-Plus后多数据源配置不生效。原因MyBatis-Plus有自己的自动配置和SqlSessionFactoryBean它会使用Primary的数据源而忽略我们的动态数据源。解决需要手动配置MyBatis-Plus的MybatisSqlSessionFactoryBean并将其数据源设置为我们的dynamicDataSource。同时可能需要排除MyBatis-Plus的部分自动配置。
)
