Spring Boot多数据源配置与动态路由实战指南

1. 多数据源场景的现实需求

在真实的企业级应用开发中，单一数据库往往无法满足业务需求。我经历过一个典型的电商项目，需要同时连接订单库、用户库和商品库，这三个库分别部署在不同的物理服务器上，甚至使用了不同类型的数据库（MySQL、PostgreSQL和MongoDB）。这种场景下，多数据源管理就成了必须解决的架构问题。

Spring Boot的自动配置为我们提供了开箱即用的单数据源支持，但面对多数据源时，开发者需要手动处理数据源的创建、管理和切换。这不仅仅是简单的配置多个DataSource bean那么简单，更需要考虑事务管理、连接池优化、运行时动态切换等一系列复杂问题。

2. 基础多数据源配置实战

2.1 数据源定义与Bean声明

我们先从最基本的静态多数据源配置开始。在application.yml中定义两个数据源：

yaml复制spring:
  datasource:
    primary:
      url: jdbc:mysql://localhost:3306/primary_db
      username: root
      password: password
      driver-class-name: com.mysql.jdbc.Driver
    secondary:
      url: jdbc:mysql://localhost:3306/secondary_db
      username: root
      password: password
      driver-class-name: com.mysql.jdbc.Driver

然后在配置类中声明对应的Bean：

java复制@Configuration
public class DataSourceConfig {
    
    @Bean
    @Primary
    @ConfigurationProperties("spring.datasource.primary")
    public DataSource primaryDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    @ConfigurationProperties("spring.datasource.secondary")
    public DataSource secondaryDataSource() {
        return DataSourceBuilder.create().build();
    }
}

这里有几个关键点需要注意：

1. 必须使用@Primary标记一个主数据源，这是Spring的强制要求
2. @ConfigurationProperties会自动绑定配置文件中的前缀属性
3. 实际项目中应该使用更专业的连接池如HikariCP

2.2 多数据源事务管理挑战

当引入多个数据源后，事务管理变得复杂起来。Spring的@Transactional注解默认只能处理单个数据源的事务。如果业务方法需要跨多个数据源操作，就需要引入分布式事务解决方案。

对于不强求ACID的场景，可以使用"最终一致性"模式。我曾在一个金融项目中采用以下方案：

java复制@Service
public class OrderService {
    @Transactional("primaryTransactionManager")
    public void createOrder(Order order) {
        // 操作主库
    }
    
    @Transactional("secondaryTransactionManager")
    public void updateInventory(Inventory inventory) {
        // 操作从库
    }
    
    public void placeOrder(Order order) {
        createOrder(order);
        // 这里可以加入消息队列或补偿机制
        updateInventory(order.getInventory());
    }
}

每个数据源需要配置独立的事务管理器：

java复制@Bean
@Primary
public PlatformTransactionManager primaryTransactionManager(
        @Qualifier("primaryDataSource") DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

@Bean
public PlatformTransactionManager secondaryTransactionManager(
        @Qualifier("secondaryDataSource") DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

3. 动态数据源路由实现

3.1 AbstractRoutingDataSource原理剖析

Spring提供了AbstractRoutingDataSource这个抽象类来实现动态数据源路由。它的核心思想是：

1. 维护一个targetDataSources Map，保存所有备选数据源
2. 通过determineCurrentLookupKey()方法决定当前使用哪个数据源
3. 每次数据库操作前会调用该方法获取数据源key

实现一个简单的版本：

java复制public class DynamicDataSource extends AbstractRoutingDataSource {
    
    private static final ThreadLocal<String> CONTEXT_HOLDER = 
        new ThreadLocal<>();
    
    public static void setDataSourceKey(String key) {
        CONTEXT_HOLDER.set(key);
    }
    
    public static void clearDataSourceKey() {
        CONTEXT_HOLDER.remove();
    }
    
    @Override
    protected Object determineCurrentLookupKey() {
        return CONTEXT_HOLDER.get();
    }
}

3.2 完整动态数据源配置

完整的配置类实现：

java复制@Configuration
@EnableTransactionManagement
public class DynamicDataSourceConfig {
    
    @Bean
    @ConfigurationProperties("spring.datasource.primary")
    public DataSource primaryDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    @ConfigurationProperties("spring.datasource.secondary")
    public DataSource secondaryDataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    public DataSource dynamicDataSource(
            @Qualifier("primaryDataSource") DataSource primary,
            @Qualifier("secondaryDataSource") DataSource secondary) {
        
        Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put("primary", primary);
        targetDataSources.put("secondary", secondary);
        
        DynamicDataSource routingDataSource = new DynamicDataSource();
        routingDataSource.setDefaultTargetDataSource(primary);
        routingDataSource.setTargetDataSources(targetDataSources);
        
        return routingDataSource;
    }
    
    @Bean
    public PlatformTransactionManager transactionManager(
            @Qualifier("dynamicDataSource") DataSource dataSource) {
        return new DataSourceTransactionManager(dataSource);
    }
}

3.3 使用AOP实现自动切换

手动调用DynamicDataSource.setDataSourceKey()不够优雅，我们可以用AOP实现自动切换：

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DataSourceSelector {
    String value() default "primary";
}

@Aspect
@Component
public class DataSourceAspect {
    
    @Before("@annotation(selector)")
    public void before(JoinPoint point, DataSourceSelector selector) {
        DynamicDataSource.setDataSourceKey(selector.value());
    }
    
    @After("@annotation(selector)")
    public void after(JoinPoint point, DataSourceSelector selector) {
        DynamicDataSource.clearDataSourceKey();
    }
}

使用示例：

java复制@Service
public class UserService {
    
    @DataSourceSelector("primary")
    public User getPrimaryUser(Long id) {
        // 使用主库查询
    }
    
    @DataSourceSelector("secondary")
    public User getSecondaryUser(Long id) {
        // 使用从库查询
    }
}

4. 生产环境中的进阶问题

4.1 连接池配置优化

多数据源环境下，连接池配置尤为重要。我推荐使用HikariCP，并为每个数据源独立配置：

yaml复制spring:
  datasource:
    primary:
      hikari:
        maximum-pool-size: 20
        minimum-idle: 5
        connection-timeout: 30000
        idle-timeout: 600000
        max-lifetime: 1800000
    secondary:
      hikari:
        maximum-pool-size: 10
        minimum-idle: 2
        connection-timeout: 30000
        idle-timeout: 600000
        max-lifetime: 1800000

4.2 多数据源与MyBatis集成

当使用MyBatis时，需要为每个数据源配置独立的SqlSessionFactory：

java复制@Configuration
@MapperScan(basePackages = "com.example.mapper.primary", 
           sqlSessionFactoryRef = "primarySqlSessionFactory")
public class PrimaryMyBatisConfig {
    
    @Bean
    public SqlSessionFactory primarySqlSessionFactory(
            @Qualifier("primaryDataSource") DataSource dataSource) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setDataSource(dataSource);
        bean.setMapperLocations(new PathMatchingResourcePatternResolver()
                .getResources("classpath:mapper/primary/*.xml"));
        return bean.getObject();
    }
}

4.3 动态数据源的健康检查

在Spring Boot Actuator中注册自定义健康检查：

java复制@Component
public class DataSourceHealthContributor implements CompositeHealthContributor {
    
    private final Map<String, HealthContributor> contributors = new HashMap<>();
    
    public DataSourceHealthContributor(
            @Qualifier("primaryDataSource") DataSource primary,
            @Qualifier("secondaryDataSource") DataSource secondary) {
        
        contributors.put("primary", DataSourceHealthIndicator(primary));
        contributors.put("secondary", DataSourceHealthIndicator(secondary));
    }
    
    @Override
    public HealthContributor getContributor(String name) {
        return contributors.get(name);
    }
    
    @Override
    public Iterator<NamedContributor<HealthContributor>> iterator() {
        return contributors.entrySet().stream()
                .map(entry -> NamedContributor.of(entry.getKey(), entry.getValue()))
                .iterator();
    }
}

5. 常见问题排查指南

5.1 事务不生效问题

在多数据源环境下，最常见的问题是事务不生效。排查步骤：

1. 确认@EnableTransactionManagement注解已添加
2. 检查事务管理器是否绑定到正确的数据源
3. 确保@Transactional注解指定了正确的事务管理器
4. 检查方法是否为public（Spring AOP限制）

5.2 数据源切换失败

如果发现数据源切换没有生效：

1. 检查AOP顺序，确保数据源切换切面在事务切面之前执行
2. 确认ThreadLocal没有被意外清除
3. 检查是否有嵌套方法调用导致切面失效

5.3 连接泄漏问题

多数据源环境下连接泄漏更难排查：

1. 为每个数据源启用连接泄漏检测
2. 使用Druid的监控功能跟踪连接获取堆栈
3. 确保所有Connection、Statement、ResultSet都在finally块中关闭

我在实际项目中发现，使用以下工具组合效果最佳：

• HikariCP的leakDetectionThreshold
• Spring的JDBC拦截器
• Micrometer的指标监控

6. 性能优化实战经验

6.1 读写分离实现

基于动态数据源实现读写分离：

java复制@Aspect
@Component
public class ReadWriteSeparationAspect {
    
    @Before("execution(* com.example.repository.*.*(..)) && " +
            "@annotation(org.springframework.transaction.annotation.Transactional)")
    public void before(JoinPoint point) {
        TransactionAttribute txAttr = TransactionAspectSupport
                .currentTransactionStatus()
                .getTransactionAttribute();
        
        if (txAttr.isReadOnly()) {
            DynamicDataSource.setDataSourceKey("secondary");
        } else {
            DynamicDataSource.setDataSourceKey("primary");
        }
    }
    
    @After("execution(* com.example.repository.*.*(..)) && " +
           "@annotation(org.springframework.transaction.annotation.Transactional)")
    public void after(JoinPoint point) {
        DynamicDataSource.clearDataSourceKey();
    }
}

6.2 分库分表路由策略

对于更复杂的分库分表场景，可以实现自定义路由策略：

java复制public class ShardingDataSourceRouter {
    
    private static final int DB_COUNT = 4;
    private static final int TABLE_COUNT = 8;
    
    public static String determineDataSourceKey(Long id) {
        int dbIndex = (int)(id % DB_COUNT);
        return "ds_" + dbIndex;
    }
    
    public static String determineTableName(Long id) {
        int tableIndex = (int)(id % TABLE_COUNT);
        return "user_" + tableIndex;
    }
}

6.3 多数据源与缓存协同

在多数据源环境下使用缓存需要特别注意一致性问题：

1. 写操作后立即清除相关缓存
2. 读操作先查缓存，缓存未命中时根据路由规则查询对应数据源
3. 考虑使用二级缓存，如Redis + 本地缓存

我通常采用的缓存策略：

java复制@Service
public class UserService {
    
    @Cacheable(value = "users", key = "#id", unless = "#result == null")
    @DataSourceSelector
    public User getUser(Long id) {
        // 根据id路由到正确的数据源查询
        String dataSourceKey = ShardingDataSourceRouter.determineDataSourceKey(id);
        DynamicDataSource.setDataSourceKey(dataSourceKey);
        try {
            return userMapper.selectById(id);
        } finally {
            DynamicDataSource.clearDataSourceKey();
        }
    }
    
    @CacheEvict(value = "users", key = "#user.id")
    @Transactional
    public void updateUser(User user) {
        String dataSourceKey = ShardingDataSourceRouter.determineDataSourceKey(user.getId());
        DynamicDataSource.setDataSourceKey(dataSourceKey);
        try {
            userMapper.updateById(user);
        } finally {
            DynamicDataSource.clearDataSourceKey();
        }
    }
}

7. 替代方案比较

7.1 开源框架对比

除了自己实现，还可以考虑以下开源方案：

1. dynamic-datasource-spring-boot-starter

   • 优点：功能全面，文档丰富
   • 缺点：学习曲线较陡

2. sharding-jdbc

   • 优点：分库分表功能强大
   • 缺点：配置复杂

3. MyCat

   • 优点：中间件方案，对应用透明
   • 缺点：需要额外维护中间件

7.2 自研 vs 开源选择建议

根据项目规模和技术实力选择：

• 小型项目：推荐使用dynamic-datasource
• 中型项目：可以考虑自研简单方案
• 大型分布式系统：建议使用sharding-jdbc或MyCat

我在实际项目中的选择标准：

1. 团队对框架的熟悉程度
2. 是否需要分库分表
3. 未来扩展需求
4. 运维成本考量

8. 微服务架构下的演进

8.1 从多数据源到服务拆分

随着业务发展，多数据源方案可能演变为微服务拆分：

1. 每个数据源对应一个独立服务
2. 通过API网关聚合数据
3. 使用分布式事务解决一致性问题

8.2 分布式事务解决方案

常见方案对比：

1. 2PC/3PC：强一致，性能差
2. TCC：需要业务改造
3. SAGA：最终一致，实现简单
4. 本地消息表：可靠性高

我最近的一个项目采用了Seata的AT模式：

java复制@GlobalTransactional
public void crossServiceOperation() {
    serviceA.update();
    serviceB.update();
}

8.3 数据同步与一致性保障

在多数据源/多服务环境下，数据同步策略：

1. 数据库binlog同步（如Canal）
2. 消息队列（Kafka/RocketMQ）
3. 定时任务补偿

实际项目中我采用的混合方案：

plantuml复制@startuml
PrimaryDB -> Canal : Binlog
Canal -> Kafka : Change Events
Kafka -> SecondaryDB : Consumer Group
Kafka -> Elasticsearch : Consumer Group
@enduml

9. 监控与运维实践

9.1 多数据源监控指标

关键监控指标：

1. 连接池使用率
2. 查询响应时间分布
3. 事务成功率
4. 慢查询统计

Prometheus配置示例：

yaml复制metrics:
  enabled: true
  export:
    jmx:
      enabled: true
  hikari:
    enabled: true

9.2 告警策略配置

推荐告警规则：

1. 连接池使用率 > 80%持续5分钟
2. 平均查询时间 > 500ms
3. 事务失败率 > 1%
4. 连接等待时间 > 1s

9.3 性能调优案例

一个真实调优案例：

问题现象：系统高峰期响应变慢，从库延迟严重

排查过程：

1. 发现从库查询没有走索引
2. 连接池配置不合理
3. 没有做读写分离

解决方案：

1. 优化慢查询
2. 调整连接池参数
3. 实现自动读写分离
4. 增加从库数量

优化后效果：

• 平均响应时间从1200ms降到200ms
• 高峰期错误率从5%降到0.1%
• 资源利用率提高30%

10. 未来演进思考

随着云原生技术的发展，多数据源管理也出现新趋势：

1. Service Mesh对数据库流量的治理
2. 云数据库代理的智能路由
3. 基于机器学习的自适应负载均衡

我在技术选型时会考虑：

1. 是否真的需要多数据源？能否通过其他方案解决？
2. 团队的运维能力边界在哪里？
3. 长期的技术债务成本如何？

最近尝试将部分系统迁移到Vitess，它提供了很好的分片管理能力，但迁移成本较高，适合大规模系统。对于中小型项目，经过良好封装的动态数据源方案仍然是性价比最高的选择。