MyBatis动态数据源配置教程

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《MyBatis动态数据源路由实现教程》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

动态数据源路由通过Spring的AbstractRoutingDataSource实现，核心步骤包括：1.定义数据源枚举或常量；2.创建继承AbstractRoutingDataSource的动态数据源类并重写determineCurrentLookupKey方法；3.使用ThreadLocal保存当前线程的数据源上下文；4.通过AOP切面拦截方法调用，自动切换数据源；5.在Spring中配置多个实际数据源及事务管理器。此机制支持读写分离、多租户等场景，提升系统可扩展性和灵活性。

MyBatis动态数据源路由，说白了，就是让你的应用在运行时能根据需要切换到不同的数据库连接。这在读写分离、多租户系统或者数据库分库分表场景下，简直是救命稻草。它不像写死在配置文件里那么僵硬，而是能根据业务逻辑或者请求上下文，灵活地决定用哪个库，这对于构建可伸缩、高可用的系统至关重要。

解决方案

实现MyBatis动态数据源路由，核心在于利用Spring的AbstractRoutingDataSource，配合AOP和ThreadLocal来动态切换数据源。

1. 定义数据源枚举或常量： 明确你的所有数据源名称。
2. 创建动态数据源类： 继承AbstractRoutingDataSource，重写determineCurrentLookupKey()方法，这个方法就是决定使用哪个数据源的关键。
3. 使用ThreadLocal保存当前数据源上下文： 在每次请求或业务操作开始时，将目标数据源标识符存入ThreadLocal，并在操作结束后清除。
4. AOP切面进行数据源切换： 定义一个切面，拦截需要动态切换数据源的方法，在方法执行前设置ThreadLocal，方法执行后（无论成功失败）清除ThreadLocal。
5. Spring配置： 将所有实际的数据源配置好，然后将它们注入到你的动态数据源类中，并配置事务管理器。

为什么需要MyBatis动态数据源？深入剖析其应用场景与核心价值

讲真，刚开始做系统的时候，单库单表跑得好好的，根本不会去想什么动态数据源。但随着业务发展，用户量上来，数据量暴涨，或者公司开始搞多租户模式，你就会发现，一个数据库撑不住了。这时候，读写分离、分库分表就成了绕不过去的坎。

动态数据源就是为了解决这些痛点而生的。想象一下，一个电商系统，用户浏览商品是读操作，下单是写操作。如果所有请求都打到同一个数据库，写操作的压力很容易拖垮读操作的响应速度。这时候，我们就可以把读操作引到从库，写操作引到主库，这就是最常见的读写分离。而动态数据源的作用，就是让你在代码层面，不用写死连接池配置，就能根据当前方法是读还是写，自动切换到对应的数据库。

再比如多租户，每个租户的数据可能物理上隔离在不同的数据库实例里，或者至少是不同的Schema。用户A登录进来，所有操作都应该指向租户A的数据库；用户B登录，就指向租户B的数据库。这种场景下，你不可能为每个租户写一套独立的DAO层和Service层，那简直是灾难。动态数据源通过在请求入口处（比如Filter或Interceptor）解析租户ID，然后设置对应的数据源，就能实现一套代码服务多个租户。

它的核心价值在于“解耦”和“灵活性”。它把数据源的选择逻辑从业务代码中剥离出来，集中管理，这样当数据库架构调整时，业务代码几乎不用改动，只需要修改数据源的配置和路由规则，大大降低了维护成本和系统复杂度。我个人觉得，这玩意儿是系统演进到一定规模后，提升架构优雅度的关键一环。

如何实现一个基于Spring AbstractRoutingDataSource的动态数据源？代码与配置详解

实现动态数据源，我们主要围绕AbstractRoutingDataSource这个Spring提供的抽象类来展开。它的核心就是那个determineCurrentLookupKey()方法，我们得告诉它，当前请求应该用哪个数据源的key。

首先，我们需要一个地方来存放当前线程要使用的数据源标识。ThreadLocal是完美的选择，它能保证每个线程的数据独立性。

// DataSourceContextHolder.java
public class DataSourceContextHolder {
    private static final ThreadLocal CONTEXT_HOLDER = new ThreadLocal<>();

    public static void setDataSourceType(String dataSourceType) {
        CONTEXT_HOLDER.set(dataSourceType);
    }

    public static String getDataSourceType() {
        return CONTEXT_HOLDER.get();
    }

    public static void clearDataSourceType() {
        CONTEXT_HOLDER.remove();
    }
}

接下来，创建我们的动态数据源类，继承AbstractRoutingDataSource：

// DynamicDataSource.java
public class DynamicDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        // 从ThreadLocal中获取当前数据源的key
        return DataSourceContextHolder.getDataSourceType();
    }
}

然后是Spring的配置。你需要定义多个实际的数据源（比如主库、从库），然后把它们注入到DynamicDataSource中。

这段配置把dynamicDataSource作为MyBatis的实际数据源，这样MyBatis在执行SQL时，就会通过determineCurrentLookupKey()方法找到对应的连接。

利用AOP实现数据源的自动化切换与事务管理考量

光有动态数据源和ThreadLocal还不够，我们总不能在每个业务方法里手动调用DataSourceContextHolder.setDataSourceType()吧？那也太蠢了。这时候，AOP就派上用场了。我们可以定义一个自定义注解，标记需要切换数据源的方法，然后用AOP来拦截这些方法。

首先，定义一个注解：

// @TargetDataSource.java
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface TargetDataSource {
    String value() default "master"; // 默认使用master数据源
}

然后，创建AOP切面：

// DynamicDataSourceAspect.java
@Aspect
@Component
public class DynamicDataSourceAspect {

    // 定义切点，匹配所有带有@TargetDataSource注解的方法
    @Pointcut("@annotation(com.example.annotation.TargetDataSource)")
    public void dataSourcePointCut() {}

    @Around("dataSourcePointCut()")
    public Object around(ProceedingJoinPoint point) throws Throwable {
        MethodSignature signature = (MethodSignature) point.getSignature();
        Method method = signature.getMethod();

        TargetDataSource targetDataSource = method.getAnnotation(TargetDataSource.class);
        if (targetDataSource == null) {
            // 如果方法上没有注解，尝试获取类上的注解
            targetDataSource = method.getDeclaringClass().getAnnotation(TargetDataSource.class);
        }

        if (targetDataSource != null) {
            String dataSourceType = targetDataSource.value();
            DataSourceContextHolder.setDataSourceType(dataSourceType);
            System.out.println("切换到数据源: " + dataSourceType); // 调试信息
        }

        try {
            return point.proceed(); // 执行目标方法
        } finally {
            // 确保在方法执行完成后清除ThreadLocal，避免内存泄漏或数据源混乱
            DataSourceContextHolder.clearDataSourceType();
            System.out.println("数据源已清除"); // 调试信息
        }
    }
}

别忘了在Spring配置中启用AOP：

现在，你只需要在Service层的方法上加上@TargetDataSource("slave")，这个方法执行时就会自动切换到从库。

关于事务管理： 这是一个比较容易踩坑的地方。Spring的事务管理器是基于DataSource的。如果你在一个事务中，先访问了主库，又访问了从库，那么这两个操作将不在同一个事务中。DataSourceTransactionManager绑定的是单个数据源的连接。对于跨数据源的事务，你需要考虑分布式事务（如XA协议，但性能开销大）或者采用柔性事务方案。在读写分离场景下，通常读操作不涉及事务，写操作才需要事务，所以这种AOP切换方式是没问题的。但如果你的业务逻辑确实需要在同一个事务中操作多个不同数据源，那这套方案需要更复杂的改造，比如引入Atomikos或JTA等分布式事务管理器。不过，大多数情况下，我们只会在读写分离中用到，写操作走一个库的事务，读操作不走事务或者走另一个库的事务，这就足够了。

这个方案，在实际项目中用起来非常顺手，既保证了代码的整洁，又提供了强大的数据源切换能力。当然，它也有自己的局限性，比如对分布式事务的支持。但对于大部分读写分离和多租户的场景，它完全够用，而且实现起来相对简单直接。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。