动态数据源路由通过spring的abstractroutingdatasource实现，核心步骤包括：1.定义数据源枚举或常量；2.创建继承abstractroutingdatasource的动态数据源类并重写determinecurrentlookupkey方法；3.使用threadlocal保存当前线程的数据源上下文；4.通过aop切面拦截方法调用，自动切换数据源；5.在spring中配置多个实际数据源及事务管理器。此机制支持读写分离、多租户等场景，提升系统可扩展性和灵活性。
MyBatis动态数据源路由，说白了，就是让你的应用在运行时能根据需要切换到不同的数据库连接。这在读写分离、多租户系统或者数据库分库分表场景下，简直是救命稻草。它不像写死在配置文件里那么僵硬，而是能根据业务逻辑或者请求上下文，灵活地决定用哪个库，这对于构建可伸缩、高可用的系统至关重要。
解决方案
实现MyBatis动态数据源路由，核心在于利用Spring的AbstractRoutingDataSource，配合AOP和ThreadLocal来动态切换数据源。
- 定义数据源枚举或常量： 明确你的所有数据源名称。
-
创建动态数据源类： 继承
AbstractRoutingDataSource，重写determineCurrentLookupKey()方法，这个方法就是决定使用哪个数据源的关键。 -
使用
ThreadLocal保存当前数据源上下文： 在每次请求或业务操作开始时，将目标数据源标识符存入ThreadLocal，并在操作结束后清除。 -
AOP切面进行数据源切换： 定义一个切面，拦截需要动态切换数据源的方法，在方法执行前设置
ThreadLocal，方法执行后（无论成功失败）清除ThreadLocal。 - 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：
蓝色大气通用企业公司网站源码，这是一款采用经典的三层结构，可以动态、伪静态模式，后台功能实用，界面大气，无限级分类，单篇栏目添加等的企业网站源码，比较适合二次开发或者企业自用，感兴趣的可以下载看一下啊。网站源码完整，后台是我作为程序员多年认为最为好用的一款后台，有时间我将发布更多的模板供大家下载使用，数据库为ACCESS，如需MSSQL数据库可与我联系。功能介绍：【新闻文章管理】可以发布公司新闻和
// 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等分布式事务管理器。不过，大多数情况下，我们只会在读写分离中用到，写操作走一个库的事务，读操作不走事务或者走另一个库的事务，这就足够了。
这个方案，在实际项目中用起来非常顺手，既保证了代码的整洁，又提供了强大的数据源切换能力。当然，它也有自己的局限性，比如对分布式事务的支持。但对于大部分读写分离和多租户的场景，它完全够用，而且实现起来相对简单直接。
