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解析和路由的代码流程有了初步的了解,下次在这里面有什么问题也能更快的定位问题,还是有一定的收获的。

发布了35 篇原创文章 · 获赞 104 · 访问量 10万+

猜你喜欢

转载自blog.csdn.net/wk52525/article/details/89506399