ShardingSphere的一些核心概念和核心过程

前面我们知道ShardingSphere需要执行五大核心流程，但是我们没有对五大核心流程有一个更深入的了解。也即五大过程做了什么事情。下面我们来了解两个概念以及五大核心流程。

一、何为绑定表？

表与表之间，如果是两个分表的库，此时关联查询会出现笛卡尔积查询的情况，也即是两者的排列组合。此时需要对其进行多余的去除处理。而绑定表的作用则建立两者关系的表。

二、何为广播表？

比如基础数据表，数据量不大，但频繁使用，此时可能很多地方需要用到，此时广播表就派上用场了。

三、分库分表的5大核心过程

解析、路由、改写、执行、归并。

 public ExecutionContext prepare(final String sql, final List<Object> parameters) {
        List<Object> clonedParameters = cloneParameters(parameters);
        // 先进行解析再执行路由
        RouteContext routeContext = executeRoute(sql, clonedParameters);
        ExecutionContext result = new ExecutionContext(routeContext.getSqlStatementContext());
        // 重写 这里是改写的核心
        result.getExecutionUnits().addAll(executeRewrite(sql, clonedParameters, routeContext));
        if (properties.<Boolean>getValue(ConfigurationPropertyKey.SQL_SHOW)) {
            SQLLogger.logSQL(sql, properties.<Boolean>getValue(ConfigurationPropertyKey.SQL_SIMPLE), result.getSqlStatementContext(), result.getExecutionUnits());
        }
        return result;
    }

1）解析：分为三个过程，解析、提取、填充。SqlParserEngine生成sql抽象语法树，通过SqlSegmentsExtractorEngine提取SQLStatement，以及通过SQLStatementFilter填充SQLStatement。

Sql解析的过程在之前的版本，使用的druid来做AST语法树解析，之后的版本，使用Antlr4实现对更多数据库的语法树解析和适配。

2）路由：通过对解析过程中生成的SQLStatement中所携带的上下文信息获取匹配数据库和表的分片策略，并生成路由结果。ShardingRouter分为预编译Statement和Statement。

3）改写：sql语句的改写是将原先的逻辑sql改成数据库中可以执行的sql语句，也即真实的sql语句。比如我们在分片算法中，定义了对应的路由算法，此时会根据对应的算法和对应的分片规则，需要进行正确的改写。而改写主要有两个作用：一种是用于分片逻辑的改写，一种是用于脱敏的改写。两者基于装饰者模式增强实现。核心接口：rewrite接口。

4）执行：执行具体的sql语句。

这个过程会将sql逐一执行，因此这个过程可能会执行多个sql语句。因此不免需要有归并的操作执行。

5）归并：经过路由改写之后，执行sql的语句可能有多条，此时就每个sql只是查询出来了结果的一部分，需要对sql查询的结果进行汇总，也即进行归并操作mergeQuery。

 MergedResult mergedResult = mergeQuery(preparedStatementExecutor.executeQuery());

 或者拿结果集的时候执行归并
  MergedResult mergedResult = mergeQuery(getQueryResults(resultSets));

四、什么时候会使用Statement或者PreparedStatement？

如果一个sql执行的次数只有一次，此时就会采用Statement，如果需要执行多次的时候，则会采用PreparedStatement。

五、分片策略

分片策略 => 分片算法 + 分片键

分片算法，通常我们可以进行重写，实现自己的个性化业务需求逻辑规则。还有数据库节点和分表节点定义等。

六、总结

本文简单梳理了一下相关概念和五大核心流程。由于业务需求开发需要，了解和看了一下ShardingSphere的源代码。发现之前在深入了解Seata之后，再来理解ShardingSphere，相对来说要容易很多。因为ShardingSphere的切入点是JDBC的整个过程的扩展，这个和Seata的思想是相通的，Seata在执行的过程中，也实现了自己的扩展。而为了实现扩展，ShardingSphere的作者对这一规范进行了扩展和改写，实现自己的扩展。从而实现在sql执行的过程中，能够根据业务需求的需要进行sql的解析、路由、改写、执行、归并。

参考：https://shardingsphere.apache.org/

https://github.com/apache/shardingsphere