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