关于Sharding-Sphere分库分表框架的保姆级教学！

谁践踏了优雅 2024-03-25 16:46 63阅读 0赞

> 在分库分表领域中，其实有许许多多的一些落地技术栈，如`TDDL、TSharding、Sharding-Sphere、MyCat、Atlas、Oceanus、Vitess.....`，但经时间沉淀与岁月洗礼后，如今主流的方案也就剩下了`MyCat、Sharding-Sphere`两种，`MyCat`近几年由于某些原因，开始逐渐走下坡路，反观投入`Apache`怀抱的`Sharding-Sphere`热度逐步上升，其目前的最新版本也相对稳定。

正是由于上述原因，如今越来越多的企业选用`Sharding-Sphere`作为分库分表的落地方案

### 一、初识Apache-Sharding-Sphere生态 ###

![format_png][]

`Apache-Sharding-Sphere`的前身是当当网开源的`Sharding-JDBC`框架，后面引入`Zookeeper`作为注册中心，又研发了`Sharding-Proxy`中间件，贡献给`Apache`软件基金会后，正式整合成`Sharding-Sphere`生态，并且支持、兼容各种数据库，[Apache-Sharding-Sphere官网][Apache-Sharding-Sphere]上可看到的发展历程如下：  
  
目前最新的`5.2.1`版本属于其中`5.x`阶段的一个版本，目前支持可可拔插功能，其支持的核心功能如下：  
  
在该版本中都有对应的解决方案，如多表连查、数据分片、分布式事务、数据迁移与扩容、分布式`ID.....`，在预计`2023`年发布的`6.x`版本中会结合各类云容器技术，全面兼容与拥抱云生态，在预计`2025`年发布的`7.x`版本中，则会彻底落实`Databases-Plus`理念，支持将各类数据库作为可拔插式存储引擎使用，也意味着像`MySQL`的可拔插式引擎那样，在`Sharding-Sphere`中使用`MySQL、Oracle、PgSQL、SQL-Server....`等关系型数据。

> 其实看到这里大家会发现，`Sharding-Sphere`作为`Apache`软件基金会的顶级项目，其内部对于它的未来规划十分明确，主要就是构建一个分库分表技术的生态圈，就类似于`Spring`框架在`J2EE`中的地位一样，迄今为止已发行的`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`则支持多数据源的管理，部署形态如下：

![format_png 1][]

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

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

#### 1.2、Sharding-Proxy中间件简介 ####

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

![format_png 2][]

使用`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`做分库分表，部署形态如下：

![format_png 3][]

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

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

### 二、Sharding-Sphere中的核心概念 ###

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

*  路由键：也被称为分片键，也就是作为数据分片的基准字段，可以是一个或多个字段组成。
 *  分片算法：基于路由键做一定逻辑处理，从而计算出一个最终节点位置的算法。

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

#### 2.1、分库分表的工作流程 ####

![format_png 4][]

在`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、绑定表

![format_png 5][]

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

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

2.2.2、广播表

![format_png 6][]

当有些表需要经常被用来做连表查询时，这种频繁关联查询的表，如果每次都走跨库`Join`，这显然又会造成一个令人头疼的性能问题，所以对于一些经常用来做关联查询的表，就可以将其配置为广播表，广播表在有些地方也被称为同步表、网络表、全局表，但本质上表达的含义都相同，如下：  
  
广播表是一种会在所有库中都创建的表，以系统字典表为例，将其配置为广播表之后，向其增、删、改一条或多条数据时，所有的写操作都会发给全部库执行，从而确保每个库中的表数据都一致，后续在需要做连表查询时，只需要关联自身库中的字典表即可，从而避免了跨库`Join`的问题出现。

2.2.3、单表

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

2.2.4、动态表

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

![format_png 7][]

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

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

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

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/f6bd2b5d591f4da289ee1d62d897dbaf.png
[Apache-Sharding-Sphere]: https://link.juejin.cn?target=https%3A%2F%2Fshardingsphere.apache.org%2Findex_zh.html
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/c920b210f91642af8c4f0df9c2a69949.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/ef1ff35c8c134533963ba33f86801110.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/6bf8f1127b2143f08f614ddc9a37ffed.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/4b27136c35f9430a82c36a9970945fba.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/2374d43ef30f497ea91fd85b7e3b36a2.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/335f7fb6d0d14907b38bccbd199734b2.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/da258dc7654e4906934d3950d2bcb522.png