在大数据时代，随着业务数据量的不断增长，单一的数据库往往难以承载大规模的数据处理需求。数据库分片（Sharding）是一种有效的数据库扩展技术，通过将数据分布到多个数据库实例上，提高系统的性能和可扩展性。

ShardingSphere 是一款开源的分布式数据库中间件，可以帮助我们轻松实现数据库分片。

本文的目的是介绍如何快速上手使用 ShardingSphere来实现 MySQL 数据库分片。

一、ShardingSphere 简介

ShardingSphere 是 Apache 基金会下的一个开源项目，提供分布式数据库中间件解决方案。ShardingSphere 已经在2020年4月16日从 Apache 孵化器毕业，成为 Apache 顶级项目。其主要功能包括数据分片（Sharding）、读写分离、分布式事务以及数据加密等。ShardingSphere 主要由三个核心组件组成：

Sharding-JDBC：轻量级的 Java 框架，直接集成在应用程序中，提供数据库分片、读写分离等功能。需要在 spring boot 中集成，编写相关的配置。如果分片策略用默认的4种，那可以只改配置就好了。如果分片策略很特殊，可以通过实现抽象类，写自定义的方法进行分片分库。
Sharding-Proxy：独立部署的数据库代理，支持所有兼容 MySQL、PostgreSQL 协议的客户端。原来程序连接到这个代理就可以实现分片和分库。程序不需要任何改变。
Sharding-Sidecar（Plan）：云原生环境下的数据库代理，与 Kubernetes 等平台集成。

1.1 对比

| |Sharding-JDBC| Sharding-Proxy| Sharding-Sidecar| |--|--|--|--| |数据库| 任意| MySQL/PostgreSQL| MySQL/PostgreSQL| 连接消耗数| 高| 低| 高| 异构语言| 仅Java| 任意| 任意| 性能 |损耗低| 损耗略高|损耗低| 无中心化| 是| 否| 是| 静态入口| 无 |有| 无|

1.2 核心概念

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

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

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

在这里插入图片描述

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

逻辑表：提供给应用程序操作的表名，程序可以像操作原本的单表一样，灵活的操作逻辑表。
真实表：在各个数据库节点上真实存在的物理表，但表名一般都会和逻辑表存在偏差。
数据节点：主要是用于定位具体真实表的库表名称，如DB1.tb_user1、DB2.tb_user2.....
均匀分布：指一张表的数量在每个数据源中都是一致的。
自定义分布：指一张表在每个数据源中，具体的数量由自己来定义，上图就是一种自定义分布。

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

1.3 Sharding-Sphere中的表概念

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

1.3.1 绑定表

一般的项目基本上都会存在主外键，虽然不会在表上添加主外键约束，但也会从逻辑上保障主外键关系，但经过水平分库后，所有的读写操作会基于路由键去分片。

那此时以订单表、订单详情表为例，假设用户选择了三个购物车的商品提交订单，此时会产生

一条订单记录
以及对应的三条订单详情记录。

假设商品库有两个水平节点，两个商品库都具备订单表、订单详情表，而订单表的路由键是 order_id，订单详情表的路由键是 order_info_id ，数据分片的路由算法为取模，那此时数据的落库情况为：

订单详情2数据落入 DB0 商品库中。
订单详情1、详情3数据落入 DB1 商品库中。

但此时订单表和订单详情表的数据是存在外键关系的，如果按照上述的路由方式去对数据做分片，最终就会导致通过 order_id=1 的订单 ID 查询订单详情时，只能在 DB1 中查询到两条订单详情数据，这个问题显然是业务上无法接受的。通常我们会将这两张表配置为绑定表，以确保它们在同一个分片中，从而优化订单相关的联表查询操作。

1.3.2 广播表

广播表是指在所有分片数据源中都存在的一张表，且数据内容完全相同。这种表通常用于存储一些公共的、全局性的数据，比如系统配置、国家代码等。由于广播表的数据是全局一致的，当有更新操作时，需要将变更同步到所有的分片数据源中。

在不同的库需要数据的表中冗余字段，把常用的字段放到需要要数据的表中，避免跨库连表。
选择同步数据，通过广播表/网络表/全局表将对应的表数据直接完全同步一份到相应库中。
在设计库表拆分时创建 ER 绑定表，具备主外键的表放在一个库，保证数据落到同一数据库
Java 系统中组装数据，通过调用对方服务接口的形式获取数据，然后在程序中组装后返回

这四种方案都能够解决需要跨库 Join 的问题，但第二种方案提到了广播表/网络表/全局表似乎之前没听说过对嘛，这其实是分库分表中的名词。场景：假设有一个 t_country 表，存储国家和地区的信息，这些信息在整个系统中是统一的，因此可以将 t_country 作为广播表，在所有数据库实例中都保存一份副本。

但往往垂直分库的场景中，第四种方案是最常用的，因为分库分表的项目中，Java 业务系统那边也绝对采用了分布式架构，因此通过调用对端 API 接口来获取数据，是分布式系统最为常见的一种现象。

1.3.3 单表

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

二、ShardingSphere-JDBC

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

Apache ShardingSphere-JDBC 可以通过Java 和 YAML 这 2 种方式进行配置，开发者可根据场景选择适合的配置方式。

2.2 原理

Sharding-JDBC 中的路由结果是通过分片字段和分片方法来确定的,如果查询条件中有 id 字段的情况还好，查询将会落到某个具体的分片

如果查询没有分片的字段，会向所有的db或者是表都会查询一遍，让后封装结果集给客户端。

在这里插入图片描述

接下来会搭建一个简单的SpringBoot+MyBatis项目，结合Sharding-Sphere-JDBC实现水平分库~

spring boot整合

<!-- 分表分库依赖 -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
    <version>5.2.1</version>
</dependency>

数据库

接着先在数据库中创建db_sharding_01、db_sharding_02两个库，我这里用伪集群的方式搭建水平库，毕竟线上只需要把数据库地址改为不同的机器IP即可

接着分别再在两个水平库中，创建用户表、订单表、订单详情表、商品表（两张），这四张表是接下来用于测试的表，SQL如下：

drop table if exists `user_info`;
create table `user_info`  (
  `user_id` bigint not null comment '用戶id',
  `user_name` varchar(255) comment '用戶姓名',
  `user_sex` varchar(255) comment '用戶性別',
  `user_age` int(8) not null comment '用戶年齡',
  primary key (`user_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci 
row_format = compact;
 
 
drop table if exists `shoping_00`;
create table `shoping_00`  (
  `shoping_id` bigint not null comment '商品id',
  `shoping_name` varchar(255) comment '商品名称',
  `shoping_price` int(8) not null comment '商品价格',
  primary key (`shoping_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci 
row_format = compact;
 
 
drop table if exists `shoping_01`;
create table `shoping_01`  (
  `shoping_id` bigint not null comment '商品id',
  `shoping_name` varchar(255) comment '商品名称',
  `shoping_price` int(8) not null comment '商品价格',
  primary key (`shoping_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci 
row_format = compact;
 
 
drop table if exists `order`;
create table `order`  (
  `order_id` bigint not null comment  '订单号',
  `order_price` int(8) not null comment '订单总金额',
  `user_id` bigint not null comment '用戶id',
  primary key (`order_id`) using btree
) 
engine = InnoDB
character set = utf8
collate = utf8_general_ci 
row_format = compact;
 
 
drop table if exists `order_info`;
create table `order_info`  (
  `order_info_id` bigint not null comment  '订单详情号',
  `order_id`  bigint not null comment '订单号',
  `shoping_name` varchar(255)  comment '商品名称',
  `shoping_price` int(8) not null comment '商品价格',
  primary key (`order_info_id`) using btree,
  index `key_order_id`(`order_id`) using btree
)
engine = InnoDB
character set = utf8
collate = utf8_general_ci 
row_format = compact;

分库分表的核心配置

Sharding-Sphere的所有产品对业务代码都是零侵入的，无论是Sharding-JDBC也好，Sharding-Proxy也罢，都不需要更改业务代码，这也就意味着大家在分库分表环境下做业务开发时，可以像传统的单库开发一样轻松，Sharding-Sphere中最主要的是对配置文件的更改，Sharding-JDBC主要修改application.properties/yml文件，Sharding-Proxy主要修改自身的配置文件。

多数据源配置

spring:
  shardingsphere:
    mode:
      type: Standalone
      repository:
        type: JDBC
    datasource:
      names: ds0,ds1
      ds0:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: 「数据库节点1的地址」
        username: 「数据库节点1的账号」
        password: 「数据库节点1的密码」
      ds1:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: 「数据库节点2的地址」
        username: 「数据库节点1的账号」
        password: 「数据库节点1的密码」

上述这组配置中，需要通过names配置多个数据源的别名，接着需要为每个别名配置对应的数据源信息，按照上述方式编写好配置文件后，则表示完成了多数据源的配置。

多数据源可用性测试

为了确保多数据源的可用性，接着先简单配置一张表：

spring:
  shardingsphere:
    
    props:
      
      sql-show: true
 
    
    rules:
      
      sharding:
        
        tables:
          
          shoping:
            
            actual-data-nodes: ds0.shoping_00

使用shardingsphere实现mysql数据库分片