sharding-jdbc 分库连接数优化 | 京东物流技术团队

一.背景:

配运平台组的快递订单履约中心(cp-eofc)及物流平台履约中心(jdl-uep-ofc)系统都使用了 ShardingSphere 生态的 sharding-jdbc 作为分库分表中间件, 整个集群采用只分库不分表的设计,共 16 个 MYSQL 实例,每个实例有 32 个库,集群共 512 个库.

当每增加一台客户端主机,一个 MYSQl 实例最少要增加 32 个连接(通常都会使用连接池,根据配置的最大连接数,这个连接数可能会放大 5~10 倍).并且通常一个系统都会分为 web,provider,worker 等多个应用,这些应用共用一套数据源.随着应用机器数的增加,MYSQL 实例的连接数会很快达到上限,这就对系统的扩容造成了阻碍,无法横向的增加机器数,只能纵向的提高机器的配置来应对流量的增长.

作为京东物流的核心系统,业务增长迅速,系统所承接的流量也是逐渐增加,所以急需解决这个制约系统扩展的瓶颈点.

二.分库分表的相关概念介绍

2.1 为什么要分库分表

2.1.1 分库

随着业务的发展,单库中的数据量不断增加,数据库的 QPS 会越来越高,对数据库的读写耗时也会相应的增长,这时单库的读写性能必然会成为系统的瓶颈点.这时可以通过将单个数据库拆分为多个数据库的方法,来分担数据库的压力,提升性能.同时多个数据库分布在不同的机器上也提高了数据库的可用性.

2.1.2 分表

随着单表数据量的增加,对于数据的查询和更新,即使在数据库底层有一定的优化,但是随着量变必定会引起质变,导致性能急剧下降.这时可以通过分表的方法,将单表数据按一定规则水平拆分到多个表中,减小单表的数据量,提升系统性能.

2.2 sharding-jdbc 简介

ShardingSphere

是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（计划中）这 3 款相互独立的产品组成.他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、容器、云原生等各种多样化的应用场景。

Sharding-JDBC

定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

适用于任何基于 Java 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。

支持任意实现 JDBC 规范的数据库。目前支持 MySQL，Oracle，SQLServer 和 PostgreSQL。

我们先看下 ShardingSphere 官网给出的基于 Spring 命名空间的规则配置示例:

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns:sharding="http://shardingsphere.io/schema/shardingsphere/sharding"     xsi:schemaLocation="http://www.springframework.org/schema/beans                         http://www.springframework.org/schema/beans/spring-beans.xsd                        http://shardingsphere.io/schema/shardingsphere/sharding                         http://shardingsphere.io/schema/shardingsphere/sharding/sharding.xsd                         ">    <!-数据源ds0->    <bean id="ds0" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">        <property name="driverClassName" value="com.mysql.jdbc.Driver" />        <property name="url" value="jdbc:mysql://localhost:3306/ds0" />        <property name="username" value="root" />        <property name="password" value="" />    </bean>    <!-数据源ds1->    <bean id="ds1" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">        <property name="driverClassName" value="com.mysql.jdbc.Driver" />        <property name="url" value="jdbc:mysql://localhost:3306/ds1" />        <property name="username" value="root" />        <property name="password" value="" />    </bean>        <!-分片策略->    <sharding:inline-strategy id="databaseStrategy" sharding-column="user_id" algorithm-expression="ds$->{user_id % 2}" />    <sharding:inline-strategy id="orderTableStrategy" sharding-column="order_id" algorithm-expression="t_order$->{order_id % 2}" />    <sharding:inline-strategy id="orderItemTableStrategy" sharding-column="order_id" algorithm-expression="t_order_item$->{order_id % 2}" />        <!-sharding数据源配置->    <sharding:data-source id="shardingDataSource">        <sharding:sharding-rule data-source-names="ds0,ds1">            <sharding:table-rules>                <sharding:table-rule logic-table="t_order" actual-data-nodes="ds$->{0..1}.t_order$->{0..1}" database-strategy-ref="databaseStrategy" table-strategy-ref="orderTableStrategy" />                <sharding:table-rule logic-table="t_order_item" actual-data-nodes="ds$->{0..1}.t_order_item$->{0..1}" database-strategy-ref="databaseStrategy" table-strategy-ref="orderItemTableStrategy" />            </sharding:table-rules>        </sharding:sharding-rule>    </sharding:data-source></beans>

配置总结:

1.需要配置多个数据源 ds0,ds1;

2.分片策略中配置分片键(sharding-column)和分片表达式(algorithm-expression)需符合 groovy 语法;

3.在 sharding 数据源中sharding:table-rule标签中配置逻辑表名(logic-table),库分片策略(database-strategy-ref)和表分片策略(table-strategy-ref),actual-data-node 属性由数据源名 + 表名组成，以小数点分隔,用于广播表;

三.问题分析与解决方案

3.1 问题分析

正如文章开头提到的目前我们的 MYSQL 集群架构如下,16 个 MYSQL 实例,每个实例有 32 个库,集群共 512 个库.当客户端主机启动后与 MYSQL_0 实例中的 32 个库连接,分别会建立 32 个数据源,连接池配置的最大连接数为 5,也就是说极端情况下一个客户端与一个 MYSQL 实例最多会建立 32*5=160 个连接数.对于物流的一些核心系统在大促时扩容上百台是很常见的,所以很快单个实例的最大连接数就会触达上限.

目前客户端连接连接数据库集群形式如图所示:

3.2 可行方案

我们的目标就是降低单个 MYSQL 实例的连接数,其中我们共探讨了几种方案如下:

3.2.1 单实例不分库只分表

这样一个客户端与单个数据库实例只需通过一个连接池连接,大大降低了连接数.但这种方案改变了现有的分片规则,需要新建一套数据库集群,根据新规则同步历史数据和增量数据,还有新旧数据验证,但难度和风险最高的还是线上切换过程,可能会造成数据不一致,且一旦出问题回滚方案也会非常复杂.

3.2.2 使用支持弹性扩展的数据库

使用京东的 jed,tidb 等支持弹性扩展的数据库,将数据同步到新库中,这类数据库的优势是开发人员只需关注业务,不需要再去处理数据库连接这些底层细节.

3.2.3 使用 sharding-proxy

Sharding-Proxy 的定位是透明化的数据库代理,我们可以在服务器上部署一套 Sharding-Proxy,客户端只需连接 proxy 服务,再由 proxy 服务器连接 MYSQL 集群,这样 MYSQL 集群的连接数只与 proxy 服务器的数量有关,与客户端解耦.

3.2.4 通过改造 sharding-jdbc

理论上我们只要获取数据库实例上某个库的连接,我们就可以通过"库名.表名"的方式访问这台实例上其他库中的数据(当然前提是用户要拥有要访问库的权限),我们是否可以通过改造 sharding-jdbc 来实现这种访问方式?

以上几种方案,3.2.1 和 3.2.2 都需要新建数据库,同步历史和增量数据,还涉及线上切换数据源,3.2.3 需要部署一套 proxy 服务,并且为了高可用必定要以集群方式部署,这三种方案工作量和风险都较高,我们基于成本最小原则,最终选择改造 sharding-jdbc 的方案.

3.3 探究 sharding-jdbc

3.3.1 工作流程

sharding-jdbc 的工作流程可以分为以下步骤:

• sql 解析-词法解析和语法解析;

• sql 路由-根据解析上下文匹配数据库和表的分片策略，并生成路由路径;

• sql 改写-将逻辑 SQL 改写为在真实数据库中可以正确执行的 SQL;

• sql 执行-使用多线程并发执行 sql;

• 结果归并-将从各个数据节点获取的多数据结果集，组合成为一个结果集并正确的返回至请求客户端;

显然数据库和表的分片是在 sql 路由阶段处理,所以我们以 sql 路由逻辑为入口分析下源码.

3.3.2 源码分析

ShardingStandardRoutingEngine 类中的 route 方法为计算路由的入口,返回的结果是数据库和表的分片集合:

route 方法中的核心逻辑在该类的 route0 方法中,其中 routeDataSources 方法负责 database 路由,routeTables 方法负责 table 路由,实际路由计算在 StandardShardingStrategy 的 doSharding 方法中,我们继续深入.

在 StandardShardingStrategy 类中有两个成员属性,preciseShardingAlgorithm(精准分片算法),rangeShardingAlgorithm(范围分片算法),由于我们的 sql 都只指定分片键精准查询,使用的都是 preciseShardingAlgorithm 计算出的结果,PreciseShardingAlgorithm 是个接口,那我们就可以实现这个接口来自定义分片算法.

同时在 sharding-sphere 官网上也找到了相应的标签支持:

所以我们只需要自己实现 PreciseShardingAlgorithm 接口并配置在标签内即可实现自定义分片策略.

3.4 改造步骤

3.4.1 库分片改造

目前应用配置了 ds_0~ds_511 共 512 个数据源,我们只需配置 ds_0~ds_15 共 16 个数据源,每个数据源配置的是单个实例上的第一个库.

对于分片规则,我们可以依然使用sharding:inline-strategy标签,只需对 Groovy 表达式进行重写,分片键为 order_code,之前分片算法为(Math.abs(order_code.hashCode()) % 512)即用 order_code 列的哈希值对 512 取模得到 0~511,我们只需要将结果再整除 32 即可得到 0~16,即表达式改写为(Math.abs(order_code.hashCode()) % 512).intdiv(32).

改造前分库规则配置:

改造后分库规则配置:

3.4.2 表分片改造

实现 PreciseShardingAlgorithm 接口,重写表分片算法,使计算结果返回"实际库名+表名"的形式;

例如:查询 DB_31 库上 t_order 表的 user_id=35711 的数据,数据库分片算法返回的数据源为"DB_0",表分片算法返回"DB_31.t_order";

自定义表分片算法:

在 xml 中定义sharding:standard-strategy标签,其属性 precise-algorithm-ref 配置为我们自定义的分表算法.

3.4.3 数据库连接池参数调整

改造前是一个库对应一个数据源连接池,改造后一个实例上的 32 个库共用一个数据源连接池,那么连接池的最大连接数,最小空闲连接数等参数需要相应的做调整.这个需要根据业务流量做合理的评估,当然最严谨的还是要以压测结果作为依据.

改造后客户端连接集群的形式如图:

优化前后数据库集群连接数对比:

四.小插曲

在改写库分片规则的 Groovy 表达式时,整除 32 直接在原有表达式上配置"/32"即 Math.abs(order_code.hashCode()) % 512 / 32 ,在调试中发现执行 sql 会报"no database route info"错误信息,经过 debug 发现 sharding-jdbc 计算分片规则时会出现小数(例如:ds_14.6857),导致找不到数据源,这是因为 Groovy 没有提供专用的整数除法运算符,所以要用.intdiv()方法,最终表达式改写为(Math.abs(order_code.hashCode()) % 512).intdiv(32).

五.总结

本文介绍了分库分表的概念及优势,以及 sharding-jdbc 分库分表中间件,探究了 sharding-jdbc 的路由规则的执行流程.当然在系统设计之初,对于数据库的分库分表,到底需不需要做?是多分库好还是多分表好?并没有一个放之四海而皆准的法则,需结合系统的特点(例如 qps,tps,单表数据量,磁盘规格,数据保留时间,业务增量,数据冷热方案等因素)来决策权衡,有利有弊才需决策,有取有舍才需权衡.

作者：京东物流 张仲良

来源：京东云开发者社区 自猿其说 Tech