Spring Boot多数据源配置问题与解决方案

1. 多数据源配置的典型场景与核心痛点

在Spring Boot项目中，多数据源配置是一个高频需求。我最近在金融支付系统中就遇到了这样的场景：核心交易数据需要存储在PostgreSQL集群保证事务一致性，而用户行为日志需要写入MySQL做分析统计。这种异构数据库混用的情况，正是dynamic-datasource这类框架大显身手的时机。

但升级到Spring Boot 3.4.3后，项目启动时突然抛出"Failed to configure a DataSource"异常。控制台明确提示PostgreSQL驱动加载失败，但检查pom.xml依赖明明存在。这种看似简单的配置冲突，背后其实暗藏玄机：

1. 自动装配冲突：Spring Boot 3.x对自动配置机制做了优化，而dynamic-datasource 3.6.1版本尚未完全适配
2. 驱动加载顺序：PostgreSQL驱动在特定条件下会被HikariCP池提前初始化
3. 方言识别异常：MyBatis-Plus的方言探测器与dynamic-datasource的代理逻辑产生冲突

关键提示：这个问题在同时使用PostgreSQL和MySQL时必现，但仅用MySQL或Oracle时却表现正常，说明与特定数据库类型有关。

2. 环境准备与问题复现

2.1 基础环境搭建

先来看最小复现环境配置。创建一个Spring Boot 3.4.3项目，关键依赖如下：

xml复制<dependencies>
    <!-- Spring Boot Starter -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    
    <!-- 数据源相关 -->
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
        <version>3.6.1</version>
    </dependency>
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
        <scope>runtime</scope>
    </dependency>
    
    <!-- MyBatis-Plus -->
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.3.1</version>
    </dependency>
</dependencies>

2.2 配置多数据源

application.yml配置示例：

yaml复制spring:
  datasource:
    dynamic:
      primary: master 
      datasource:
        master:
          url: jdbc:postgresql://localhost:5432/payment_core
          username: postgres
          password: 123456
          driver-class-name: org.postgresql.Driver
        slave:
          url: jdbc:mysql://localhost:3306/log_db
          username: root
          password: 123456
          driver-class-name: com.mysql.cj.jdbc.Driver

启动时会看到这样的错误栈：

code复制org.postgresql.util.PSQLException: 不良的类型值 int :94054000619622242
at org.postgresql.jdbc.PgPreparedStatement.setInt(PgPreparedStatement.java:308)

3. 问题根源深度解析

3.1 驱动加载时序问题

通过DEBUG模式跟踪，发现PostgreSQL驱动在HikariCP初始化阶段就被加载，而此时dynamic-datasource尚未完成代理包装。关键断点位置：

1. HikariDataSource.getConnection() 先于 DynamicDataSourceProvider.loadDataSources()
2. PostgreSQL驱动在注册时对类型转换做了严格校验
3. dynamic-datasource的代理层修改了原始Connection的行为

3.2 类型系统冲突

PostgreSQL的JDBC驱动对数据类型校验非常严格。当dynamic-datasource尝试包装Connection时，某些元数据操作会导致类型转换异常。具体表现为：

• 包装后的Statement对象与原始类型不匹配
• 预处理参数的类型推导失效
• 事务隔离级别传递异常

3.3 Spring Boot 3.x的自动配置变化

Spring Boot 3.4.3中，数据源自动配置顺序发生变化：

1. DataSourceAutoConfiguration 现在会提前初始化
2. @ConditionalOnMissingBean 的判定逻辑更严格
3. 代理类检测机制会影响Bean的注册顺序

4. 完整解决方案

4.1 方案一：强制初始化顺序（推荐）

在启动类添加注解控制初始化顺序：

java复制@SpringBootApplication
@AutoConfigureBefore({DataSourceAutoConfiguration.class})
@AutoConfigureAfter({DynamicDataSourceAutoConfiguration.class})
public class PaymentApplication {
    public static void main(String[] args) {
        SpringApplication.run(PaymentApplication.class, args);
    }
}

4.2 方案二：自定义数据源配置

完全禁用Spring Boot的自动配置，手动创建数据源：

java复制@Configuration
@EnableTransactionManagement
@MapperScan("com.example.mapper")
public class DataSourceConfig {
    
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.dynamic.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.dynamic.datasource.slave")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    @Primary
    public DataSource dynamicDataSource(DataSource masterDataSource, DataSource slaveDataSource) {
        Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put("master", masterDataSource);
        targetDataSources.put("slave", slaveDataSource);
        return new DynamicRoutingDataSource(masterDataSource, targetDataSources);
    }
}

4.3 方案三：版本降级兼容

如果暂时无法修改代码，可以回退到稳定版本组合：

xml复制<properties>
    <spring-boot.version>2.7.18</spring-boot.version>
    <dynamic-datasource.version>3.5.2</dynamic-datasource.version>
</properties>

5. 生产环境验证与性能调优

5.1 连接池参数优化

多数据源环境下，每个数据源需要独立配置连接池：

yaml复制spring:
  datasource:
    dynamic:
      datasource:
        master:
          hikari:
            maximum-pool-size: 20
            minimum-idle: 5
            connection-timeout: 30000
            idle-timeout: 600000
        slave:
          hikari:
            maximum-pool-size: 30
            minimum-idle: 10

5.2 事务管理增强

需要显式指定事务管理器：

java复制@Bean
public PlatformTransactionManager transactionManager(DynamicDataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

5.3 监控集成

建议添加以下监控指标：

1. 每个数据源的活跃连接数
2. SQL执行耗时分布
3. 事务提交/回滚统计

java复制@Bean
public MeterRegistryCustomizer<MeterRegistry> metrics() {
    return registry -> {
        HikariDataSource master = (HikariDataSource) dynamicDataSource
            .getDataSource("master");
        HikariDataSource slave = (HikariDataSource) dynamicDataSource
            .getDataSource("slave");
        
        new HikariMetrics(master, "master").bindTo(registry);
        new HikariMetrics(slave, "slave").bindTo(registry);
    };
}

6. 扩展思考与最佳实践

6.1 多租户场景下的特殊处理

对于SaaS系统，建议采用这样的数据源路由策略：

java复制public class TenantDataSourceSelector {
    
    public static String determineCurrentLookupKey() {
        String tenantId = TenantContext.getCurrentTenant();
        if (StringUtils.isEmpty(tenantId)) {
            return "master";
        }
        return tenantId + "_slave";
    }
}

6.2 读写分离实现技巧

通过AOP实现自动路由：

java复制@Around("@annotation(readOnly)")
public Object routeToSlave(ProceedingJoinPoint pjp, ReadOnly readOnly) throws Throwable {
    DynamicDataSourceContextHolder.push("slave");
    try {
        return pjp.proceed();
    } finally {
        DynamicDataSourceContextHolder.poll();
    }
}

6.3 灾备切换方案

建议实现这样的故障转移机制：

1. 监控主库健康状态
2. 自动切换至备用数据源
3. 记录切换日志用于事后分析

java复制public class FailoverDataSource extends AbstractDataSource {
    
    @Override
    public Connection getConnection() throws SQLException {
        try {
            return primaryDataSource.getConnection();
        } catch (SQLException e) {
            log.warn("Primary failed, switch to standby");
            return standbyDataSource.getConnection();
        }
    }
}

在实际项目中，我发现这类配置问题往往出现在版本升级时。建议团队建立完善的升级检查清单，特别关注自动配置类的变化。对于关键业务系统，可以先在预发布环境进行全量接口测试，确保数据访问层稳定后再上线生产。