shardingsphere核心分片-sql路由

sql路由作为数据分片的核心步骤在shardingSphere中由路由引擎来实现，通过解析引擎解析后的statement，提取关键的信息构建statementContext

为路由引擎提供支持。

我们从一条sql语句执行时去看看路由引擎如何路由的

    public ResultSet executeQuery() throws SQLException {
        ShardingSphereResultSet result;
        try {
　　　　　　　//清除上一次的缓存信息
            this.clearPrevious();
            //创建执行上下文
            this.executionContext = this.createExecutionContext();
            //调用执行器真正执行sql
            List<QueryResult> queryResults = this.executeQuery0();
            //结果归并，这是一个查询的sql可能会需要结果集进行归并
            MergedResult mergedResult = this.mergeQuery(queryResults);
            result = new ShardingSphereResultSet(this.getResultSetsForShardingSphereResultSet(), mergedResult, this, this.executionContext);
        } finally {
            this.clearBatch();
        }

        this.currentResultSet = result;
        return result;
    }

上述代码属于ShardingSpherePreparedStatement这个类，我们知道shardingsphere中sharding-jdbc实现分片功能是通过包装jdbc层来实现的，这里

就是包装了PreparedStatement。真正的路有隐情在创建执行上下文的时候会进行，执行上下文中包含了已经路由好的结果已经sql改写的结果。

进入这个创建执行上下文的方法

    private ExecutionContext createExecutionContext() {
        LogicSQL logicSQL = this.createLogicSQL();
        SQLCheckEngine.check(logicSQL.getSqlStatementContext().getSqlStatement(), logicSQL.getParameters(), this.metaDataContexts.getDefaultMetaData().getRuleMetaData().getRules(), "logic_db", this.metaDataContexts.getMetaDataMap(), (Grantee)null);
        ExecutionContext result = this.kernelProcessor.generateExecutionContext(logicSQL, this.metaDataContexts.getDefaultMetaData(), this.metaDataContexts.getProps());
        this.findGeneratedKey(result).ifPresent((generatedKey) -> {
            this.generatedValues.addAll(generatedKey.getGeneratedValues());
        });
        return result;
    }

在这里第一步 创建LogicSQL这样一个对象，这个对象比较简单，里面包含了StatementContext、当前的sql以及向sql中设置的参数信息。

第二步通过SQLCheckEngine对SQL进行检查，校验合法性等信息，这个校验我看shardingShpere中没有具体的实现SQLChecker的类，

通过shardingsphere这种SPI实现的微内核架构，我们可以快速的将自己的SQLChecker注册到shardingSphere中进行我们自定义的校验。

接下来第三部就是通过核心处理器来真正生成执行上下文。

    public ExecutionContext generateExecutionContext(LogicSQL logicSQL, ShardingSphereMetaData metaData, ConfigurationProperties props) {
        RouteContext routeContext = this.route(logicSQL, metaData, props);
        SQLRewriteResult rewriteResult = this.rewrite(logicSQL, metaData, props, routeContext);
        ExecutionContext result = this.createExecutionContext(logicSQL, metaData, routeContext, rewriteResult);
        this.logSQL(logicSQL, props, result);
        return result;
    }

进入我们的KernelProcessor类，这里我们终于看到了路由的真正入口。这个方法中第一步就是路由之后进行sql改写然后将结果生成执行上下文。

接下来就会通过路由引擎执行路由逻辑

 

    public RouteContext route(LogicSQL logicSQL, ShardingSphereMetaData metaData) {
        SQLRouteExecutor executor = this.isNeedAllSchemas(logicSQL.getSqlStatementContext().getSqlStatement()) ? new AllSQLRouteExecutor() : new PartialSQLRouteExecutor(this.rules, this.props);
        return ((SQLRouteExecutor)executor).route(logicSQL, metaData);
    }

通过SQLRouteExecutor路由执行器来进行路由，其中第一步会进行一个路由器的选择，如果我们的SQL类型属于MySQLShowTablesStatement这时会创建一个AllSQLRouteExecutor,否则

则会创建PartialSQLRouteExecutor。MySQLShowTablesStatement包含什么？比如就是 show tables这条语句，AllSQLRouteExecutor顾名思义就是一个全部路由，里面的路由返回的结果

就是将我们所有的数据库配置和表配置组成对应的节点返回。重点是我们的PartialSQLRouteExecutor。

    public PartialSQLRouteExecutor(final Collection<ShardingSphereRule> rules, final ConfigurationProperties props) {
        this.props = props;
        routers = OrderedSPIRegistry.getRegisteredServices(SQLRouter.class, rules);
    }
    
    @Override
    @SuppressWarnings({"unchecked", "rawtypes"})
    public RouteContext route(final LogicSQL logicSQL, final ShardingSphereMetaData metaData) {
        RouteContext result = new RouteContext();
        for (Entry<ShardingSphereRule, SQLRouter> entry : routers.entrySet()) {
            if (result.getRouteUnits().isEmpty()) {
                result = entry.getValue().createRouteContext(logicSQL, metaData, entry.getKey(), props);
            } else {
                entry.getValue().decorateRouteContext(result, logicSQL, metaData, entry.getKey(), props);
            }
        }
        if (result.getRouteUnits().isEmpty() && 1 == metaData.getResource().getDataSources().size()) {
            String singleDataSourceName = metaData.getResource().getDataSources().keySet().iterator().next();
            result.getRouteUnits().add(new RouteUnit(new RouteMapper(singleDataSourceName, singleDataSourceName), Collections.emptyList()));
        }
        return result;
    }

在PartialSQLRouteExecutor中主要有一个构造器和route方法，在构造器里根据rules（分片规则）去获取了所有的SQLRouter，包括shardingSQLRouter、ReadwriteSplittingSQLRouter、ShadowSQLRouter

等。我们现在配置的Rules只有shardingRules也就是分库分表的规则配置，并不涉及读写分离的规则或者影子库的规则等，没有与之共同使用。所以这里根据ruls获取的SQLRouter

只有我们的ShardingSQLRouter进行分库分表的路由配置。

通过shardingSQLRouter进入我们的构造上下文

    public RouteContext createRouteContext(final LogicSQL logicSQL, final ShardingSphereMetaData metaData, final ShardingRule rule, final ConfigurationProperties props) {
        RouteContext result = new RouteContext();
        SQLStatement sqlStatement = logicSQL.getSqlStatementContext().getSqlStatement();
        Optional<ShardingStatementValidator> validator = ShardingStatementValidatorFactory.newInstance(sqlStatement);
        validator.ifPresent(optional -> optional.preValidate(rule, logicSQL.getSqlStatementContext(), logicSQL.getParameters(), metaData.getSchema()));
        ShardingConditions shardingConditions = createShardingConditions(logicSQL, metaData, rule);
        boolean needMergeShardingValues = isNeedMergeShardingValues(logicSQL.getSqlStatementContext(), rule);
        if (sqlStatement instanceof DMLStatement && needMergeShardingValues) {
            mergeShardingConditions(shardingConditions);
        }
        ShardingRouteEngineFactory.newInstance(rule, metaData, logicSQL.getSqlStatementContext(), shardingConditions, props).route(result, rule);
        validator.ifPresent(v -> v.postValidate(rule, logicSQL.getSqlStatementContext(), result, metaData.getSchema()));
        return result;
    }

在这个构建上下文的方法中，主要对Statement进行一个校验，之后创建shardingConditions,shardingConditions就是分片条件，里面包含了我们分片键的列名以及分片键的值。

可以看到：

 

 

 这是shardingConditions里面有一个ShardingCondition的list，里面存储了每个分片键以及对应的信息。这里我作为演示的是使用的标准分片策略用来处理单键分片，

而且是一个精确分片算法，不是between 、in这种范围分片。我们可以看到我们的分片键order_id以及分片键的值为90。这些信息就是通过我们sql解析时生成的statement

对象和参数信息生成的。之后就可以根据这些conditions信息进行路由。

之后进入我们的shardingRouteEngine中的getDataNodes方法中。

   private Collection<DataNode> getDataNodes(final ShardingRule shardingRule, final TableRule tableRule) {
        ShardingStrategy databaseShardingStrategy = createShardingStrategy(shardingRule.getDatabaseShardingStrategyConfiguration(tableRule), shardingRule.getShardingAlgorithms());
        ShardingStrategy tableShardingStrategy = createShardingStrategy(shardingRule.getTableShardingStrategyConfiguration(tableRule), shardingRule.getShardingAlgorithms());
        if (isRoutingByHint(shardingRule, tableRule)) {
            return routeByHint(tableRule, databaseShardingStrategy, tableShardingStrategy);
        }
        if (isRoutingByShardingConditions(shardingRule, tableRule)) {
            return routeByShardingConditions(shardingRule, tableRule, databaseShardingStrategy, tableShardingStrategy);
        }
        return routeByMixedConditions(shardingRule, tableRule, databaseShardingStrategy, tableShardingStrategy);
    }

在这里我们datasource的配置和table的配置都使用的是标准分片策略，所以shardingsphere这里选择是 ShardingStandardRoutingEngine来进行处理。

通过这个方法我们可以看到，首先会根据配置的分片策略和算法去创建对应的表的和数据库的ShardingStrategy，在demo中这里两个都是StandardShardingStrategy。

值得一提的是 shardingSphere支持四种策略，标准分片策略、强制路由、复杂分片策略以及不分片策略。标准分片策略用来处理单键分片，与标准分片算法

配合；复杂分片策略用于处理多个分片键的路由与复杂分片算法配置。强制路由使用HintManager自定义传入分片值以及自定义算法实现。不分片策略则是没有分片的

情况下可以使用。

通过判断是否强制路由或者根据condition分片路由来决定如何路由，如果数据库或者表其中一个是hint方式另一个是分片方式则会进行混合路由。

进入分片路由逻辑：

    private Collection<DataNode> routeByShardingConditions(final ShardingRule shardingRule, final TableRule tableRule, 
                                                           final ShardingStrategy databaseShardingStrategy, final ShardingStrategy tableShardingStrategy) {
        return shardingConditions.getConditions().isEmpty()
                ? route0(tableRule, databaseShardingStrategy, Collections.emptyList(), tableShardingStrategy, Collections.emptyList())
                : routeByShardingConditionsWithCondition(shardingRule, tableRule, databaseShardingStrategy, tableShardingStrategy);
    }

判断conditions是否为空如果为空则传入一个emptyList直接进行真正的路由，否则遍历我们的conditions通过condition进行路由。

    private Collection<DataNode> route0(final TableRule tableRule, 
                                        final ShardingStrategy databaseShardingStrategy, final List<ShardingConditionValue> databaseShardingValues, 
                                        final ShardingStrategy tableShardingStrategy, final List<ShardingConditionValue> tableShardingValues) {
        Collection<String> routedDataSources = routeDataSources(tableRule, databaseShardingStrategy, databaseShardingValues);
        Collection<DataNode> result = new LinkedList<>();
        for (String each : routedDataSources) {
            result.addAll(routeTables(tableRule, each, tableShardingStrategy, tableShardingValues));
        }
        return result;
    }

将通过condition解析好的对应的数据库分片键以及表的分片键构建为List类型的ShardingConditionValue，这个shardingVlue就包含了分片键的名称以及值。

先通过数据库的ShardingConditionValue去路由所用的数据库，在根据表的ShardingConditionValue去路由表，然后将路由的每一个表节点添加至上一步路由

后的每一个数据库节点。这样所有需要访问的数据节点就已经确定了。

我们看一下具体是如何路由的

    public Collection<String> doSharding(final Collection<String> availableTargetNames, final Collection<ShardingConditionValue> shardingConditionValues, final ConfigurationProperties props) {
        ShardingConditionValue shardingConditionValue = shardingConditionValues.iterator().next();
        Collection<String> shardingResult = shardingConditionValue instanceof ListShardingConditionValue
                ? doSharding(availableTargetNames, (ListShardingConditionValue) shardingConditionValue) : doSharding(availableTargetNames, (RangeShardingConditionValue) shardingConditionValue);
        Collection<String> result = new TreeSet<>(String.CASE_INSENSITIVE_ORDER);
        result.addAll(shardingResult);
        return result;
    }

我们可以看分片策略类中的doSharding方法，这里会最终调用配合我们策略使用的算法中的doSharding来实现真正的计算。

主要看一下dmeo中的分片算法使用，这里时用了shardingSphere的内置INLINE算法。

    @Override
    public String doSharding(final Collection<String> availableTargetNames, final PreciseShardingValue<Comparable<?>> shardingValue) {
        Closure<?> closure = createClosure();
        closure.setProperty(shardingValue.getColumnName(), shardingValue.getValue());
        return closure.call().toString();
    }
    
    @Override
    public Collection<String> doSharding(final Collection<String> availableTargetNames, final RangeShardingValue<Comparable<?>> shardingValue) {
        if (allowRangeQuery) {
            return availableTargetNames;
        }
        throw new UnsupportedOperationException("Since the property of `" + ALLOW_RANGE_QUERY_KEY + "` is false, inline sharding algorithm can not tackle with range query.");
    }

INLINE算法就是我们提供一个行表达式，之后shardingSphere通过计算表达式的值来确定具体路由的结构。比如 表的INLINE分片算法的表达式 t_order_${order_id % 2}

最终shardingSphere就会跟个order_id的值对2进行取模组成真正的表结点如 t_order_0或者t_order_1。

我们可以看到这个类有两个doSharding的方法。第一个是精确分片这里时处理  = 和 in这种分片键的，因为这里所有的分片值我们可以枚举出来。对于in中多个值会进行循环

处理，每次传入一个确定的值。

第二个方法是针对范围分片的，主要用来处理 between and , < , >,<=,>=的，这些分片值都是一个范围的东西。当然INLINE算法一般不支持范围分片的。如果允许范围分片

它就会返回所有可用的表或者数据源信息。

 

以上就上路由的全部流程，当然里面有些部分和细节没有写出来，以后会仔细研究一下在补充。