1. 多数据源场景的现实需求
在企业级应用开发中，多数据源的需求几乎无处不在。我经历过一个典型的电商项目，需要同时连接商品数据库、用户数据库和订单数据库，这三个数据库分别部署在不同的服务器上，甚至使用了不同的数据库引擎（MySQL、PostgreSQL和MongoDB）。这种架构设计往往源于以下几个现实考量：
- 数据隔离与安全：核心业务数据（如支付信息）需要与普通业务数据物理隔离
- 性能优化：高频访问的热数据（如商品信息）与低频访问的冷数据（如日志）分离
- 技术异构：不同业务模块可能更适合不同的存储方案（如关系型与非关系型）
- 历史遗留系统整合：并购或系统演进过程中产生的多数据库并存
重要提示：多数据源不是银弹。引入前务必评估是否真的需要，因为这会增加系统复杂度和维护成本。我曾见过一个团队为了"架构先进"强行拆分单库，结果事务管理和联表查询成了噩梦。
2. Spring Boot多数据源实现方案选型
2.1 主流技术路线对比
经过多个项目的实践验证，我总结出三种主流实现方式及其适用场景：
| 方案类型 | 代表实现 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 手动配置型 | 多个DataSource Bean | 灵活可控，适合复杂场景 | 需要自行处理事务管理 | 需要精细控制连接池的场景 |
| 注解驱动型 | @DS注解（MyBatis-plus） | 声明式使用，代码侵入性低 | 动态切换有性能损耗 | 简单CRUD业务 |
| 抽象路由型 | AbstractRoutingDataSource | 一次配置多处使用 | 学习曲线较陡 | 中大型复杂系统 |
2.2 核心组件依赖
无论选择哪种方案，以下依赖都是基础必备（以Gradle为例）：
groovy复制implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'com.zaxxer:HikariCP:5.0.1' // 推荐连接池
runtimeOnly 'mysql:mysql-connector-java:8.0.33'
runtimeOnly 'org.postgresql:postgresql:42.6.0'
3. 实战：基于AbstractRoutingDataSource的智能路由方案
3.1 数据源配置详解
首先在application.yml中定义主从数据源（示例使用MySQL）：
yaml复制spring:
datasource:
master:
jdbc-url: jdbc:mysql://master-db:3306/core?useSSL=false
username: admin
password: Master@123
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 20
slave:
jdbc-url: jdbc:mysql://slave-db:3306/report?useSSL=false
username: reporter
password: Slave@456
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
maximum-pool-size: 15
3.2 动态数据源路由实现
创建线程安全的数据源上下文持有器：
java复制public class DataSourceContextHolder {
private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();
public static void setDataSource(String name) {
CONTEXT.set(name);
}
public static String getDataSource() {
return CONTEXT.get();
}
public static void clear() {
CONTEXT.remove();
}
}
实现抽象路由数据源：
java复制public class DynamicDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey() {
return DataSourceContextHolder.getDataSource();
}
}
3.3 数据源初始化配置
java复制@Configuration
public class DataSourceConfig {
@Bean
@ConfigurationProperties("spring.datasource.master")
public DataSource masterDataSource() {
return DataSourceBuilder.create().type(HikariDataSource.class).build();
}
@Bean
@ConfigurationProperties("spring.datasource.slave")
public DataSource slaveDataSource() {
return DataSourceBuilder.create().type(HikariDataSource.class).build();
}
@Bean
public DataSource dynamicDataSource(
@Qualifier("masterDataSource") DataSource master,
@Qualifier("slaveDataSource") DataSource slave) {
Map<Object, Object> targetDataSources = new HashMap<>();
targetDataSources.put("master", master);
targetDataSources.put("slave", slave);
DynamicDataSource ds = new DynamicDataSource();
ds.setDefaultTargetDataSource(master); // 默认数据源
ds.setTargetDataSources(targetDataSources);
ds.afterPropertiesSet();
return ds;
}
}
4. 事务管理的陷阱与解决方案
4.1 跨数据源事务问题
当业务需要同时操作多个数据源时，常规的@Transactional注解会失效。我曾在库存扣减和订单创建的场景中踩过这个坑，导致数据不一致。解决方案有两种：
方案一：分布式事务（重型方案）
java复制// 使用Atomikos实现JTA
@Bean
public PlatformTransactionManager transactionManager() {
return new JtaTransactionManager();
}
方案二：最终一致性（推荐）
java复制// 使用事务日志表+定时任务补偿
public void placeOrder(Order order) {
try {
DataSourceContextHolder.setDataSource("master");
orderRepository.save(order);
DataSourceContextHolder.setDataSource("inventory");
inventoryService.reduceStock(order.getItems());
} finally {
DataSourceContextHolder.clear();
}
// 记录事务日志
transactionLogService.logOperation(...);
}
4.2 事务传播行为调整
在多数据源环境下，PROPAGATION_REQUIRES_NEW可能会产生意外行为。建议：
- 读操作使用PROPAGATION_SUPPORTS
- 写操作使用PROPAGATION_REQUIRED
- 避免嵌套事务跨数据源
5. 性能优化实战技巧
5.1 连接池调优参数
根据线上监控数据，我总结出这些黄金配置（以HikariCP为例）：
yaml复制spring.datasource.hikari:
maximum-pool-size: ${DB_MAX_POOL:10} # 建议CPU核心数*2 + 有效磁盘数
minimum-idle: 3
idle-timeout: 60000
max-lifetime: 1800000
connection-timeout: 3000
validation-timeout: 1000
leak-detection-threshold: 5000 # 生产环境建议设置
5.2 多数据源监控方案
在Spring Boot Actuator基础上增加以下配置：
java复制@Bean
public DataSourcePoolMetrics masterDataSourceMetrics(
@Qualifier("masterDataSource") DataSource dataSource) {
return new DataSourcePoolMetrics(dataSource, "master", "master");
}
@Bean
public DataSourcePoolMetrics slaveDataSourceMetrics(
@Qualifier("slaveDataSource") DataSource dataSource) {
return new DataSourcePoolMetrics(dataSource, "slave", "slave");
}
通过/metrics端点可以获取关键指标：
- datasource.master.active: 活动连接数
- datasource.slave.usage: 连接使用率
- datasource.master.max: 最大连接数
6. 常见故障排查指南
6.1 连接泄露诊断
症状：连接数持续增长不释放
排查步骤：
- 在测试环境设置leakDetectionThreshold=3000
- 重现操作后检查日志中的"Connection leak detection"警告
- 使用jstack分析线程栈，找到未关闭的连接
6.2 切换失效问题
典型报错："No qualifying bean of type 'javax.sql.DataSource' available"
解决方案检查清单：
- 确保@Primary注解只标注在默认数据源上
- 检查AOP切面顺序是否正确（事务切面要最后执行）
- 验证ThreadLocal是否在finally块中被清除
6.3 跨库查询优化
对于需要关联查询多个数据源的场景，建议：
- 使用内存Join（数据量小时）
java复制public List<OrderDTO> getOrderWithUserInfo(Long orderId) {
DataSourceContextHolder.setDataSource("order");
Order order = orderRepository.findById(orderId);
DataSourceContextHolder.setDataSource("user");
User user = userRepository.findById(order.getUserId());
return assembleDTO(order, user);
}
- 考虑使用数据同步工具（如Debezium）构建查询视图
- 对于实时性要求不高的场景，使用Elasticsearch构建宽表
7. 进阶：多租户数据源动态注册
在SAAS系统中，我实现过按租户动态注册数据源的方案。核心思路：
java复制public void registerTenantDataSource(String tenantId) {
DataSource newDs = buildDataSource(tenantConfig);
DynamicDataSource ds = (DynamicDataSource)applicationContext.getBean("dynamicDataSource");
Map<Object, Object> targetSources = new HashMap<>(ds.getResolvedDataSources());
targetSources.put(tenantId, newDs);
ds.setTargetDataSources(targetSources);
ds.afterPropertiesSet();
// 热加载相关Mapper接口
sqlSessionFactory.refreshMapper(tenantId);
}
关键点：
- 使用ConcurrentHashMap保证线程安全
- 每次修改后必须调用afterPropertiesSet()
- 需要同步刷新MyBatis映射器
8. 生产环境注意事项
-
连接串优化：建议添加以下MySQL连接参数
code复制jdbc:mysql://host/db?useSSL=false&allowPublicKeyRetrieval=true&useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&autoReconnect=true&failOverReadOnly=false&maxReconnects=10 -
防御性编程：所有数据源操作添加fallback逻辑
java复制public Object queryFromSlave(Supplier<Object> query) { String originalDs = DataSourceContextHolder.getDataSource(); try { DataSourceContextHolder.setDataSource("slave"); return query.get(); } catch (Exception e) { log.warn("Slave query failed, fallback to master", e); DataSourceContextHolder.setDataSource("master"); return query.get(); } finally { DataSourceContextHolder.setDataSource(originalDs); } } -
启动顺序控制：在ApplicationRunner中验证所有数据源连通性
java复制@Bean public ApplicationRunner dataSourceValidator() { return args -> { DataSource master = applicationContext.getBean("masterDataSource", DataSource.class); try (Connection conn = master.getConnection()) { // 执行简单查询验证 } // 其他数据源验证... }; }
经过多个项目的迭代，我发现最稳定的多数据源架构应该具备以下特征：
- 默认数据源明确且稳定
- 从库查询有自动降级机制
- 每个数据源有独立的监控指标
- 关键操作都有事务日志记录
- 定期执行连接健康检查