MyBatis配置多个数据源怎么做？，MyBatis多数据源配置方法有哪些

在我的MyBatis多数据源配置实践中,通过Spring的AbstractRoutingDataSource结合AOP注解，可以优雅地实现动态数据源切换，同时必须严格隔离事务边界，避免数据混淆，这是解决多数据库、读写分离、微服务独立数据库等场景的核心方案，酷番云在支撑高并发业务时，常采用主从+分库的多数据源架构，并利用其云数据库实例的自动故障转移能力，保障动态切换的稳定性。

多数据源的典型场景与核心挑战

实际开发中,多数据源需求通常来自：

• 读写分离：主库写、从库读，提升查询性能。
• 多数据库兼容：业务数据存入MySQL，日志存入ClickHouse。
• 微服务设计：每个服务拥有独立数据库，但服务内部需访问多个库。

核心挑战在于：如何让MyBatis在不同数据源间无缝切换，同时保证事务的一致性和连接的隔离性，如果直接配置多个SqlSessionFactory，代码会变得冗余且难以维护，必须借助动态数据源机制。

基于Spring Boot的配置实现

定义数据源与动态路由

在application.yml中配置多个数据源连接信息：

spring:
  datasource:
    primary:
      url: jdbc:mysql://.../primary
      username: 
      password: 
    secondary:
      url: jdbc:mysql://.../secondary
      username: 
      password: 

创建DynamicDataSource类继承AbstractRoutingDataSource，重写determineCurrentLookupKey()方法，返回当前线程持有的数据源标识。

public class DynamicDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return DataSourceContextHolder.getDataSource();
    }
}

DataSourceContextHolder使用ThreadLocal存储当前线程的数据源key，确保切换的线程隔离。

配置SqlSessionFactory与事务管理器

为每个数据源创建独立的DataSource Bean，并配置对应的SqlSessionFactory和PlatformTransactionManager。关键点：将DynamicDataSource作为默认数据源注入SqlSessionFactory，并将所有实际数据源注册到DynamicDataSource的targetDataSources中。

@Bean
@Primary
public DataSource dynamicDataSource() {
    DynamicDataSource dynamicDataSource = new DynamicDataSource();
    Map<Object, Object> targetDataSources = new HashMap<>();
    targetDataSources.put("primary", primaryDataSource());
    targetDataSources.put("secondary", secondaryDataSource());
    dynamicDataSource.setTargetDataSources(targetDataSources);
    dynamicDataSource.setDefaultTargetDataSource(primaryDataSource());
    return dynamicDataSource;
}

事务管理器同样使用DynamicDataSource，但需注意：如果不指定事务管理器，默认使用primary数据源，对于多数据源事务，需使用@Transactional("transactionManagerPrimary")显式指定。

基于AOP注解的切换实现

定义@DataSource注解，配合AOP切面，在方法执行前设置数据源key，执行后清除。

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface DataSource {
    String value() default "primary";
}

切面中获取注解值,设置到DataSourceContextHolder，并在@After或@Around中清理，这样，业务代码只需在方法上添加@DataSource("secondary")即可切换，实现零侵入的动态路由。

事务管理的最佳实践

多数据源下,事务边界必须清晰。切忌跨数据源的事务操作，否则会导致难以回滚，推荐做法：

• 每个数据源拥有独立的事务管理器,方法上指定

  

  @Transactional("transactionManagerSecondary")。

• 如果确实需要跨库事务,应使用分布式事务方案（如Seata、TCC），但会引入复杂度和性能损耗，在非强一致场景下尽量避免。
• 对于只读操作（如查询历史数据），可以在Service层方法上使用@DataSource("secondary")并配合@Transactional(readOnly = true)，提升性能。

经验分享：在酷番云的部分项目中，我们采用强制路由策略：将写操作默认路由到主库，读操作通过注解切换到从库，并在配置中心动态调整路由规则，避免硬编码，利用酷番云数据库的只读实例自动扩展读能力，结合多数据源配置，实现了秒级扩容。

常见问题与解决方案

• 切换失败，数据源仍指向默认库：检查AOP切面是否生效，确保@DataSource注解在被代理的方法上（内部调用无效）；验证ThreadLocal是否在请求结束时清理，避免内存泄漏。
• 事务回滚后数据源错乱：如果@Transactional和@DataSource同时存在，优先保证事务管理器与数据源匹配，建议在@Transactional注解中明确指定transactionManager。
• 连接池混乱：每个数据源应独立配置连接池参数（如HikariCP），避免共用连接池导致资源竞争。

酷番云独家经验案例

在某电商平台优化中,我们使用酷番云的云数据库MySQL实例作为主库，只读实例作为从库，通过MyBatis多数据源配置实现读写分离。核心步骤：

1. 在酷番云控制台创建主从实例,获取内网地址。
2. 在Spring配置中定义两个数据源,主库用于写操作，从库用于复杂查询。
3. 通过AOP注解,将统计类、报表类查询全部路由到从库，主库压力下降40%。



4. 利用酷番云的自动故障切换功能，当主库宕机时，从库自动提升为主库，只需修改数据源配置即可无缝切换，无需重启应用。

独立见解：多数据源配置不应只是代码层面的技巧，更应该与基础设施结合，酷番云提供的数据库实例分组和连接管理能力，让动态切换更加稳定，同时减少了运维成本。

相关问答模块

问题1：多数据源下，如何保证跨库操作的事务一致性？
答：最简单的方案是避免跨库事务，将需要一致性的操作放在同一个数据源中，如果业务必须跨库，建议使用分布式事务中间件（如Seata的AT模式），但代价是性能下降和复杂度增加，另一种方式是最终一致性，通过消息队列异步处理，牺牲即时一致性换来高可用，在酷番云实践中，我们通常将强关联的业务表放在同一数据库，而将日志、统计等独立数据源使用异步补偿。

问题2：动态数据源和静态配置多个SqlSessionFactory有什么区别？
答：静态配置多个SqlSessionFactory需要在代码中显式注入不同的SqlSessionTemplate，导致业务代码与具体数据源强耦合，扩展性差，而动态数据源通过AbstractRoutingDataSource和AOP，将数据源选择逻辑抽离，业务代码只需关注@DataSource注解，切换灵活、维护简单，尤其适合数据源数量动态变化的场景，酷番云在微服务架构中全面采用动态数据源，结合配置中心，可在线调整路由规则，无需重启服务。

互动环节

如果在实际项目中遇到多数据源配置的难题,欢迎在评论区留言，我们一起探讨解决方案，你对动态数据源的事务管理有什么独到见解？或者想了解更多关于酷番云数据库与多数据源结合的最佳实践？期待你的分享！