关于@DS注解切换数据源失败的原因实战记录

第关于@DS注解切换数据源失败的原因实战记录目录项目场景：问题排查过程第一个问题，数据源没有载入第二个问题，@DS注解切换数据源无效总结

项目场景：

一位好友在陈年老代码中想要加入mybatis-plus和boumidou的多数据源来轻松实现crud，但是发现@DS无法成功切换数据源，一直都是访问的主库，于是我开始了漫长的啃源码找原因。

以下内容包含两个问题1：配置的数据库没有正常被dynamic框架载入，2：@DS注解切换数据源无效

问题排查过程

第一个问题，数据源没有载入

根据启动日志里druid打印的信息来看，只载入了一个数据库，并没有把yml配置信息中的两个数据库都加载，YML配置如下。

从源码来看，数据源的配置读取是在AbstractDataSourceProvider类中。

他的调用是在子类YmlDynamicDataSourceProvider中。

然后在DynamicDataSourceAutoConfiguration类中注入了YmlDynamicDataSourceProvider。

在此处打上断点后，发现传入的datasourceMap中的信息都是正确的，跟yml配置的一致。

那就只能是YmlDynamicDataSourceProvider中的loadDataSources()方法没有调用。

此方法在DynamicRoutingDataSource的初始化方法中调用。

在这里打上断点后发现断点进不来，是对象没有创建的原因，回到DynamicDataSourceAutoConfiguration类中找DynamicRoutingDataSource的创建。

@ConditionalOnMissingBean表明dataSource这个Bean应该是已经被注入了，通过全局查询找到了问题的关键点（下图），代码在其他地方注入了dataSource。

然而很多地方已经在用这个dataSource了，删了的话，就雪崩了。考虑另辟蹊径，选择了自己去创建DynamicRoutingDataSource对象。

到这里，成功载入了其他数据源。

第二个问题，@DS注解切换数据源无效

先从@DS的拦截盘起，@DS的拦截在DynamicDataSourceAnnotationInterceptor拦截器中，读取了@DS上的库名，然后放入一个上下文管理器的队列中。

调用SQL时，会通过AbstractRoutingDataSource的getConnection()方法(下图)。

里面的determineDataSource()方法由子类DynamicRoutingDataSource实现，真正切换了数据源，里面调用了队列的peek()方法，取出上面拦截器中加入的@DS属性的库名，然后通过库名，拿到了对应数据源的DataSource，再结合AbstractRoutingDataSource的getConnection()方法拿到了对应数据库的连接，去执行SQL。

切换数据源的流程到这就说的差不多了，然后讲讲这个项目中为什么切换不了数据源。

在determineDataSource()方法打上断点，结果根本没有经过该方法，然而@DS的拦截器断点是能正常进入的，@DS注解上的数据源名称也读取正确，是第二个库。由此猜测，应该是没有走进AbstractRoutingDataSource的getConnection()方法，查看druid的数据库加载相关的日志，发现在boumidou的dynamic框架加载数据库之前，已经有其他数据库加载了。

推测可能是由于，SQL调用的时候，默认是用的第一个数据库的DataSource调用的getConnection()方法，但是这个不是由dynamic框架加载，并不是AbstractRoutingDataSource对象，所以不会走进determineDataSource()方法去选择数据源，就试着想办法让dynamic框架优先加载。

在上面自己创建DynamicRoutingDataSource的@Bean方法上