由于一些特殊业务场景,或者根据customer来做分库的策略需要用到动态多数据源的场景。
看到很多帖子写的动态数据源没办法支持一个service混用多个数据源的场景,以及混用后的事务控制问题,使用AbstractRoutingDataSource 实现,贴几段关键
##1:determineCurrentLookupKey 实现
public enum DbContextHolder {
/**
* 数据源枚举
*/
Datasource;
private static ThreadLocal<List<DbTypeEnum>> contextHolder = new ThreadLocal<>();
/**
* 设置数据源
* @param dbTypeEnum
*/
public void setDbType(DbTypeEnum dbTypeEnum) {
if (null == contextHolder.get()) {
contextHolder.set(new ArrayList<>());
}
contextHolder.get().add(dbTypeEnum);
}
/**
* 取得当前数据源
* @return
*/
public String getDbType() {
List<DbTypeEnum> dbTypeEnumList = contextHolder.get();
return dbTypeEnumList.get(dbTypeEnumList.size() - 1).getValue();
}
/**
* 清除当前数据源
* @return
*/
public void clear() {
List<DbTypeEnum> dbTypeEnumList = contextHolder.get();
dbTypeEnumList.remove(dbTypeEnumList.size() - 1);
}
}
##2:ThreadLocal<List>
解决同一个service内调用多个数据源的场景
配合annotation @Db 作用在需要切分的数据源上
DynamicDBAspect 代码
@Aspect
@Order(0)
@Component
public class DynamicDBAspect {
@Before(value = "@annotation(db)")
public void before(JoinPoint point, Db db) {
DbContextHolder.Datasource.setDbType(db.value());
}
@After(value = "@annotation(db)")
public void after(JoinPoint point, Db db) {
//在每次调用完成清除ThreadLocal<List<DbTypeEnum>> 最后一个数据源
DbContextHolder.Datasource.clear();
}
}
##3:@Db的实现
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
//继承Transactional并以非事务方式运行
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public @interface Db {
DbTypeEnum value();
}
##4:调用方式:
service{
a(){
service1.invoke();
service2.invoke();
service3.invoke();
}
}
service1{
@Db(DbTypeEnum.a)
invoke(){}
}
service2{
@Db(DbTypeEnum.b)
invoke(){}
}
service3{
@Db(DbTypeEnum.c)
invoke(){}
}
##注:
@Db为什么要继承@Transactional 以非事务方式运行
1:如果service.a 使用@Transactional 修饰,则后续的sqlConnection不会实例,会导致数据源不会切换(determineCurrentLookupKey),在数据源混用的场景中我们一般只是查询动作,所以以非事务方式运行是合理的
2:在使用@Db修饰的service.method再用@Transactional,会优先使用指定的@Transactional
先写到这里,因为最近接手的这个项目是根据customer做的分库,在请求入口会根据customerId默认数据源,需要切换的场景只是一些调用公用的系统配置类的表,对事务的控制基本没有,如果存在一个service中调用多个数据源且需要事务控制,解决思路如下:
1:先进行pre-check后进行数据变更;先执行易错的调用
2:可以先以非事务方式控制,在需要回滚的逻辑中将数据进行补偿
一些大项目基本都是微服务不存在多数据源的场景,事务这块也都是分布式事务,补偿等方式来做