springboot动态多数据源

由于一些特殊业务场景，或者根据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<DbTypeEnum>>

解决同一个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：可以先以非事务方式控制，在需要回滚的逻辑中将数据进行补偿
一些大项目基本都是微服务不存在多数据源的场景，事务这块也都是分布式事务，补偿等方式来做

最后编辑于：2019.06.04 15:05:10