没事刷博客，看到动静数据源，发现网上的代码啦，配置啦，千篇一律，你抄我来我抄你，没啥意义，网上开源的轮子也有dynamic-datasource-spring-boot-starter，不过我看了下他那边的源码，不反对spring事务，这个我集体还是感觉比拟不喜爱的，而且在他本人实现的事务性能外面，貌似对事务嵌套也没做什么解决，它DSTransactional注解标记的办法最初间接就提交事务了。
整个我的项目将应用springboot + mybatis + mysql，简略点配置也少点，代码地址也在最初放进去了。
PS：前情提醒，提前温习下ThreadLocal以及aop的用法，以及dynamic-datasource-spring-boot-starter为什么要应用栈的数据结构来存储事务内的所有连贯，mybatis的一级缓存带来的问题。
spring其实曾经提供了一个很好的数据源，帮咱们实现运行时动静切换数据源，它就是AbstractRoutingDataSource，
简略来说，AbstractRoutingDataSource外部保护了一个默认数据源以及一个map(value为DataSource)，它的getConnection办法，在运行时只有咱们实现determineCurrentLookupKey办法，返回一个key，它就会去map中依据key找到对应的DataSource（找不到则应用默认数据源），从而实现动静切换的性能。
如果所有获取connection的形式，都是间接从DataSource来的话，此时咱们曾经完满实现了动静数据源的性能，而且并没有和orm框架强绑定，你以前是啥配置，当初仍旧啥配置，只是须要你注入的数据源是AbstractRoutingDataSource即可。不过，这是不是意味着咱们一劳永逸了？
不论你是否本人钻研过spring事务源码，最起码咱们都晓得一个事实：一个事务内会复用connection。究其原因，spring事务aop在开启事务时，会间接获取connection,组装成ConnectionHolder，而后通过TransactionSynchronizationManager.bindResource(DataSource,ConnectionHolder)，在其余须要获取connection的中央，则是优先通过TransactionSynchronizationManager.getResource(dataSource)去获取connection，这就导致了咱们的AbstractRoutingDataSource，在一个事务内只会触发一次getConnection，从而导致数据源切换失败！
这时候有意思的来了，如果存在事务的状况下，即便会复用connection，然而咱们让这个connection也具备动静能力，是不是就解决了事务上面切换数据源的问题？
间接上外围改写的类
package com.routing.datasource;
import com.routing.constant.DataSourceKeyConstant;
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;
import org.springframework.util.ClassUtils;
import org.springframework.util.StringUtils;
import javax.sql.DataSource;
import java.lang.reflect.Constructor;
import java.lang.reflect.Proxy;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.Map;
/**
* 动静数据源
*/
public class DynamicDataSource extends AbstractRoutingDataSource {
private Map<Object,Object> targetDataSource ;
public DynamicDataSource(DataSource defaultDataSource, Map<Object, Object> targetDataSource){
setDefaultTargetDataSource(defaultDataSource);
setTargetDataSources(targetDataSource);
this.targetDataSource = targetDataSource;
}
public Map<Object, Object> getTargetDataSource() {
return targetDataSource;
}
/**
* 获取实在的物理数据源信息
* @return
*/
public DataSource getPhysicsDataSource(){
return determineTargetDataSource();
}
@Override
public Connection getConnection() throws SQLException {
Connection connection = super.getConnection();
return getConnectionProxy(connection);
}
@Override
public Connection getConnection(String username, String password) throws SQLException {
Connection connection = super.getConnection(username, password);
return getConnectionProxy(connection);
}
@Override
protected Object determineCurrentLookupKey() {
return DataSourceHolder.getDbKey();
}
/**
* 生成代理对象,connection存在事务的状况下，复用connection
* @return
*/
public Connection getConnectionProxy(Connection target){
boolean existingTransaction = DataSourceHolder.isExistingTransaction();
if(existingTransaction){
Object dbKey = DataSourceHolder.getDbKey();
if(dbKey == null){
dbKey = DataSourceKeyConstant.PRIMARY;
}
ConnectionContext.initStack(dbKey,target);
}
// 生成代理类
Class<?>[] interfaces = {Connection.class};
Connection connection = (Connection) Proxy.newProxyInstance(ClassUtils.getDefaultClassLoader(),interfaces,new DynamicConnectionProxy(target));
return connection;
}
}
在获取到的connection上，咱们应用jdk代理的形式，如果存在事务，代理类DynamicConnectionProxy会动静实在物理库连贯，而后通过反射去执行实在物理库连贯的办法（一个事务内一个库的连贯重复使用）
而后看看jdk代理类的相干改写局部
package com.routing.datasource;
import lombok.extern.slf4j.Slf4j;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.sql.Connection;
/**
* 动静数据源
*/
@Slf4j
public class DynamicConnectionProxy implements InvocationHandler {
// 默认连贯
private Connection target;
// 是否已提交
private boolean commit;
// 是否已回滚
private boolean rollback;
public DynamicConnectionProxy(Connection target){
this.target = target;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
String methodName = method.getName();
if("toString".equals(methodName)){
return this.toString();
}
// 重写提交和回滚办法
if("commit".equals(methodName)){
log.info("connection 动静代理 commit办法....");
ConnectionContext.commitAllConnectionInTransaction();
commit = true;
return null;
}
if("rollback".equals(methodName)){
log.info("connection 动静代理 rollback办法....");
ConnectionContext.rollbackAllConnectionInTransaction();
rollback = true;
return null;
}
if("close".equals(methodName)){
// 以后连贯已被提交或者回滚
if(commit || rollback){
ConnectionContext.removeAllConnectionInTransaction(true);
DataSourceHolder.cleanDbKey();
return null;
}
}
// 判断是否存在事务，如果存在事务，则提供动静切换connection的性能
if(DataSourceHolder.isExistingTransaction()){
Connection connection = ConnectionContext.getPhysicsConnection(target);
return method.invoke(connection,args);
}
return method.invoke(target,args);
}
}
代理类中保护了一个target，次要是解决没有事物的状况，这个target本就是实在物理库的连贯，此时不须要connection有动静能力，全副由target间接执行即可；当存在事务的状况下，才须要咱们提供动静能力去解决这个问题。
这两个类曾经帮咱们解决了绝大部分动静数据源的问题，其余就是些aop以及ThreadLocal的利用了，就不丢进去了。
整个代码在https://codeup.aliyun.com/620…，有须要的人本人去拉吧（ QQ 1767028198）
发表回复