Sharding-Jdbc 3.1.0遇到的问题与处理

读前请注意

本文涉及的源码修改并没有经过严格的验证或大量测试,谨慎参考.

提前configMapContext的注入便于shardingAlgorithm使用

• 总的来说
  ShardingDataSource初始化时会读取"sharding.jdbc.config.config-map"配置放入configMapContext类中.
  但是用户自定义的shardingAlgorithm初始化先于configMapContext. 所以我给他提前了.
• 具体来说
  下面这是读取配置的部分

@ConfigurationProperties(prefix = "sharding.jdbc.config")
public class SpringBootConfigMapConfigurationProperties {
    private Map configMap = new LinkedHashMap<>();
}

下面是修改部分.

@EnableConfigurationProperties({
        SpringBootShardingRuleConfigurationProperties.class, SpringBootMasterSlaveRuleConfigurationProperties.class,
        SpringBootConfigMapConfigurationProperties.class, SpringBootPropertiesConfigurationProperties.class
})
public class SpringBootConfiguration implements EnvironmentAware {
	//此处为spring读取的sharding.jdbc.config配置.
	private final SpringBootConfigMapConfigurationProperties configMapProperties;
	@Bean
    public DataSource dataSource() throws SQLException {
    	// ------------------以下为手动添加的部分------------------
        if (!configMapProperties.getConfigMap().isEmpty()) {
            ConfigMapContext.getInstance().getConfigMap().putAll(configMapProperties.getConfigMap());
        }
        // ------------------以上为手动添加的部分------------------
		//shardingProperties.getShardingRuleConfiguration()会对ShardingAlgorithm进行实例化,此时configMapContetx尚未初始化.
        return null == masterSlaveProperties.getMasterDataSourceName()
                ? ShardingDataSourceFactory
                .createDataSource(dataSourceMap, shardingProperties.getShardingRuleConfiguration(), configMapProperties.getConfigMap(), propMapProperties.getProps())
                : MasterSlaveDataSourceFactory.createDataSource(
                dataSourceMap, masterSlaveProperties.getMasterSlaveRuleConfiguration(), configMapProperties.getConfigMap(), propMapProperties.getProps());
    }
}
/**
 *下面是ShardingDataSource的构造函数
 */
public class ShardingDataSource extends AbstractDataSourceAdapter {
	public ShardingDataSource(final Map dataSourceMap, final ShardingRule shardingRule, final Map configMap, final Properties props) throws SQLException {
        super(dataSourceMap);
        checkDataSourceType(dataSourceMap);
        //原来是在此处进行configMapContext的初始化.
        if (!configMap.isEmpty()) {
            ConfigMapContext.getInstance().getConfigMap().putAll(configMap);
        }
        shardingContext = new ShardingContext(getDataSourceMap(), shardingRule, getDatabaseType(), props);
    }
}

解释:

原本ConfigMapContext读取"sharding.jdbc.config"的配置是在ShradingDatasource初始化的时候注入的.但是ShardingDatasource初始化的时候先进行了ShardingRule的初始化(此时进行了ShardingAlgorithm的实例化),故在ShardingAlgorithm中初始化获取ConfigMapContext的时候还没有获取到配置文件中的配置.

莫名的NullPointerException

• 总的来说
  执行报错,抛空指针异常,发现真实异常被finally代码块中的异常覆盖了.然后改代码放出异常以便排查真正的报错原因.
• 具体来说
  追踪下去发现了ShardingPreparedStatement中sqlRoute()方法抛了异常,routeResult就会为NULL,结果在finally的时候又抛了一次异常覆盖掉了前一次的异常,导致看到的都是nullPointerException
  病源:

@Override
public boolean execute() throws SQLException {
    try {
        clearPrevious();
        //抛出异常
        sqlRoute();
        initPreparedStatementExecutor();
        return preparedStatementExecutor.execute();
    } finally {
        //若sqlRoute()存在异常,则routeResult的值为Null.便会再抛一次NullpointerException
        refreshTableMetaData(connection.getShardingContext(), routeResult.getSqlStatement());
        clearBatch();
    }
}

private void sqlRoute() {
    routeResult = routingEngine.route(new ArrayList<>(getParameters()));
}

临时处理方案: 由于我们只有查询(query)语句,故直接在这里加上一个非空判断.

if (routeResult != null) {
    refreshTableMetaData(connection.getShardingContext(), routeResult.getSqlStatement());
}

refreshTableMetaData()方法只有在如下几种场景时才会有作用,其中不包含我的查询场景.故直接跳过,具体作用没看

protected final void refreshTableMetaData(final ShardingContext shardingContext, final SQLStatement sqlStatement) {
    if (sqlStatement instanceof CreateTableStatement) {
        refreshTableMetaData(shardingContext, (CreateTableStatement) sqlStatement);
    } else if (sqlStatement instanceof AlterTableStatement) {
        refreshTableMetaData(shardingContext, (AlterTableStatement) sqlStatement);
    } else if (sqlStatement instanceof DropTableStatement) {
        refreshTableMetaData(shardingContext, (DropTableStatement) sqlStatement);
    }
}

基于暗示(Hint)的路由,表级别的分片策略不生效,只走默认分片策略.

• 总的来说
  仔细看官方文档.忘了就多看看.
  addDatabaseShardingValue不会跳过SQL解析引擎,setDatabaseShardingValue则会并且从此无视为单表配置好的分片策略,只会走默认策略
• 具体来说
  一开始没有仔细看官方文档,导致我一直不明白为什么给表配置了shardingAlgorithm却走不进去.
  下面是官方文档内容:

---

添加分片键值

• 使用hintManager.addDatabaseShardingValue来添加数据源分片键值。
• 使用hintManager.addTableShardingValue来添加表分片键值。

分库不分表情况下，强制路由至某一个分库时，可使用hintManager.setDatabaseShardingValue方式添加分片。通过此方式添加分片键值后，将跳过SQL解析和改写阶段，从而提高整体执行效率。

---

若是想分片逻辑精确控制到表单位得使用HintManager.getInstance().addDatabaseShardingValue()而不是setDatabaseShardingValue(),而我没仔细看,就踩了进去.

若使用了setDatabaseShardingValue,
将会使用DatabaseHintSQLRouter路由器并跳过sql解析直接指定目标库(兼容性最好,可以无视sharding-jdbc解析引擎不支持的sql语法报错,比如CTE这种解析引擎无法识别的语法再或者UNION这种解析引擎主动过滤的语法(后者可以强制开启,见三))

public final class PreparedStatementRoutingEngine {

    public PreparedStatementRoutingEngine(final String logicSQL, final ShardingRule shardingRule, final ShardingMetaData shardingMetaData, final DatabaseType databaseType, final boolean showSQL) {
        this.logicSQL = logicSQL;
        //创建路由实例, 当使用了HintManager的setDatabaseShardingValue时,此处会生成DatabaseHintSQLRouter并跳过sql解析.
        //普通情况下,使用ParsingSQLRouter路由并解析sql只有解析了sql才知道表名,才能从配置中找到表对应的逻辑.
        shardingRouter = ShardingRouterFactory.newInstance(shardingRule, shardingMetaData, databaseType, showSQL);
        masterSlaveRouter = new ShardingMasterSlaveRouter(shardingRule.getMasterSlaveRules());
    }
    //路由入口,由shardingRouter.route进行路由. shardingRouter的生成逻辑见上
    public SQLRouteResult route(final List