动态数据源路由通过spring的abstractroutingdatasource实现,核心步骤包括:1.定义数据源枚举或常量;2.创建继承abstractroutingdatasource的动态数据源类并重写determinecurrentlookupkey方法;3.使用threadlocal保存当前线程的数据源上下文;4.通过aop切面拦截方法调用,自动切换数据源;5.在spring中配置多个实际数据源及事务管理器。此机制支持读写分离、多租户等场景,提升系统可扩展性和灵活性。
MyBatis动态数据源路由,说白了,就是让你的应用在运行时能根据需要切换到不同的数据库连接。这在读写分离、多租户系统或者数据库分库分表场景下,简直是救命稻草。它不像写死在配置文件里那么僵硬,而是能根据业务逻辑或者请求上下文,灵活地决定用哪个库,这对于构建可伸缩、高可用的系统至关重要。
实现MyBatis动态数据源路由,核心在于利用Spring的AbstractRoutingDataSource,配合AOP和ThreadLocal来动态切换数据源。
讲真,刚开始做系统的时候,单库单表跑得好好的,根本不会去想什么动态数据源。但随着业务发展,用户量上来,数据量暴涨,或者公司开始搞多租户模式,你就会发现,一个数据库撑不住了。这时候,读写分离、分库分表就成了绕不过去的坎。
动态数据源就是为了解决这些痛点而生的。想象一下,一个电商系统,用户浏览商品是读操作,下单是写操作。如果所有请求都打到同一个数据库,写操作的压力很容易拖垮读操作的响应速度。这时候,我们就可以把读操作引到从库,写操作引到主库,这就是最常见的读写分离。而动态数据源的作用,就是让你在代码层面,不用写死连接池配置,就能根据当前方法是读还是写,自动切换到对应的数据库。
再比如多租户,每个租户的数据可能物理上隔离在不同的数据库实例里,或者至少是不同的Schema。用户A登录进来,所有操作都应该指向租户A的数据库;用户B登录,就指向租户B的数据库。这种场景下,你不可能为每个租户写一套独立的DAO层和Service层,那简直是灾难。动态数据源通过在请求入口处(比如Filter或Interceptor)解析租户ID,然后设置对应的数据源,就能实现一套代码服务多个租户。
它的核心价值在于“解耦”和“灵活性”。它把数据源的选择逻辑从业务代码中剥离出来,集中管理,这样当数据库架构调整时,业务代码几乎不用改动,只需要修改数据源的配置和路由规则,大大降低了维护成本和系统复杂度。我个人觉得,这玩意儿是系统演进到一定规模后,提升架构优雅度的关键一环。
实现动态数据源,我们主要围绕AbstractRoutingDataSource这个Spring提供的抽象类来展开。它的核心就是那个determineCurrentLookupKey()方法,我们得告诉它,当前请求应该用哪个数据源的key。
首先,我们需要一个地方来存放当前线程要使用的数据源标识。ThreadLocal是完美的选择,它能保证每个线程的数据独立性。
// DataSourceContextHolder.java public class DataSourceContextHolder { private static final ThreadLocal<String> 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中。
<!-- Spring XML配置示例 --> <bean id="masterDataSource" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close"> <property name="url" value="jdbc:mysql://localhost:3306/master_db" /> <property name="username" value="root" /> <property name="password" value="root" /> <!-- ...其他连接池配置 --> </bean> <bean id="slaveDataSource" class="com.alibaba.druid.pool.DruidDataSource" destroy-method="close"> <property name="url" value="jdbc:mysql://localhost:3306/slave_db" /> <property name="username" value="root" /> <property name="password" value="root" /> <!-- ...其他连接池配置 --> </bean> <bean id="dynamicDataSource" class="com.example.DynamicDataSource"> <property name="targetDataSources"> <map key-type="java.lang.String"> <entry key="master" value-ref="masterDataSource"/> <entry key="slave" value-ref="slaveDataSource"/> <!-- 更多数据源可以在这里添加 --> </map> </property> <!-- 默认数据源,当ThreadLocal中没有设置时使用 --> <property name="defaultTargetDataSource" ref="masterDataSource"/> </bean> <!-- 配置SqlSessionFactory,使用动态数据源 --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dynamicDataSource"/> <!-- ...其他MyBatis配置 --> </bean> <!-- 事务管理器也需要使用动态数据源 --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dynamicDataSource"/> </bean>
这段配置把dynamicDataSource作为MyBatis的实际数据源,这样MyBatis在执行SQL时,就会通过determineCurrentLookupKey()方法找到对应的连接。
光有动态数据源和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:
<!-- 启用Spring AOP注解 --> <aop:aspectj-autoproxy proxy-target-class="true"/>
现在,你只需要在Service层的方法上加上@TargetDataSource("slave"),这个方法执行时就会自动切换到从库。
关于事务管理: 这是一个比较容易踩坑的地方。Spring的事务管理器是基于DataSource的。如果你在一个事务中,先访问了主库,又访问了从库,那么这两个操作将不在同一个事务中。DataSourceTransactionManager绑定的是单个数据源的连接。对于跨数据源的事务,你需要考虑分布式事务(如XA协议,但性能开销大)或者采用柔性事务方案。在读写分离场景下,通常读操作不涉及事务,写操作才需要事务,所以这种AOP切换方式是没问题的。但如果你的业务逻辑确实需要在同一个事务中操作多个不同数据源,那这套方案需要更复杂的改造,比如引入Atomikos或JTA等分布式事务管理器。不过,大多数情况下,我们只会在读写分离中用到,写操作走一个库的事务,读操作不走事务或者走另一个库的事务,这就足够了。
这个方案,在实际项目中用起来非常顺手,既保证了代码的整洁,又提供了强大的数据源切换能力。当然,它也有自己的局限性,比如对分布式事务的支持。但对于大部分读写分离和多租户的场景,它完全够用,而且实现起来相对简单直接。
以上就是MyBatis动态数据源路由的完整实现教程的详细内容,更多请关注php中文网其它相关文章!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号