Sharding-jdbc设置defaultDatasource无效问题解决和源码分析思路

概要：sharding-jdbc中设置defaultDataSourcceName要配合setBindingTableGroups使用，否则默认数据源的配置无效。

背景

在使用sharding-jdbc进行分库分表的开发过程中，我们使用了3个数据源（库）：user0，user1，user2中，将主要需要拆分的用户表及相关关系表拆分成了36张表分配在三个库中，而除了这些需要分片的大表，还有一些量比较小的表，都存放在user0这个库中。而由于使用了sharding-jdbc的分片数据源，无法单独设置一个数据源，希望设置一个默认的路由规则，让未配置具体分片的表都路由到user0这个库。

这边找到sharding-jdbc的官方文档的配置手册，其中有这么一项配置：

• 

因此，这边设置：shardingRuleConfig.setDefaultDataSourceName(“user0”)

但是发现，最后在查询未分片表时，没有路由到user0上，而是路由到了user1。这边就只能debug跟着源码一层层调用，看看问题出在哪，为什么defaultDataSourcceName的设置没有生效。

问题解决

在对sharding-jdbc源码进行debug分析后，发现只配置defaultDataSourcceName是不会生效的，必须要配置bindingTableGroups，将所有需要按默认规则路由的表配置进去 ，这里官方文档有点坑，因为并没有说明这两个配置的关联性，而网上也没有查到这类问题。这次解决了问题，也算熟悉了sharding-jdbc的源码。

贴出我的数据源配置（通过java config配置的）：

• 

源码分析过程

首先，我们通过setDefaultDataSourceName()这个方法开始，可以看到是直接修改了ShardingRuleConfiguration类的defaultDataSourceName属性，通过idea的find usage功能搜索到这个属性的使用者：

• 

有两个类使用了ShardingRuleConfiguration.defaultDataSourceName，其中的YamlShardingRuleConfiguration这个类只是对yml文件解析为配置的一个类，因此从ShardingDataSourceNames.getDefaultDataSourceName看，：

• 

这里有三个调用者：

• DefaultDatabaseRoutingEngine
• ShardingRule
• TableReferencesClauseParser

从类名来看，我们要找的就是DefaultDatabaseRoutingEngine。而ShardingRule类中主要是给TableBroadcastRoutingEngine和StandardRoutingEngine提供支持，这两个类一个是用于全数据源查找，另一个是需要实现标准路由算法，不符合我们的需求。TableReferencesClauseParser是用于解析SQL的，并未在数据源路由中发挥作用。因此我们下面就是从DefaultDatabaseRoutingEngine着手：

• 

这个类的功能很明显，在route()方法中，将所有逻辑表路由至配置的默认数据源。可以看到logicTable是以对象属性参与到路由逻辑中，因此，真正调用前需要通过构造器来创建这个路由引擎（RoutingEngine）。
我通过查找的引用，找到了创建RoutingEngine的位置：RoutingEngineFactory.newInstance()

• 

从这个方法中可以看到，这里是根据不同的判定条件，将SQL交由不同的RoutingEngine去执行数据源路由。而使用DefaultDatabaseRoutingEngine的条件则在shardingRule.isAllInDefaultDataSource()中，这个方法如下：

• 
• 对需查询的逻辑表的判断逻辑有三部分：
  1. 配置了路由规则返回false
  2. 配置了广播表规则（查询所有数据源）返回false
  3. 表名不为空

这边我们需要查询的表没有配置路由规则，只在user0中，因此前两项都不满足，所以只要表名（logicTables）不为空，则可以使用DefaultDatabaseRoutingEngine路由至默认数据源。
但是通过Debug发现，我们这边传进来的的tableNames居然为空：

• 

很奇怪为什么我们的SQL没有解析出来tableNames，这里的tableNames()保存在sqlStatement中，而点进去能看到添加tableName的逻辑在TableFiller中：

• 

而通过debug看到，这里的sqlSegment是能拿到tableName的：

• 

那么应该就是fill判定为false导致没有向sqlStatement中添加tableName了，从上图fill()方法中的判断逻辑看，只有满足shardingRule.contains()时，fill才为true，而shardingRule.contains()的代码为：

• 
• 需要满足三个条件其中之一：
  1. 配置了表分片规则
  2. 配置了绑定表
  3. 配置了广播规则

因此，当我不想配置分片规则，又不想要在所有数据源中广播查询，并需要路由到指定的默认数据源时，必须要配置bindingTableRule，在官方文档中找到设置：bindingTableGroups，也就是得到了上面最开始的结果：setBindingTableGroups()。(跳至解决方案)

设置了绑定表后，发现的确在sqlStatement中拿到了tableName，并判定使用DefaultDatabaseRoutingEngine路由至设置的默认的数据源user0，达到了我们的目的。

这次虽然只是解决了一个小问题，但是基本上对sharding-jdbc中sql解析和路由的代码流程有了初步的了解，下次在这里面有什么问题也能更快的定位问题，还是有一定的收获的。