Sharding-JDBC 分库分表

---

提示：以下是本篇文章正文内容，Java 系列学习将会持续更新

一、分库分表策略

在大型的互联网系统中，可能单台 MySQL 的存储容量无法满足业务的需求，这时候就需要进行扩容了。

和之前的问题一样，单台主机的硬件资源是存在瓶颈的，不可能无限制地纵向扩展，这时我们就得通过多台实例来进行容量的横向扩容，我们可以将数据分散存储，让多台主机共同来保存数据。

那么问题来了，怎么个分散法？

• 垂直拆分：我们的表和数据库都可以进行垂直拆分，所谓垂直拆分，就是将数据库中所有的表，按照业务功能拆分到各个数据库中（是不是感觉跟前面两章的学习的架构对应起来了）而对于一张表，也可以通过外键之类的机制，将其拆分为多个表。
  
• 水平拆分：水平拆分针对的不是表，而是数据，我们可以让很多个具有相同表的数据库存放一部分数据，相当于是将数据分散存储在各个节点上。
  

那么要实现这样的拆分操作，我们自行去编写代码工作量肯定是比较大的，因此目前实际上已经有一些解决方案了，比如我们可以使用 MyCat（也是一个数据库中间件，相当于挂了一层代理，再通过 MyCat 进行分库分表操作数据库，只需要连接就能使用）。类似的还有 ShardingSphere-Proxy 或是Sharding JDBC（应用程序中直接对 SQL 语句进行分析，然后转换成分库分表操作，需要我们自己编写一些逻辑代码）。

回到目录…

二、Sharding-JDBC

官方文档：https://shardingsphere.apache.org/document/5.1.0/cn/overview/#shardingsphere-jdbc

Sharding-JDBC 是一套开源的分布式数据库中间件解决方案，定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务，它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

• 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC；
• 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, HikariCP 等；
• 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可使用 JDBC 访问的数据库。

2.1 添加依赖

这里我们主要演示一下水平分表方式，我们直接创建一个新的 SpringBoot 项目即可，依赖如下：

<dependencies>
    <dependency>
        <groupId>org.apache.shardingsphere</groupId>
        <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
        <version>5.1.0</version>
    </dependency>
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>2.2.2</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.47</version>
    </dependency>
</dependencies>

回到目录…

2.2 分库策略

🍓2.2.1 数据库环境

①我们使用 Docker 开启两个 MySQL 容器，代表我们的两个数据库：

②分别给两个数据库创建可外网访问的用户

CREATE USER 'wsy'@'%' IDENTIFIED BY '123456';
grant all on *.* to 'wsy'@'%';
flush privileges;

③再给两个数据库创建相同的库表结构：

create database yyds;

CREATE TABLE test (
	id       int          not null primary key,
	name     varchar(30), 
	passwd   varchar(30)
);

回到目录…

🍓2.2.2 yml 配置数据源

我们是一个分库分表的状态，需要配置两个数据源：

spring:
  shardingsphere:
    datasource:
      # 有几个数据就配几个，这里是名称，按照下面的格式，名称+数字的形式
      names: db0,db1
      # 为每个数据源单独进行配置
      db0:
      	# 数据源实现类，这里使用默认的HikariDataSource
        type: com.zaxxer.hikari.HikariDataSource
        # 数据库驱动
        driver-class-name: com.mysql.jdbc.Driver
        # 不用我多说了吧
        jdbc-url: jdbc:mysql://1.15.76.95:3307/yyds
        username: wsy
        password: 123456
      db1:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://1.15.76.95:3308/yyds
        username: wsy
        password: 123456

启动主类，可以通过观察日志，发现连接成功：

回到目录…

🍓2.2.3 yml 配置分片算法

ShardingSphere 内置了很多分片算法，可以查询官网：shardingsphere-jdbc 分片算法。

现在我们就来编写配置文件，我们需要告诉 ShardingJDBC 要如何进行分片，首先明确：现在是两个数据库都有 test 表存放用户数据，我们目标是将用户信息分别存放到这两个数据库的表中。

spring:
  shardingsphere:
    rules:
      sharding:
        tables:
          #这里填写表名称，程序中对这张表的所有操作，都会采用下面的路由方案
          #比如我们上面Mybatis就是对test表进行操作，所以会走下面的路由方案
          test:
            #这里填写实际的路由节点，比如现在我们要分两个库，那么就可以把两个库、以及对应的表写上
            #也可以使用表达式简写为 db$->{0..1}.test
            actual-data-nodes: db0.test,db1.test
            #这里是分库策略配置
            database-strategy:
              #这里选择标准策略，也可以配置复杂策略，基于多个键进行分片
              standard:
                #参与分片运算的字段，下面的算法会根据这里提供的字段进行运算
                sharding-column: id
                #这里填写我们下面自定义的算法名称
                sharding-algorithm-name: my-alg
        sharding-algorithms:
          #自定义一个新的算法，名称随意
          my-alg:
            #算法类型，官方内置了很多种，这里演示最简单的一种
            type: MOD
            props:
              sharding-count: 2
    props:
      #开启日志，一会方便我们观察
      sql-show: true

这里我们使用的是 MOD，也就是取模分片算法。
 它会根据主键的值进行取模运算，比如我们插入的 id=2，那么就表示对主键进行模2运算，根据数据源的名称，比如 db0 就是取模后为 0，db1 就是取模后为 1。也就是说，最终实现的效果就是单数放在db1，双数放在db0，当然它还支持一些其他的算法，这里就不多介绍了。

回到目录…

🍓2.2.4 查看分库效果

我们需要对项目进行一些编写，添加我们的用户实体类和 Mapper：

@Data
@AllArgsConstructor
public class User {
    int id;
    String name;
    String passwd;
}

@Mapper
public interface UserMapper {

    @Select("select * from test where id = #{id}")
    User getUserById(int id);

    @Insert("insert into test(id, name, passwd) values(#{id}, #{name}, #{passwd})")
    int addUser(User user);
}

① 那么现在我们编写一个测试用例来看看，是否能够按照我们上面的规则进行路由：

@SpringBootTest
class ShardingJdbcStudyApplicationTests {
    @Resource
    private UserMapper userMapper;

    @Test
    void contextLoads() {
        for (int i = 1; i <= 10; i++) {
            // 像数据库插入 1~10 用户
            userMapper.addUser(new User(i, "xx-" + i, "123456"));
        }
    }
}

观察控制台日志，发现是交替插入两个数据库：

查看两个数据库：

② 当我们测试查询用户时，

@Test
void contextLoads2() {
    for (int i = 1; i <= 10; i++) {
        User user = userMapper.getUserById(i);
    }
}

发现它也是轮询去两个数据库查询的。

这样我们就很轻松地实现了分库策略。

回到目录…

2.3 分表策略

接着我们来看分表，比如现在我们的数据库中有 test_0 和 test_1 两张表，表结构一样，但是我们也是希望能够根据 id 取模运算的结果分别放到这两个不同的表中，实现思路其实是差不多的。

这里首先需要介绍一下两种表概念：

• 逻辑表：相同结构的水平拆分数据库（表）的逻辑名称，是 SQL 中表的逻辑标识。 例：订单根据主键尾数拆分为 10 张表，分别是 t_order_0 到 t_order_9，他们的逻辑表名为 t_order。
• 真实表：在水平拆分的数据库中真实存在的物理表。 即上个示例中的 t_order_0 到 t_order_9 这十张表。

🍒2.3.1 数据库环境

现在我们就以一号数据库为例，那么我们在里面创建上面提到的两张表，之前的那个 test 表删不删都可以，就当做不存在就行了：

create table test_0  (
  `id` int primary key,
  `name` varchar(255) NULL,
  `passwd` varchar(255) NULL
);

create table test_1  (
  `id` int primary key,
  `name` varchar(255) NULL,
  `passwd` varchar(255) NULL
);

回到目录…

🍒2.3.2 yml 配置分表策略

接着我们不要去修改任何的业务代码，Mybatis 里面写的是什么依然保持原样，即使我们的表名已经变了，我们需要做的是通过路由来修改原有的 SQL，配置如下：

spring:
  shardingsphere:
    rules:
      sharding:
        tables:
          #这里填写表名称，程序中对这张表的所有操作，都会采用下面的路由方案
          #比如我们上面Mybatis就是对test表进行操作，所以会走下面的路由方案
          test:
            #这里填写实际的路由节点，比如现在我们要分到db0库的两张表上
            #也可以分开写为 db0.test_0,db0.test_1
            actual-data-nodes: db0.test_$->{0..1}
            #现在我们来配置一下分表策略，注意这里是 table-strategy，分库是用 database-strategy
            table-strategy:
              #基本都跟之前是一样的
              standard:
                sharding-column: id
                sharding-algorithm-name: my-alg
        sharding-algorithms:
          my-alg:
            #选择算法类型，INLINE支持我们自行编写表达式
            type: INLINE
            props:
              #比如我们还是希望进行模2计算得到数据该去的表
              #只需要给一个最终的表名称就行了test_，后面的数字是表达式取模算出的
              #实际上这样写和MOD模式一模一样
              algorithm-expression: test_$->{id % 2}
              #查询也会根据分片策略来进行。如果我们进行范围查询，实际上依然会进行全量查询
              #INLINE算法默认是不支持进行全量查询的，所以我们应该设为 true
              allow-range-query-with-inline-sharding: true
    props:
      #开启日志，一会方便我们观察
      sql-show: true

分片算法有很多内置的，可以在这里查询官网：shardingsphere-jdbc 分片算法。

回到目录…

🍒2.3.3 查看分表效果

① 我们来测试一下，看看会不会按照我们的策略进行分表插入：

② 再来看看查询，也会根据我们配置的策略，选择对应的表进行：

③ 当我们进行范围查询时，又是怎样的？

注意：INLINE 算法默认是不支持进行全量查询的，我们得手动允许

allow-range-query-with-inline-sharding: true

否则，会有以下报错：

我们现在向 Mapper 中添加一条 SQL 接口：

@Select("select * from test where id between #{start} and #{end}")
List<User> getUsersByIdRange(int start, int end);

我们来测试一下：

@Test
void contextLoads3() {
    List<User> list = userMapper.getUsersByIdRange(3, 8);
}

我们可以发现，内部真正执行的 SQL 是分别查询了两张表，并将结果进行了合并。

这样我们就很轻松地实现了分表策略。

回到目录…

2.4 分布式序列算法

在复杂分布式系统中，特别是微服构架中，往往需要对大量的数据和消息进行唯一标识。随着系统的复杂，数据的增多，分库分表成为了常见的方案，对数据分库分表后需要有一个唯一 ID 来标识一条数据或消息（如订单号、交易流水、事件编号等），此时一个能够生成全局唯一ID的系统是非常必要的。

比如我们之前创建过学生信息表、图书借阅表、图书管理表，所有的信息都会有一个ID作为主键，并且这个ID有以下要求：

1. 为了区别于其他的数据，这个ID必须是全局唯一的。
2. 主键应该尽可能的保持有序，这样会大大提升索引的查询效率。

那么我们在分布式系统下，如何保证ID的生成满足上面的需求呢？

🍌2.4.1 UUID

UUID 是由一组 32 位数的16进制数字随机构成的，我们可以直接使用 JDK 为我们提供的 UUID 类来创建：

public static void main(String[] args) {
    String uuid = UUID.randomUUID().toString();
    System.out.println(uuid);
}

结果为 73d5219b-dc0f-4282-ac6e-8df17bcd5860，生成速度非常快，可以看到确实是能够保证唯一性，因为每次都不一样，而且这么长一串那重复的概率真的是小的可怜。

但是它并不满足我们上面的第二个要求，也就是说我们得到的都是一些无序的ID。

🍌2.4.2 雪花算法（Snowflake）

我们来看雪花算法，它会生成一个一个 64bit 大小的整型的 ID，int 肯定是装不下了。

可以看到它主要是三个部分组成，时间 + 工作机器ID + 序列号，时间以毫秒为单位。

• 41 个 bit 位能表示约70年的时间，时间纪元从 2016年11月1日 零点开始，可以使用到 2086 年。
• 工作机器ID 其实就是节点ID，每个节点的ID都不相同，那么就可以区分出来，10 个bit位可以表示最多1024个节点。
• 最后 12 位就是每个节点下的序列号，因此每台机器每毫秒就可以有 4096 个系列号。

这样，它就兼具了上面所说的唯一性和有序性了。这已经是市面上最好的方案了，但是依然是有缺点的：第一个是时间问题，如果机器时间出现倒退，那么就会导致生成重复的ID。第二是节点容量只有1024个，如果是超大规模集群，也是存在隐患的。

回到目录…

🍌2.4.3 ShardingJDBC 实现

Sharding-JDBC 支持以上两种算法为我们自动生成 ID，文档： ShardingSphere-JDBC > 内置算法 > 分布式序列算法。

我们以 ShardingJDBC 的雪花算法为例，来为我们生成唯一 ID。

① 首先是配置数据库，我们两个数据库的 test 表的 id 是 int 类型，装不下64位的，改为 bigint 类型：

ALTER TABLE `yyds`.`test` MODIFY COLUMN `id` bigint NOT NULL FIRST;

② 接着我们需要修改一下 Mybatis 的插入语句，因为现在 id 是由 ShardingJDBC 自动生成，不需要手动插入了：

@Insert("insert into test(name, passwd) values(#{name}, #{passwd})")
int addUser(User user);

③ 接着我们在 yml 中配置：还是采用分库策略、自定义主键生成算法

spring:
  shardingsphere:
    rules:
      sharding:
        tables:
          test:
            actual-data-nodes: db0.test,db1.test
            #这里还是分库策略
            database-strategy:
              standard:
                sharding-column: id
                sharding-algorithm-name: my-alg
            #这里使用自定义的主键生成策略
            key-generate-strategy:
              column: id
              key-generator-name: my-gen
        key-generators:
          #这里写我们自定义的主键生成算法
          my-gen:
            #使用雪花算法
            type: SNOWFLAKE
            props:
              #工作机器ID，保证唯一就行
              worker-id: 666
        sharding-algorithms:
          my-alg:
            type: MOD
            props:
              sharding-count: 2

回到目录…

🍌2.4.4 查看效果

我们来编写一下测试用例：

@Test
void contextLoads4() {
    for (int i = 1; i <= 20; i++) {
        mapper.addUser(new User("aaa" + i, "123456"));
    }
}

查看日志：在插入的时候，将我们的 SQL 语句自行添加了一个 id 字段，并且使用的是雪花算法生成的值。

查看数据库：没有任何问题，插入了唯一ID，也是按照分库策略进行的插入。

回到目录…

2.5 读写分离

我们来看看读写分离，我们之前实现了 MySQL 的主从复制：MySQL与分布式：主从复制

那么我们就基于之前的主从结构，实现读写分离，主库作为写，从库作为读：

🍆2.5.1 数据库主从结构

① 我们之前在 Docker 中开启了两个 MySQL 容器，代表一主一从的结构：

② 注意：我们需要将从库开启只读模式，在 MySQL 配置文件中添加如下：

# 仅对普通用户有效，超级用户root还是可以插入数据的
read-only    = 1

③ 从库重启后，重新搭建主从结构，搭建成功！

④ 主库创建我们需要操作的库表信息，从库也随之有了：

create database yyds;

CREATE TABLE test (
	id       int          not null primary key,
	name     varchar(30), 
	passwd   varchar(30)
);

总结一下：具体信息

	主库	从库
docker 容器名	mysql-master	mysql-slave
mysql 映射端口	3301	3302
mysql 远程访问用户	wsy, 123456	wsy, 123456
库名	yyds	yyds
yyds 表名	test	test
test 表字段	(id, name, passwd)	(id, name, passwd)

回到目录…

🍆2.5.2 yml 配置数据源

spring:
  shardingsphere:
    datasource:
      names: master-db,slave-db
      master-db:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://1.15.76.95:3301/yyds
        username: wsy
        password: 123456
      slave-db:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://1.15.76.95:3302/yyds
        username: wsy
        password: 123456

🍆2.5.3 yml 配置读写分离

当有多个 slave 时，就需要进行负载均衡了。官方提供了很多负载均衡算法： ShardingSphere-JDBC > 内置算法 > 负载均衡算法

spring:
  shardingsphere:
    rules:
      #配置读写分离
      readwrite-splitting:
        data-sources:
          #名称随便写
          user-db:
            #这里使用静态类型，动态Dynamic类型可以自动发现auto-aware-data-source-name，这里不演示
            type: Static
            props:
              #配置写库（只能一个）
              write-data-source-name: master-db
              #配置从库（多个，逗号隔开）
              read-data-source-names: slave-db
              #负载均衡策略，可以自定义
              load-balancer-name: my-load
        load-balancers:
          #自定义的负载均衡策略
          my-load:
            type: ROUND_ROBIN
    props:
      sql-show: true

回到目录…

🍆2.5.4 查看读写分离效果

① 编写一个测试用例：写操作

@Test
void contextLoads5() {
    userMapper.addUser(new User(1, "zhangsan", "123456"));
    userMapper.addUser(new User(2, "lisi", "123456"));
    userMapper.addUser(new User(3, "wangwu", "123456"));
}

查看控制台日志：发现确实只向主库插入了数据。

查看数据库：虽然没有直接向从库插入数据，但从库依然同步了数据。

② 再编写一个测试用例：读操作

@Test
void contextLoads6() {
    User user1 = userMapper.getUserById(1);
    User user2 = userMapper.getUserById(2);
    User user3 = userMapper.getUserById(3);
}

查看控制台日志：发现确实只向从库读取了数据。

回到目录…

---

总结:
提示：这里对文章进行总结：
本文是对Sharding-JDBC的学习，学习了如何分库分表，了解了它内置的分片算法；又使用了Sharding提供的分布式序列算法：雪花算法；最后又用Sharding实现了主从结构下数据库的读写分离。之后的学习内容将持续更新！！！