Sharding-Sphere 分库分表框架综述

一、初识Apache-Sharding-Sphere生态

Apache-Sharding-Sphere的前身是当当网开源的Sharding-JDBC框架，后面引入Zookeeper作为注册中心，又研发了Sharding-Proxy中间件，贡献给Apache软件基金会后，正式整合成Sharding-Sphere生态，并且支持、兼容各种数据库，Apache-Sharding-Sphere官网上可看到的发展历程如下：

发展历程

目前最新的5.2.1版本属于其中5.x阶段的一个版本，目前支持可可拔插功能，其支持的核心功能如下：

核心功能

Apache-Sharding-Sphere总共由JDBC、Proxy、Sidecar三大核心产品组成，前两者都已具备完整形态，Sidecar还处于开发阶段，这也就代表着目前的ShardingSphere5中只有JDBC、Proxy两款产品，这两款产品即支持各自独立部署，也支持混合部署的模式，两者区别在于：

• JDBC：以工程形式嵌入Java应用，兼容所有JDBC支持的数据库，适用于任意ORM框架。

• Proxy：以独立的中间件形式部署，目前只支持MySQL、PgSQL，但支持异构语言开发的系统。

1.1、Sharding-JDBC框架简介

Sharding-JDBC的定位是一款轻量级Java框架，它会以POM依赖的形式嵌入程序，运行期间会和Java应用共享资源，这款框架的本质可以理解成是JDBC的增强版，只不过Java原生的JDBC仅支持单数据源的连接，而Sharding-JDBC则支持多数据源的管理，部署形态如下：

JDBC部署形态

Java-ORM框架在执行SQL语句时，Sharding-JDBC会以切面的形式拦截发往数据库的语句，接着根据配置好的数据源、分片规则和路由键，为SQL选择一个目标数据源，然后再发往对应的数据库节点处理。

Sharding-JDBC在整个业务系统中对性能损耗极低，但为何后面又会推出Sharding-Proxy呢？因为Sharding-JDBC配置较为麻烦，比如在分布式系统中，任何使用分库分表的服务都需要单独配置多数据源地址、路由键、分片策略....等信息，同时它也仅支持Java语言，当一个系统是用多语言异构的，此时其他语言开发的子服务，则无法使用分库分表策略。

1.2、Sharding-Proxy中间件简介

也正是由于配置无法统一管理、不支持异构系统的原因，后面又引入Sharding-Proxy来解决这两个问题，Sharding-Proxy可以将其理解成一个伪数据库，对于应用程序而言是完全透明的，它会以中间件的形式独立部署在系统中，部署形态如下：

Proxy部署形态

使用Sharding-Proxy的子服务都会以连接数据库的形式，与其先建立数据库连接，然后将SQL发给它执行，Sharding-Proxy会根据分片规则和路由键，将SQL语句发给具体的数据库节点处理，数据库节点处理完成后，又会将结果集返回给Sharding-Proxy，最终再由它将结果集返回给具体的子服务。

但Sharding-Proxy虽然可以实现分库分表配置的统一管理，以及支持异构的系统，但因为需要使用独立的机器部署，同时还会依赖Zookeeper作为注册中心，所以硬件成本会直线增高，至少需要多出3~4台服务器来部署。

同时SQL执行时，需要先发给Proxy，再由Proxy发给数据库节点，执行完成后又会从数据库返回到Proxy，再由Proxy返回给具体的应用，这个过程会经过四次网络传输的动作，因此相较于原本的Sharding-JDBC来说，性能、资源开销更大，响应速度也会变慢。

1.3、JDBC、Proxy混合部署模式

如果用驱动式分库分表，虽然能够让Java程序的性能最好，但无法支持多语言异构的系统，但如果纯用代理式分库分表，这显然会损害Java程序的性能，因此在Sharding-Sphere中也支持JDBC、Proxy做混合式部署，也就是Java程序用JDBC做分库分表，其他语言的子服务用Proxy做分库分表，部署形态如下：

混合部署形态

这种混合式的部署方案，所有的数据分片策略都会放到Zookeeper中统一管理，然后所有的子服务都去Zookeeper中拉取配置文件，这样就能很方便的根据业务情况，来灵活的搭建适用于各种场景的应用系统，这样也能够让数据源、分片策略、路由键....等配置信息灵活，可以在线上动态修改配置信息，修改后能够在线上环境中动态感知。

但Sharding-Sphere还提供了一种单机模式，即直接将数据分片配置放在Proxy中，但这种方式仅适用于开发环境，因为无法将分片配置同步给多个实例使用，也就意味着会导致其他实例由于感知不到配置变化，从而造成配置信息不一致的错误。

二、Sharding-Sphere中的核心概念

分库分表中最重要的核心概念有两个，即路由键和分片算法，这两个将决定数据分片的位置，先稍微解释一下这两个概念：

• • 路由键：也被称为分片键，也就是作为数据分片的基准字段，可以是一个或多个字段组成。

• • 分片算法：基于路由键做一定逻辑处理，从而计算出一个最终节点位置的算法。

举个例子来感受一下，好比按user_id将用户表数据分片，每八百万条数据划分一张表，那在这里，user_id就是路由键，而按user_id做范围判断则属于分片算法，一张表中的所有数据都会依据这两个基础，后续对所有的读写SQL进行改写，从而定位到具体的库、表位置。

2.1、分库分表的工作流程

分库分表工作流程

在Sharding-Sphere这套技术中，无论是JDBC还是Proxy产品，工作的流程都遵循上述这个原则，里面除开上面介绍的路由键和分片算法的概念外，还有逻辑表、真实表、数据节点这三个概念：

• • 逻辑表：提供给应用程序操作的表名，程序可以像操作原本的单表一样，灵活的操作逻辑表。

• • 真实表：在各个数据库节点上真实存在的物理表，但表名一般都会和逻辑表存在偏差。

• • 数据节点：主要是用于定位具体真实表的库表名称，如DB1.tb_user1、DB2.tb_user2.....

  • • 均匀分布：指一张表的数量在每个数据源中都是一致的。

  • • 自定义分布：指一张表在每个数据源中，具体的数量由自己来定义，上图就是一种自定义分布。

以Java程序为例，编写业务代码时写的SQL语句，会直接基于逻辑表进行操作，逻辑表并不是一种真实存在的表结构，而是提供给Sharding-Sphere使用的，当Sharding-Sphere接收到一条操作某张逻辑表的SQL语句时，它会根据已配置好的路由键和分片算法，对相应的SQL语句进行解析，然后计算出SQL要落入的数据节点，最后再将语句发给具体的真实表上处理即可。

Sharding-Sphere-JDBC、Proxy的主要区别就在于：解析SQL语句计算数据节点的时机不同，JDBC是在Java程序中就完成了相应的计算，从Java程序中发出的SQL语句就已经是操作真实表的SQL了。而Proxy则是在Java应用之外做解析工作，它会接收程序操作逻辑表的SQL语句。然后再做解析得到具体要操作的真实表，然后再执行，同时Proxy还要作为应用程序和数据库之间，传输数据的中间人。

2.2、Sharding-Sphere中的表概念

除开上述的一些核心概念外，在Sharding-Sphere中为了解决某些问题，同时还有一些表概念，如广播表、绑定表、单表、动态表等，接着简单介绍一下这些概念。

2.2.1、绑定表

外键约束问题

当多张表之间存在物理或逻辑上的主外键关系，如果无法保障同一主键值的外键数据落入同一节点，显然在查询时就会发生跨库查询，这无疑对性能影响是极大的，所以在其中也提到过可以使用绑定表的形式解决该问题。

比如前面案例中的order_id、order_info_id可以配置一组绑定表关系，这样就能够让订单详情数据随着订单数据一同落库，简单的说就是：配置绑定表的关系后，外键的表数据会随着主键的表数据落入同一个库中，这样在做主外键关联查询时，就能有效避免跨库查询的情景出现。

2.2.2、广播表

跨库Join问题

当有些表需要经常被用来做连表查询时，这种频繁关联查询的表，如果每次都走跨库Join，这显然又会造成一个令人头疼的性能问题，所以对于一些经常用来做关联查询的表，就可以将其配置为广播表，广播表在有些地方也被称为同步表、网络表、全局表，但本质上表达的含义都相同，如下：

广播表

广播表是一种会在所有库中都创建的表，以系统字典表为例，将其配置为广播表之后，向其增、删、改一条或多条数据时，所有的写操作都会发给全部库执行，从而确保每个库中的表数据都一致，后续在需要做连表查询时，只需要关联自身库中的字典表即可，从而避免了跨库Join的问题出现。

2.2.3、单表

单表的含义比较简单，并非所有的表都需要做分库分表操作，所以当一张表的数据无需分片到多个数据源中时，就可将其配置为单表，这样所有的读写操作最终都会落入这一张单表中处理。

2.2.4、动态表

动态表的概念在Sharding-Sphere最新的5.x文档中已经移除了，但也可以基于分片算法去实现，所以虽然移除了动态表的概念，但也可以实现相同的效果，动态表的概念是指表会随着数据增长、或随着时间推移，不断的去创建新表，如下：

动态表

为了处理单月数据增长过高的问题，实现一套按月动态分表的方案，但在Sharding-Sphere中可以直接支持配置，无需自己去从头搭建，因此实现起来尤为简单，配置好之后会按照时间或数据量动态创建表。

2.3、Sharding-Sphere中的数据分片策略

前面聊到过，分库分表之后读写操作具体会落入哪个库中，这是根据路由键和分片算法来决定的，而Sharding-Sphere中的数据分片策略又分为：内置的自动化分片算法、用户自定义的分片算法两大类，Sharding-Sphere内置的算法涵盖取模分片、哈希分片、范围分片、时间分片等这积累常规算法，而自定义分片算法又可细分为：

• • 标准分片算法：适合基于单一路由键进行=、in、between、>、<、>=、<=...进行查询的场景。

• • 复合分片算法：适用于多个字段组成路由键的场景，但路由算法需要自己继承接口重写实现。

• • 强制分片算法：适用于一些特殊SQL的强制执行，在这种模式中可以强制指定处理语句的节点。

综上所述，在Sharding-Sphere内部将这四种分片策略称为：Inline、Standard、Complex、Hint，分别与上述四种策略一一对应，但这四种仅代表四种策略，具体的数据分片算法，可以由使用者自身来定义（后续会结合代码实战讲解）。

2.4、Sharding-Sphere的分库方式

在Sharding-Sphere生态中，支持传统的主从集群分库，如搭建出读写分离架构、双主双写架构，同时也支持按业务进行垂直分库，也支持对单个库进行横向拓展，做到水平分库。

但通常都是用它来实现水平分库和读写分离，因为分布式架构的系统默认都有独享库的概念，也就是分布式系统默认就会做垂直分库，因此无需引入S