Sharding-JDBC源码初探

Sharding-JDBC是当当开源的分库分表中间件,通过重写jdbc api的方式为Java应用提供分库分表的能力,在官方项目首页有很多使用说明,相比较其他的分库分表开源产品,文档算是维护的比较好的一个项目,而且开发者也一直在维护更新,并和社区保持着积极的沟通。

sharding-jdbc的整体架构图如下:
sharding-jdbc架构图 by github

基本上分库分表中间件都要实现如图中的这些功能:规则配置、SQL解析、SQL改写、SQL路由、SQL执行、结果集合并。下面让我们深入到sharding-jdbc的源码中去,粗略地看一下这些功能在代码中是如何实现的。

在github上下载sharding-jdbc的源码后,需要在IDE中添加对Lombok的支持,因为项目中大量地使用了Lombok的注解,以减少项目代码量。在sharding-jdbc中有个大量示例的子项目sharding-jdbc-example,以sharding-jdbc-example-jdbc为突破口,先执行resources中的all_schema.sql文件建好所需要的分表,然后执行Main类中的示例查询。
example

规则配置

sharding-jdbc的规则配置稍显复杂,规则配置的目的是为了能够得到ShardingDataSource对象,即包含有分片信息和物理数据源的分片数据源对象,而ShardingDataSource是继承标准的JDBC的DataSource接口的。物理数据源是真正执行sql的地方,每个物理数据源连接实际的database,在构建物理数据源的过程中,可以使用数据库连接池技术提升性能,比如常用的出c3p0、druid,而示例用的是dbcp。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
private static ShardingDataSource getShardingDataSource() {
DataSourceRule dataSourceRule = new DataSourceRule(createDataSourceMap());
TableRule orderTableRule = TableRule.builder("t_order").actualTables(Arrays.asList("t_order_0", "t_order_1")).dataSourceRule(dataSourceRule).build();
TableRule orderItemTableRule = TableRule.builder("t_order_item").actualTables(Arrays.asList("t_order_item_0", "t_order_item_1")).dataSourceRule(dataSourceRule).build();
ShardingRule shardingRule = ShardingRule.builder().dataSourceRule(dataSourceRule).tableRules(Arrays.asList(orderTableRule, orderItemTableRule))
.bindingTableRules(Collections.singletonList(new BindingTableRule(Arrays.asList(orderTableRule, orderItemTableRule))))
.databaseShardingStrategy(new DatabaseShardingStrategy("user_id", new ModuloDatabaseShardingAlgorithm()))
.tableShardingStrategy(new TableShardingStrategy("order_id", new ModuloTableShardingAlgorithm())).build();
return new ShardingDataSource(shardingRule);
}

private static Map<String, DataSource> createDataSourceMap() {
Map<String, DataSource> result = new HashMap<>(2);
result.put("ds_0", createDataSource("ds_0"));
result.put("ds_1", createDataSource("ds_1"));
return result;
}

private static DataSource createDataSource(final String dataSourceName) {
BasicDataSource result = new BasicDataSource();
result.setDriverClassName(com.mysql.jdbc.Driver.class.getName());
result.setUrl(String.format("jdbc:mysql://localhost:3306/%s", dataSourceName));
result.setUsername("root");
result.setPassword("");
return result;
}

获取数据源之后,就是执行SQL语句,然后获得结果集,这个和以往正常的通过jdbc api连接数据库并获取数据的流程并无实质性差别,唯一区别的是这里的每个接口的实现类都是Sharding的,比如printGroupBy执行的统计用户订单量的示例。

1
2
3
4
5
6
7
8
9
10
11
12
private static void printGroupBy(final DataSource dataSource) throws SQLException {
String sql = "SELECT o.user_id, COUNT(*) FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id GROUP BY o.user_id";
try (
Connection conn = dataSource.getConnection();
PreparedStatement preparedStatement = conn.prepareStatement(sql)
) {
ResultSet rs = preparedStatement.executeQuery();
while (rs.next()) {
System.out.println("user_id: " + rs.getInt(1) + ", count: " + rs.getInt(2));
}
}
}

关键的ShardingContext

在执行dataSource.getConnection()之后获取到了shardingConnection,shardingConnection是一种逻辑意义上的分布式数据库的连接,其中最重要的成员变量当属shardingContext,即数据源运行时的上下文信息,包括了shardingRule(分片规则)、sqlRouteEngine(数据路由引擎,得出最终可执行的SQL语句)、executorEngine(执行引擎,通过多线程的方式并行执行多路SQL),之后的一系列的操作都离不开这个shardingContext,对于能够正确解析SQL并执行正确非常关键,可以认为是整个中间件执行的核心。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/**
* 数据源运行期上下文.
*
* @author gaohongtao
*/
@RequiredArgsConstructor
@Getter
public final class ShardingContext {

private final ShardingRule shardingRule;

private final SQLRouteEngine sqlRouteEngine;

private final ExecutorEngine executorEngine;
}

sharding-context

获取shardingConnection之后,通过conn.prepareStatement(sql)获取ShardingPreparedStatement,之后调用executeQuery()方法开始执行分布式的查询操作,包括SQL解析、改写、路由、执行和合并。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
@Override
public ResultSet executeQuery() throws SQLException {
ResultSet rs;
try {
rs = ResultSetFactory.getResultSet(
new PreparedStatementExecutor(getShardingConnection().getShardingContext().getExecutorEngine(), routeSQL()).executeQuery(), getMergeContext());
} finally {
clearRouteContext();
}
setCurrentResultSet(rs);
return rs;
}

private List<PreparedStatementExecutorWrapper> routeSQL() throws SQLException {
List<Object> parameters = getParameters();
List<PreparedStatementExecutorWrapper> result = new ArrayList<>();

//获得sql路由后的结果
SQLRouteResult sqlRouteResult = preparedSQLRouter.route(getParameters());

MergeContext mergeContext = sqlRouteResult.getMergeContext();
setMergeContext(mergeContext);
setGeneratedKeyContext(sqlRouteResult.getGeneratedKeyContext());

//获得所有的物理PreparedStatement的包装器
for (SQLExecutionUnit each : sqlRouteResult.getExecutionUnits()) {
PreparedStatement preparedStatement = (PreparedStatement) getStatement(getShardingConnection().getConnection(each.getDataSource(), sqlRouteResult.getSqlStatementType()), each.getSql());
replayMethodsInvocation(preparedStatement);
getParameters().replayMethodsInvocation(preparedStatement);
result.add(new PreparedStatementExecutorWrapper(preparedStatement, parameters, each));
}
return result;
}

SQL解析、路由和改写

这个过程是SQL处理的重要步骤,原始的逻辑上的SQL,需要转换成实际可以执行的SQL,比如替换成正确的库名、表名,对于需要统计合并类的操作,可能一条逻辑SQL会对应多条物理SQL。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/**
* 使用参数进行SQL路由.
* 当第一次路由时进行SQL解析,之后的路由复用第一次的解析结果.
*
* @param parameters SQL中的参数
* @return 路由结果
*/
public SQLRouteResult route(final List<Object> parameters) {
if (null == sqlParsedResult) {
sqlParsedResult = engine.parseSQL(logicSql, parameters);
tableRuleOptional = shardingRule.tryFindTableRule(sqlParsedResult.getRouteContext().getTables().iterator().next().getName());
} else {
generateId(parameters);
engine.setParameters(parameters);
for (ConditionContext each : sqlParsedResult.getConditionContexts()) {
each.setNewConditionValue(parameters);
}
}
return engine.routeSQL(sqlParsedResult);
}

SQL Parse的过程主要是解析SQL获得抽象语法树(AST),这个过程本质上和参数是无关的,只是把SQL拆解成一个个token的过程,传递参数的目的主要用在改写和路由,比如根据参数把原来的t_order路由到t_order_0和t_order_1。SQL Parse的结果理论上是可以缓存起来的,虽然这里似乎通过if (null == sqlParsedResult)来复用了解析的结果,但其实由于该方法所在类PreparedSQLRouter每次都会重新创建,并没有真正意义上的缓存利用起来,只有在复用ShardingPreparedStatement的情况下才会复用sqlParsedResult(参考https://github.com/dangdangdotcom/sharding-jdbc/issues/156). 路由和改写并不是两个割裂的过程,而是在路由的同时,就知道该向哪个分库或分表执行SQL,同时就改写相应的SQL。

执行与合并

在SQL路由之后最终得到的结果是封装了可执行的物理PrepareStatement的集,并由preparedStatementExecutorWrappers来包装,如果只有一个物理prepareStatement,直接执行executeQuery获取结果集即可,如果有多个物理prepareStatement,框架就会借助多线程执行每个查询,最后合并。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/**
* 执行SQL查询.
*
* @return 结果集列表
*/
public List<ResultSet> executeQuery() {
Context context = MetricsContext.start("ShardingPreparedStatement-executeQuery");
eventPostman.postExecutionEvents();
List<ResultSet> result;
final boolean isExceptionThrown = ExecutorExceptionHandler.isExceptionThrown();
final Map<String, Object> dataMap = ExecutorDataMap.getDataMap();
try {
if (1 == preparedStatementExecutorWrappers.size()) {

//直接执行一条SQL
return Collections.singletonList(executeQueryInternal(preparedStatementExecutorWrappers.iterator().next(), isExceptionThrown, dataMap));
}

//多线程框架下执行
result = executorEngine.execute(preparedStatementExecutorWrappers, new ExecuteUnit<PreparedStatementExecutorWrapper, ResultSet>() {

@Override
public ResultSet execute(final PreparedStatementExecutorWrapper input) throws Exception {
synchronized (input.getPreparedStatement().getConnection()) {
return executeQueryInternal(input, isExceptionThrown, dataMap);
}
}
});
} finally {
MetricsContext.stop(context);
}
return result;
}

整体上sharding-jdbc就是分这几部分来实现分库分表的功能的,框架内部做了很多事情,应用方要做的就是接入依赖,然后通过代码或配置写清楚分库分表的规则,即可像正常模式一样使用分布式数据库。