关于java:ShardingJDBC入门

1. 简介

1.1 分库分表是什么

​ 电商平台，在开发中波及店铺、商品的相干业务，设计如下数据库

通过以下 SQL 可能获取到商品相干的店铺信息、天文区域信息：

SELECT p.*,r.[天文区域名称],s.[店铺名称],s.[信用]
FROM [商品信息] p
LEFT JOIN [店铺信息] r ON p.[产地] = r.[天文区域编码]
LEFT JOIN [店铺信息] s ON p.id  = s.[所属店铺]
WHERE p.id = ?

造成相似一下展现：

​

随着零碎商品的倒退，数据库中的数据量猛增，拜访性能也变慢了，优化火烧眉毛。剖析一下问题呈现在哪？关系型数据库自身就比拟容易成为零碎瓶颈，单机存储容量、连接数、解决能力都无限。当单表的数据量达到 1000W 或 100G 当前，因为查问维度较多，即便增加从库、优化索引、做很多操作时性能依然降落重大。

​ 计划 1：

​ 通过晋升服务器硬件能力来体高解决能力，比减少存储容量、CPU 等，这种计划老本很高，并且如果瓶颈在 mysql 自身那么进步硬件也是无限的。

  计划 2：

​ 把数据扩散到不同的数据库中，使得繁多数据库的数据质变小来缓解数据库的性能问题，从而达到晋升数据库性能的目标。如下图: 将电商数据库拆分为若干独立的数据库，并且对于大表也拆分为若干小表，通过这种数据库拆分的办法来解决数据库的性能问题。

​

​ 分库分表就是为了解决因为数据量过大而导致数据库性能升高的问题，将原来独立的数据库拆分成若干数据库组成，将数据大表拆分成若干数据组成，使得繁多数据库、繁多数据表的数据质变小，从而达到晋升数据库性能的目标。

1.2 分库分表的形式

​ 分库分表包含分库和分表两种，在生产中通常包含：垂直分库 、 程度分库 、 垂直分表 、 程度分表 四种形式。

1.2.1. 垂直分表

​ 下边通过一个商品查问案例解说垂直分表：

​ 通常在商品列表中是不显示山商品详情信息的，如下图：

用户在浏览器列表时，只有对某商品感兴趣时才会查看该商品的详细描述。因而，商品信息中的商品名称、商品图片、商品价格等其余字段数据拜访频次较高。

​ 因为这两种数据的个性不一样，因而他思考将商品信息拆分如下：

将拜访频次低的商品形容信息独自寄存在一张表中，拜访频次较高的商品根本信息独自放在一张表中。

商品列表可采纳以下 sql:

SELECT P.*,r.[天文区域名称],s.[店铺名称],s.[信用]
FROM [商品信息] p
LEFT JOIN [天文区域] ON p.[产地] = r.[天文区域编码]
LEFT JOIN [店铺信息] ON p.id = s.[所属店铺]
WHERE ... ORDER BY ... LIMIT

须要获取商品形容时，再通过以下 sql 获取：

SELECT *
FROM [商品形容]
WHERE [商品 ID] = ?

这就叫做 垂直分表

垂直分表定义：将一个表依照字段分成多表，每个表存储其中一部分字段。

它带来的晋升是：

1. 为了防止 IO 争抢并缩小锁表的几率，查看详情的用户与商品信息浏览互不影响

2. 充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品形容的低效率所连累。

<!– 为什么大字段 IO 效率低：第一是因为数据量自身大，须要更长的读取工夫；第二是跨页，页页数是数据库存储单位，很多查找及定位操作都是以页为单位，单页内的数据行越多数据库整体性能越好，而大字段占用空间大，单页内存储行数少，因而 IO 效率较低。第三，数据库已行为单位将数据加载到内存中，这样表中字段长度较短且拜访频率较高，内存能加载更多的数据，命中率更高，缩小了磁盘 IO, 从而晋升了数据库性能。–>

​ 一般来说，某业务实体中的各个数据项的拜访频次是不一样的，局部数据项可能占用存储空间比拟大的 BLOB 或是 TEXT。例如上列中的 商品形容 。所以，当表数据量很大时，能够 将表按字段切开，将热门字段，冷门字段离开搁置再不同库中，这些库能够放在不同的存储设备上，防止 IO 争抢。垂直切分带来的性能晋升次要集中在热门数据的操作效率上，而磁盘争用状况缩小。

通常咱们依照以下准则进行垂直拆分：

​ 1. 把不罕用的字段独自放入一张表；

​ 2. 把 text,blog 等大字段拆分进去放在附表中；

1.2.2. 垂直分库

​ 通过垂直分表性能失去了肯定水平的晋升，然而还没有达到要求，并且磁盘空间也快不够了，因为数据还是始终限度在一台服务器，库内垂直分表只解决了繁多表数据量过大的问题，但没有将表散布到不同的服务器上，因而每个表还是竞争同一个物理机的 CPU, 内存、网络 IO、磁盘。

​ 通过思考，他把原有 SELLER_DB(卖家库)，分为了 PRODUCT_DB(商品库)和 STORE_DB(店铺库)，并把这两个库扩散到不同的服务器，如下图:

因为 商品信息 与商品形容 业务耦合度较高，因而一起被寄存在 PRODUCT_DB(商品库); 而 店铺信息 绝对独立，因而独自被寄存在 STORE_DB(店铺库)。

​ 这一步优化就叫做 垂直分库。

​ 垂直分库 是指依照业务将表进行分类，散布到不同的数据库下面，每个库能够放在不同的服务器上，它的核心理念是专库专用。

它带来的晋升是：

• 解决业务层面的耦合，业务清晰
• 能对不同业务的数据进行分级管理、保护、监控、拓展等
• 高并发场景下，垂直分库肯定水平的晋升 IO、数据库连接数、升高单机硬件资源的瓶颈
• 垂直分库通过将表按业务分类，然而仍然没有解决单数据量过大的问题。

1.2.3. 程度分库

​ 通过 垂直分库 后，数据库性能问题失去了肯定层度的解决，然而随着业务量的增长，PRODUCT_DB(商品库)单库存储曾经超出预估。粗略预计，目前有假如有 8w 店铺，每个店铺均匀 150 个不同规格的商品，在算上增长，那商品数量的往 1500w+ 上预估，并且 PRODUCT_DB(商品库)属于拜访十分频繁的资源，单台服务器曾经无奈撑持。此时此刻如何优化？

​ 再次分库？然而从业务角度剖析，目前状况曾经无奈再次垂直分库。

​ 尝试程度分库，将店铺 ID 复数的和店铺 ID 为单数的商品信息别离在放在两个库中。

​ 也就是说，要操作某条数据，先剖析这条数据所属的店铺 ID。如果店铺 ID 为单数，将此操作映射到 PRODUCT_DB1(商品库 1)；如果店铺 ID 为复数，将操作映射到 PRODUCT_DB2(商品库 2)。此操作要拜访数据库名称的表达式PRODUCT_DB[商品库 ID%2 +1]。

​ 这进一步优化叫做 程度分库。

​ 程度分库 是把同一个表是数据按肯定规定拆到不同的数据库中，每个库能够放在不同的服务器上。

<!– 比照：垂直分库是把不同表拆分到不同数据库中，它是对数据行进行拆分，不影响表构造 –>

它带来的晋升是：

• 解决了单库大数据，高并发的性能的瓶颈
• 进步了零碎的稳定性及可用性。<!– 稳定性体现在 IO 抵触缩小，锁定缩小，可用性指某个库呈现问题，局部可用 –>

1.2.4. 程度分表

  依照程度分表的思路对他把 PRODUCT_DB_X(商品库)内的表也能够进行程度拆分，其目标也是为解决单表数据量大的问题，如下图:

与程度分库的思路相似，不过这次操作的指标是表，商品信息及商品形容被拆分了两层。如果商品 ID 为单数，将此操作映射至商品信息 1 表；如果商品 ID 为复数，将此操作映射至商品信息 2 表。此操作要拜访名称的表达式为 商品信息[商品 ID%2+1]。

​ 这进一步优化叫做 程度分表。

​ 程度分表 是在同一个数据库内，把同一个表的数据按肯定规定拆到多个表中。

​ <!– 对数据行的拆分，不影响表构造 –>

​ 它带来的晋升是：

• 优化繁多表数据量过大而产生的性能问题
• 防止 IO 争抢并缩小锁表的几率

​ 库内的程度分表，解决了繁多表数据量过大的问题，分进去的小表中只蕴含一部分数据，从而进行使得单个表的数据质变小，进步检索性能。

1.2.5. 小结

本章介绍了分库分表的各种形式，他们别离是垂直分表、垂直分库、程度分库和程度分表：

垂直分表：能够把一个宽表的字段拜访频次、是否是大字段的准则拆分为多个表，这样既能使业务清晰，还能晋升局部性能。拆分后，尽量从业务角度防止联查，否则性能方面将的得失相当。

垂直分库：能够把多个表按业务耦合松紧归类，别离寄存在不同的库，这些库能够散布在不同服务器，从而是拜访压力被多服务器负载，大大晋升性能，同时能进步整体叫否的业务清晰度，不同的业务库可依据本身状况定制优化计划。然而它须要解决跨库带来的所有简单问题。

程度分库 ：能够把一个表的数据(按数据行) 分到多个不同的库，每个库只有这个表的局部数据，这些库能够散布在不同服务器，从而使拜访压力被多服务器负载，大大晋升性能。它不仅须要解决跨库带来的所有简单问题，还要解决数据路由的问题。

程度分表 ：能够把一个表的数据(按数据行) 分到多个同一个数据库中的多个表中，每个表只有这个表的局部数据，这样做能小幅度晋升性能，它仅仅作为程度库的一个补充优化。

一般来说，在零碎设计阶段就应该依据业务耦合松紧原确定垂直分库，垂直分表，计划，在数据量及拜访压力不是特地大的状况，首先思考缓存，读写拆散、索引技术等计划，若数据量极大，且持续增长，在思考程度分库，程度分表。

1.3 分库分表带来的问题

​ 分库分表能无效的缓解了单机和单库带来的性能瓶颈和压力，冲破网络 IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。

1.3.1. 事务一致性问题

​ 因为分库分表把数据分布在不同库甚至不同服务器，不可避免带来分 布式事务 问题。

1.3.2. 跨节点关联查问

在没有分库前，咱们索引商品时能够通过以下 SQL 比照店铺信息进行关联查问；

SELECT p.*,r.[天文区域名称],s.[店铺名称],s.[信用]
FROM [商品信息] p
LEFT JOIN [天文区域] r ON p.[产地] = r.[天文区域编码]
LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]
WHERE ... ORDER BY ... LIMIT ...

但垂直分库后 [商品信息] 和[店铺信息]不在一个数据库中，甚至不在一台服务器，无奈进行关联查问。可将原关联查问分为两次查问，第一次查问的后果集中找出关联数据 id, 而后依据 id 发动第二次申请失去关联数据，最初将取得到的数据进行拼接。

1.3.3. 跨节点分页、排序函数

​ 跨节点多库进行查问时，limit 分页、order by 排序等问题，就变得比较复杂了。须要当初不同的分片节点中将数据进行排序并返回，而后将返回的后果集进行汇总和再次排序。

​ 如，进行程度分库后的商品库，按 ID 倒序排序分页，取第一页：

​

​ 以上流程是取第一页的数据，性能影响不大，然而因为商品信息的散布在各数据库的数据可能是随机的，如果是取第 N 页数据都取出来合并，再进行整体的排序，操作效率可想而知。所以申请页数越大，零碎的性能也会越差。

​ 在应用 Max、Min、Sum、Count 之类的函数进行计算的时候，与排序分页同理，也须要先在每个分片上执行相应的函数，而后将各个分片的后果集进行汇总和再次计算，最终将后果返回。

1.3.4. 主键避重

​ 在分库分表环境中，因为表中数据同时存在不同的数据库中，主键值平时应用的自增长将无用武之地，某个分区数据库生成的 ID 无奈保障全局惟一。因而须要独自设计全局主键，以防止跨库主键反复问题。

1.3.5. 公共表

​ 理论的利用场景中，参数表，数据字典等都是数据量较小，变动少，而且属于高频联结查问的依赖表。列子中 天文区域表 也属于此类型。

​ 能够将分库分表后之后，数据被扩散在不同的数据库，服务器。因而，对数据的操作也就无奈通过惯例形式实现，并且它还带来了一系列问题。好在，这些问题不是所有都须要咱们在利用层面上解决，市面上有很多中间件可供咱们抉择，其中 Sharding-JDBC 应用风行度较高，咱们来理解一下它。

1.4 Sharding-JDBC 介绍

1.4.1.Sharding-JDBC 介绍

​ Sharding-JDBC是当当网研发的开源分布式数据库中间件，从 3.0 开始 Sharding-JDBC 被蕴含 Sharding-Sphere 中，之后该我的项目进入 了 Apache 孵化器，4.0 版本之后的版本为 Apache 版本。

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

官网地址：https://shardingsphere.apache…

​ Sharding-JDBC，它定位轻量级 Java 框架，在 Java 的 JDBC 层提供额定服务。它应用客户端间接连贯数据库，以 jar 包模式提供服务，无需额定部署和依赖，可了解为增强版的 JDBC 驱动，齐全兼容 JDBC 和各种 ORM 框架。

​ Sharding-JDBC 的外围性能 数据分片 和读写拆散 ，通过 Sharding-JDBC，利用能够 通明 的应用 jdbc 拜访曾经分库分表、读写拆散的多个数据源，而不必关怀数据源的数量以及数据如何散布。

实用于任何基于 java 的 ORM 框架，如：Hibernate，Mybatis,SpringJDBC Template 或者间接应用 JDBC。

基于任何第三方的数据库连接池，如：DBCP，C3P0,BoneCP,Druid,HikariCP 等。

反对任意实现 JDBC 标准的数据库。目前反对 MYSQL，Oracle，SQLServer 和 PostgreSQL。

​ 上图展现了 Sharding-jdbc 的工作形式，应用 Sharding-jdbc 前须要人工对数据库进行分库分表，在应用程序中退出 Sharding-jdbc 的 jar 包，应用程序通过 Sharding-jdbc 操作分库分表后的数据库和数据表，因为 Sharding-jdbc 是对 jdbc 驱动的加强，应用 Sharding-jdbc 就像应用 jdbc 驱动一样，在应用程序中事无需指定具体要操作的分库和分表的。

1.4.2. 与 jdbc 性能比照

1. 性能损耗测试：服务器资源短缺、并发数雷同，比拟 JDBC 和 Sharding-jdbc 性能损耗，Sharding-jdbc 绝对 JDBC 损耗不超过 7%。

基准测试性能比

2. 性能比照测试: 服务器资源应用到极限，雷同的场景 JDBC 与 Sharding-JDBC 的吞吐量相当。

3. 性能测比照: 服务器资源应用到极限，Sharding-JDBC 采纳分库分表后，Sharding-JDBC 吞吐量较 JDBC 不分库分表有靠近 2 倍的晋升。

JDBC 单库两库表与 Sharding-JDBC 两库各两表比照

JDBC 单库单表与 Sharding-JDBC 两库各一表比照

2.Sharding-JDBC 疾速入门

2.1 需要阐明

本章节应用 Sharding-JDBC 实现对订单表的程度分表，通过疾速入门程序开发，疾速体验 Sharding-JDBC 的应用办法。

人工创立两张表，t_order_1 和 t_order_2，这两张表事订单表拆分后的表，通过 Sharding-JDBC 向订单表插入数据，依照肯定的分片规定，主键为偶数的进入 t_order_1，另一部分数据进入 t_order_2，通过 Sharding-JDBC 查问数据，依据 SQL 语句的内容从 t_order_1 或 t_order_2 查问数据。

2.2 环境配置

2.2.1. 环境阐明

• 操作系统: win10
• 数据库：MySQL-8.0.27
• JDK：64 位 jdk1.8
• 利用框架：spring-boot-2.3.5.RELEASE mybatis-plus-3.5.1
• Sharding-JDBC: Sharding-jdbc-spring-boot-start-4.1.1

2.2.2. 创立数库

创立订单 order_db

CREATE DATABASE order_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci

在 order_db 中创立 t_order_1 和 t_order_2 表

DROP TABLE IF EXISTS 't_order_1'
CREATE TABLE `t_order_1` (
  `order_id` bigint NOT NULL COMMENT '订单 id',
  `price` decimal(10,2) NOT NULL COMMENT '订单价格',
  `user_id` bigint NOT NULL COMMENT '下单用用户 id',
  `status` varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT '订单状态',
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

DROP TABLE IF EXISTS 't_order_2'
CREATE TABLE `t_order_2` (
  `order_id` bigint NOT NULL COMMENT '订单 id',
  `price` decimal(10,2) NOT NULL COMMENT '订单价格',
  `user_id` bigint NOT NULL COMMENT '下单用用户 id',
  `status` varchar(50) COLLATE utf8mb4_general_ci NOT NULL COMMENT '订单状态',
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

2.2.3. 引入依赖

引入 Sharding-jdbc 和 SpringBoot 整合的 jar 包：

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>4.1.1</version>
</dependency>

2.3 编写程序

2.3.1. 分片规定配置

具体 springboot 相干依赖及配置参考资料中 dbsharding/sharding-jdbc-simple 工程，本指引只阐明与 sharding-jdbc 相干的内容。

# 配置数据源
spring:
 shardingsphere:
   datasource:
     names: m1  #数据库
     m1:  
       type: com.alibaba.druid.pool.DruidDataSource
       driver-class-name: com.mysql.cj.jdbc.Driver
       username: root
       data-password: 123456
       url: jdbc:mysql://127.0.0.1:3306/order_db?useUnicode=true&characterEncoding=utf-8&useSSL=false&allowPublicKeyRetrieval=true
       
#指定 t_order 表的数据分布状况，配置数据节点
sharding:
     tables:
       t.order:   #逻辑表名
         key-generator:
           column: order_id  #主键
           type: SNOWFLAKE  #主键策略 雪花算法
         actual-data-nodes: m1.t_order_$->(1..2)  #表散布状况
         table-strategy: # 分表策略
           inline:
             sharding-column: order_id   # 分片路由规范
             algorithm-expression: t_order_$->{order_id % 2 +1} # 分片算法表达式



props:
     sql:
       show: true  #打印 sql

1. 首先定义数据源 m1，并对 m1 进行理论的参数配置。
2. 指定 t_order 表的数据分布状况，他散布在 m1.t_order_1 和 m1.t_order_2
3. 指定指定 t_order 表的主键生成策略为 SNOWFLAKE，SNOWFLAKE 是一种分布式自增算法，保障 id 全局惟一。
4. 定义 t_order 分表策略，order_id 为偶数的数据落在 t_order_1, 为基数落在 t_order_2, 分表策略的表达式为 t_order_$->{order_id % 2 +1}

2.3.2. 数据操作

    @Resource
    private IOrderMapper orderMapper;
    @Override
    public int addOrder(Order order) {return orderMapper.insert(order);
    }

2.4 流程剖析

通过日志剖析，Sharding-JDBC 在拿到用户要执行的 sql 之后干了哪些事儿;

(1)解析 sql，获取片键值，在本例中是 order_id

(2)Sharding-JDBC 通过规定配置 t_order_$->{order_id % 2 +1}，晓得了当 order_id 为偶数时，应该往 t_order_1 插入数据，为奇数时，往 t_order_2 插入数据。

(3)于是 Sharding-JDBC 依据 order_id 的值改写成 sql 语句，改写后的 sql 语句是实在所要执行的 sql 语句。

(4)执行改写后的实在 sql 语句

(5)将所有真正执行 sql 的后果进行汇总并返回。

3.Sharding-JDBC 执行原理

3.1 基本概念

在理解 Sharding-JDBC 的执行原理前，须要理解以下概念:

逻辑表

程度拆分的数据表的总数。例: 订单数据表主键尾数拆分为 10 张表，别离是 t_order_0、t_order_1 到 t_order_9，他们的逻辑表名为 t_order。

实在表

在分片的数据表中实在存在的物理表。即上个实例中的 t_order_0 到 t_order_9。

数据节点

数据分片的最小物理单元。由数据源名称和数据表组成，例:ds_0_order_0。

绑定表

指分片规定统一的主表和子表。例:t_order 表和 t_order_item 表, 均依照 order_id 分片，绑定表之间的分区键完全相同，则此两张表互为绑定关系。绑定表之间的多表关联查问不会呈现笛卡尔积关联，关联表效率将大大晋升。举例说明，如果 SQL 为：

SELECT i.* FROM t_order o JOIN t_order_item i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11);

在不配置绑定表关系时，假如分片键 order_id 将数值 10 路由至第 0 片，将数值 11 路由值第 1 片，那么路由后的 SQL 应该为 4 条，他们出现为笛卡尔积:

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11); 

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11);

在配置绑定表关系后，路由的 SQL 应该为 2 条

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i  ON o.order_id = i.order_id  WHERE o.order_id IN(10,11); 

播送表

指所有的分片数据源中都存在的表，表构造和表中的数据在每个数据库中均完全一致。实用于数据量不大且须要与海量数据的表进行关联查问的场景，例如: 字典表。

分片键

用于分片的数据库字段，是将数据库 (表) 程度拆分的关键字段。例: 将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。SQL 如果无分片字段，将执行全路由，性能较差。除了对订单分片字段的反对，Sharding-JDBC 也反对依据多个字段进行分片。

分片算法

通过分片算法数据分片，反对通过 =、BETEEN 和IN分片。分片算法须要利用方开发者自行实现，可实现的灵便度十分高。包含准确分片算法、范畴分片算法、复合分片算法，例如:where order_id =? 将采纳准确分片算法，where order_id in(?,?,?)将采纳准确分片算法，where order_id BETEEN ? and ? 将采纳范畴分片算法，复合算法用于分片键多简单状况。

分片策略

蕴含分片键和分片算法，因为分片算法的独立性，将其独立抽离。真正可用于分片操作的是分键 + 分片算法，也就是分片策略。内置的分片策略大抵可分为尾数取模。哈希、范畴、标签、工夫等。由用户方配置的分片策略规定更加灵便，罕用的应用行表达式配置分片策略，它采纳 Groovy 表达式示意，如: t_user_$->(u-id % 8)示意 t_user 表依据 u_id 模 8，而分成 8 张表，表名称为 t_user_0 到 t_user_7.

自增主键生成策略

通过在客户端生成自增主键替换以数据库原生自增主键的形式，做到分布式主键无反复。

3.2 SQL 解析

​ 当 Sharing-JDBC 承受到一条 SQL 语句时，会陆续执行 SQL 解析 => 查问优化 =>SQL 路由 =>SQL 改写 =>SQL 执行 => 后果归并，最终返回执行后果。

​ SQL 解析过程分为 语法解析 和语法分析。词法解析器用于将 SQL 拆解为不可再分的原子符号，称为 Token。并依据不同数据库方言所提供数据字典，将其归类为关键字，表达式，字面量和操作符。再应用语法解析器将 SQL 转为形象语法树。

例如, 以下 SQL:

SELECT id,name FROM t_user WHERE status = 'ACTIVE' AND age > 18

解析之后的为形象语法树见下图:

3.3 SQL 路由

​ SQL 路由就是针对 逻辑表 的数据操作到对数据节点操作的过程。

​ 依据解析上下文匹配数据库和表的分片策略，并生成路由门路。对于携带分片键的 SQL，依据分片键操作符不同能够划分为单片路由 (分片键的操作符是等号)、多片路由(分片的操作符是 IN) 和范畴路由(分片键的操作符是 BETWEEN)，不携带分片键的 SQL 则采纳播送路由。依据分片键进行路由场景可分为间接路由、规范路由、笛卡尔路由等。

规范路由

规范路由是 Sharding-JDBC 最为举荐应用的分片形式，它的适用范围是不蕴含关联查问或仅

当分片运算符是等于号时，路由后果将落入单库 (表)，当分片运算符是 BETWEEN 或 IN 时，则路由后果不肯定落在惟一的库(表)，因而一条逻辑 SQL 最终可能拆分为多条用于执行的实在 SQL。举例说明，如果依照order_id 的奇数和偶数进行数据分片，一个单表查问的 SQL 如下:

SELECT * FROM t_order WHERE order_id IN(1,2);

那么路由的后果为:

SELECT * FROM t_order_0 WHERE order_id IN(1,2);
SELECT * FROM t_order_1 WHERE order_id IN(1,2);

绑定表的关联查问与单表查问复杂度和性能相当。举例说明，如果一个蕴含绑定表的关联查问的 SQL 如下:

SELECT * FROM t_order o JOIN t_order_item i  ON o.order_id = i.order_id  WHERE order_id IN(1,2); 

能够看到，SQL 拆分的数目与单表是统一的。

笛卡尔路由

笛卡尔路由是最简单的状况，它无奈依据 绑定表 的关系定位分片规定，因而非绑定表之间的关联查问所须要拆解为笛卡尔积组合执行。如果上个实例中的 SQL 并为配置绑定表关系，那么路由的后果应为:

SELECT * FROM t_order_0 o JOIN t_order_item_0 i  ON o.order_id = i.order_id  WHERE order_id IN(1,2); 

SELECT * FROM t_order_0 o JOIN t_order_item_1 i  ON o.order_id = i.order_id  WHERE order_id IN(1,2); 

SELECT * FROM t_order_1 o JOIN t_order_item_0 i  ON o.order_id = i.order_id  WHERE order_id IN(1,2); 

SELECT * FROM t_order_1 o JOIN t_order_item_1 i  ON o.order_id = i.order_id  WHERE order_id IN(1,2); 

笛卡尔路由查问性能较低，需谨慎应用。

全库表路由

对于不携带分片键的 SQL，则采取播送路由的形式。依据 SQL 类型又能够划分为全库表路由。全库表路由、全库路由、全实例路由、单播路由和阻断路由这 5 种类型。其中全库表路由用于解决对数据库中与逻辑表相干的所有实在表的操作，次要包含不带分片的 DQL(数据查问)和 DML(数据操纵)，以及 DDL(数据定义)等。例如:

SELECT * FROM t_order WHERE good_prority IN(1,10);

则会遍历所有数据库中的所有表，逐个匹配逻辑表和实在表名，可能匹配得上则执行。路由后成为

SELECT * FROM t_order_0 WHERE good_prority IN(1,10);
SELECT * FROM t_order_1 WHERE good_prority IN(1,10);
SELECT * FROM t_order_2 WHERE good_prority IN(1,10);
SELECT * FROM t_order_3 WHERE good_prority IN(1,10);

3.4 SQL 改写

​ Sharding-JDBC 采纳一套自动化的执行引擎，负责将路由和改写实现之后的实在 SQL 平安且高效发送到底层数据源执行。它不是简略地将 SQL 通过 JDBC 间接发送到数据源执行；也并非间接将执行申请放入线程池去并发执行。它更关注均衡数据源连贯创立以及内存占用所产生的耗费，以及最大限度地正当利并发等问题。执行引擎的指标是自动化的均衡资源管制与执行效率，他能在以下两种模式自适应切换：

内存限度模式

​ 应用此模式的前提是，Sharding-JDBC 对一次操作所耗费的数据库连贯数量不做限度。如果理论执行的 SQL 须要对某数据库实例中的 200 张表做操作，则对每张表创立一个新的数据库连贯，并通过多线程的形式并发解决，以达成执行效率最大化。

连贯限度模式

​ 应用此模式的前提是，Sharding-jdbc 严格控制一次操作所消耗的数据库连贯数量。如果理论执行的 SQL 须要对某数据库实例中的 200 张表做操作，那么只会创立惟一的数据库连贯，并对其 200 张表串行解决。如果一次操作中的分片散落在不同的数据库，依然采纳多线程解决不同库的操作，但每个库的每次操作依然只创立一个惟一的数据库连贯。

​ 内存限度模式实用于 OLAP 操作，能够通过放宽对数据连贯的限度晋升零碎吞吐量；连贯限度模式实用于 OLTP 操作，OLTP 通常带有分片键，会路由到繁多的分片，因而严格控制数据库连贯，以保障在线零碎数据库资源可能被更多的利用所应用，是理智的抉择。

3.6 后果归并

​ 将从各个数据节点获取多个数据后果集，组合成为一个后果集并正确的返回至申请客户端，称为后果归并。

​ Sharding-JDBC 反对的后果归并从性能上能够 遍。历 、 排序 、 分组 、 分页 和聚合 5 种类型，她们是组合而非互斥的关系。

​ 归并引擎的整体构造划分如下图。

​

​ 后果归并从构造划分可分为 流式归并 和装璜归并。流式归并和内存归并是互斥的，装璜者归并并能够在流式归并和内存归并之上做进一步的解决。

​ 内存归并 很容易了解，他是将所有的分片后果集的数据都遍历并存储在内存中，再通过对立的分组，排序以及聚合等计算之后，再将其封装成为逐条拜访的数据后果集返回。

​ 流式归并是指每一次从数据库后果集中获取到的数据，都可能通过游标逐条的形式返回的正确的单条数据，它与数据库原生的返回后果集的形式最为符合。

​ 下边举例说明排序归并的过程，如下图是一个通过分数进行排序的示例图，它采纳流式归并形式。图中展现了 3 张表返回的数据后果集，每个数据集曾经依据分数排序结束，但 3 个数据后果集之间是无序的。将 3 个数据集的以后游标指向的数据值进行排序，并放入优先级队列,t_score_0 的第一个数据值最大，t_score_1 的形式排列队列。

下图则展示了进行 next 调用的时候，排序归并是如何进行的。通过图中咱们能够看到，当进行第一次 next 调用时，排在队列首位的 t_score_0 将会被弹出队列，并且将以后的游标指向的数据值 (也就是 1000) 返回值查问用户端，并且将游标下移一位之后，从新放入优先级队列。而优先级队列也会依据 t_score_0 的以后数据后果集指向游标数值(这里是 90) 进行排序，依据以后的数值，t_score_0 排列的最初一位。之前队列中排名第二的 t_score_1 的数据后果集则主动排在了队列首位。

在进行第二次 next 时，只须要将目前排列在队列首位的 t_score_1 弹出队列，并且将其数据后果集游标指向的值返回客户端，并下移游标，持续退出队列排队，以此类推。当一个后果集中曾经没有数据了，则无需再次退出队列。

能够看到，对于每个数据后果集中的数据有序，而多数据后果集整体无序的状况下，Sharing-JDBC 无需将所有的数据都加载至内存即可排序。它应用的是流式归并的形式，每次 next 仅获取惟一正确的一条数据，极大的节俭了内存的耗费。

装璜者归并 是对所有的后果集归并进行对立的性能加强，比方归并工夫须要聚合 SUM 前，在进行聚合计算前，都会通过内存归并或流式归并查问后果集。因而，聚合归并是在之前介绍的归并类型之上追加的归并能力，即装璜者模式。

3.7 总结

通过以上内容介绍，咱们曾经理解到 Sharding-JDBC 根底概念、外围性能以及执行原理。

根底概念: 逻辑表、实在表、数据节点、绑定表、播送表、分片键、分片算法、分片策略、主键生成策略

外围性能: 数据分片、读写拆散

执行流程:SQL 解析 => 查问优化 => SQL 路由 => SQL 改写 => SQL 执行 => 后果归并

4. 程度分表

​ 后面曾经介绍过，程度分表 是在同一个数据库内，把同一个数据依照肯定规定拆到多个表中，在 疾速上手 里，咱们曾经对程度分表进行实现，这里不再反复介绍。

5. 程度分库

​ 后面曾经介绍过，程度分库 是把同一个表的数据依照肯定的规定拆到不同的数据库中，每个库能够放在不同的服务器上。接下来看一下如何应用 Sharding-JDBC 实现程度分库，咱们持续对疾速入门中的例子进行欠缺。

(1)将原有的 order_db 库拆分为 order_db_1 和 order_db_2

(2)分片规定批改

因为数据库拆分两个，这里须要配置两个数据源。

分库须要配置分库的策略，和分表策略相似，通过分库策略实现数据操作针对分库的数据库进行操作。

# 定义多数据源
spring:
  shardingsphere:
    datasource:
      names: m1,m2 #数据库
      m1:  
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        username: root
        data-password: 123456
        url: jdbc:mysql://127.0.0.1:3306/order_db_1?useUnicode=true&characterEncoding=utf-8&useSSL=false&allowPublicKeyRetrieval=true
      m2:  
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.cj.jdbc.Driver
        username: root
        data-password: 123456
        url: jdbc:mysql://127.0.0.1:3306/order_db_2?useUnicode=true&characterEncoding=utf-8&useSSL=false&allowPublicKeyRetrieval=true    
        
#分库策略, 以 user_id 为分片键，分片策略为 user_id % 2 +1,user_id 为偶数操作 m1 数据源, 否则操作 m2。sharding:
      tables:
        t.order:   #逻辑表名
          table-strategy: # 分表策略
            inline:
              sharding-column: user_id   # 分片路由规范
              algorithm-expression: m$->{user_id % 2 +1} # 分片算法表达式
            key-generator: # 主键⽣成策略
              type: SNOWFLAKE
              column: order_id

        

分库策略定义形式如下:

 #分片策略，如何将一个逻辑表映射到多个数据源
 sharding:
      tables:
        < 逻辑表名 >:   
          database-strategy: 
            < 分片策略 >:
              < 分片策略属性名 >: 分片策略属性值

6. 垂直分库

​ 后面介绍过，垂直分库是指依照业务将表进行分类，散布到不同的数据库下面，每个库能够放在不同的服务器上，它的核心理念是专库专用。下来看一下如何应用 sharding-JDBC 实现垂直分库。

(1)创立数据库

创立数据库 user_db

CREATE DATABASE user_db CHARACTER SET utf8 COLLATE utf8_general_ci;

在 user_db 中创立 t_user 表

DROP TABLE IF EXITSTS t_user;
CREATE TABLE t_user (user_id bigint(20) NOT NULL COMMENT '用户 id',
    fullname varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '用户姓名',
    user_type char(1) DEFAULT NULL COMMENT '用户类型',
    PRIMARY KEY ('user_id') USING BTREE
)ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

(2) 在 sharding-JDBC 规定中批改

shardingsphere:
  datasource:
    names: m1,m2                                      # 数据源，这里为了不便间接应用库名的名称
    m1:
      username: root
      password: 123456
      url: jdbc:mysql://localhost:3306/user_db_1?setUnicode=true&characterEncoding=utf8
      driver-class-name: com.mysql.cj.jdbc.Driver
      type: com.alibaba.druid.pool.DruidDataSource   # Druid 连接池
    m2:
      username: root
      password: 123456
      url: jdbc:mysql://localhost:3307/user_db_2?setUnicode=true&characterEncoding=utf8
      driver-class-name: com.mysql.cj.jdbc.Driver
      type: com.alibaba.druid.pool.DruidDataSource   # Druid 连接池

  sharding:
      tables:
        t_user:   
          actual-data-nodes: m$->{1..2}.t_user_$->{1..2}        # 表的名字
          database-strategy:                                # 分库策略
            inline:
              sharding-column: user_id
              algorithm-expression: m$->{user_id % 2 +1}
           table-strategy:                                # 分库策略
            inline:
              sharding-column: user_id
              algorithm-expression: t_user_$->{user_id % 2 +1} #分表策略

7. 公共表

​ 公共表属于零碎中数据量较小, 变动少，而且属于频繁联结查问的依赖表。参数表、数据字典表等属于此类型。能够将这类型表每个数据库都保留一份，所有更新操作都同时发送到所有分库执行。接下来一下如何应用 Sharding-JDBC 实现公共类。

(1) 创立数据库

别离在 user_db、order_db_1、order_db2 中创立 t_dict 表:

DROP TABLE IF EXITSTS t_dict;
CREATE TABLE t_user (dict_id bigint(20) NOT NULL COMMENT '字典 id',
    type varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典类型',
    code varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典编码',
    value varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '字典值',
    PRIMARY KEY ('dict_id') USING BTREE
)ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;

(2) 在 sharding-JDBC 规定中批改

# 指定 t_dict 为公共表
    sharding:
      broadcast-tables: t_dict #公共表 播送表

8. 读写拆散

8.1 了解读写拆散

​ 面对日益的零碎访问量，数据库的吞吐量面临微小瓶颈。对于同一时刻有大量并发读操作和较少写操作类型的利用零碎来说，将数据库拆分为主库和从库，主库负责处理事务性质的增删改操作，从库负责解决查问操作，可能无效的防止由数据库更新导致的行锁，使得整个零碎的查问性能失去极大的改善。

​ 通过一主多从的配置形式，能够将查问申请平均的扩散到都多个数据正本，可能进一步的晋升零碎的解决能力。应用多主多从的形式，岂但可能晋升零碎的吞吐量，还可能晋升零碎的可用性，能够达到在任何一个数据库宕机，甚至磁盘物理损坏的状况下依然不影响零碎的失常运行。

​ 读写拆散的数据节点的数据内容是统一的，而程度分片的每个数据节点的 数据内容却并不相同。将程度分片和读写拆散联结应用，可能更加无效的晋升零碎的性能。

<! – – 主从同步的 N 种实现形式？主从同步其实与读写分离式两码事 – ->

​ ShardingJDBC 读写拆散则是依据 SQL 语义的剖析，将读操作和写操作别离路由至主库与从库。它提供透明化读写拆散，让应用办法尽量像应用一个数据库一样应用主从数据库集群。

Sharding-JDBC 提供 一主多从 的读写拆散配置，可独立应用，也可配合分库分表应用，同一线程且同一数据库连贯内，如有写入操作，当前的读操作均从主库读取，用于保证数据一致性。Sharding-JDBC 不提供主从数据库的数据同步性能，须要采纳其余机制反对。

​ 接下来须要，对下面例子中 user_db 进行读写拆散实现。为了实现 Sharding-JDBC 的读写拆散，首先，要进行 mysql 的主从同步配置。

8.2 mysql 主从同步(windows)

主库：

[mysqld]
#开启日志
log-bin= mydql-bin
#设置服务 id, 主从不能统一
server-id= 1
#设置须要同步的数据库
binlog-do-db= user_db
#屏蔽零碎同步
binlog-ignore-db= mysql
binlog-ignore-db= information_schema
binlog-ignore-db= performance_schema

从库：

[mysqld]
#开启日志
log-bin= mydql-bin
#设置服务 id, 主从不能统一
server-id= 2
#设置须要同步的数据库
binlog-do-db= user_db.%
#屏蔽零碎同步
binlog-ignore-db= mysql.%
binlog-ignore-db= information_schema.%
binlog-ignore-db= performance_schema.%

重启主库和从库

net start [主服务器名]
net start [从服务器名 mysqls1]

请留神，主从 Mysql 下的数据 (data) 目录下有个 auto.cnf, 文件中定义了 uuid，要保障主从数据库实例的 uuid 不一样，倡议间接删掉，重启服务后将从新生成。

三、受权主从复制专用账号

# 登录主库
mysql -h localhost -uroot -p123456
#受权主备复制专用账号
GARNT REPLICATION ON *.* TO 'db_sync'@'%' IDENTIFIED BY 'db_sync';
#刷新权限
FLUSH PRIVILEGES;
#确认位点，记录下文件名以及位点
show master status;

四、设置从库向主库同步数据、并查看链路

# 登录从库
mysql -h localhost -uroot -p123456
#先进行同步
STOP SLAVE;
#批改从库指向主库，应用上一步记录的文件名以及位点
CHANGE MASTER TO
 master_host = 'localhsot',
 master_user = 'db_sync',
 master_password = 'db_sync',
 master_log_file = 'mysql-bin.000002',
  master_log_pos = '154';
#启动同步
START SLAVE;
#查看从库状态 Slave_IO_Runing 和 Slave_SQL_Runing 都为 Yes 阐明同步胜利，如果不为 Yes, 请查看 error_log, 而后排查相干异样。show slave status\G

#留神 如果之前此备库已有主库指向 须要先执行以下命令清空
STOP SLAVE TO_THREAD FOR CHANNEL '';
reset slave all;

8.3 实现 sharding-JDBC 读写拆散

(1) 在 Sharding-JDBC 规定中批改

# 配置主从数据库
shardingsphere:
    datasource:
      names: m1,s1        # 主库:m1, 从库:s1
      m1:
        username: root
        password: 123456
        url: jdbc:mysql://localhost:3306/user_db?setUnicode=true&characterEncoding=utf8
        driver-class-name: com.mysql.cj.jdbc.Driver
        type: com.alibaba.druid.pool.DruidDataSource   # Druid 连接池
      s1:
        username: root
        password: 123456
        url: jdbc:mysql://localhost:3306/user_db?setUnicode=true&characterEncoding=utf8
        driver-class-name: com.mysql.cj.jdbc.Driver
        type: com.alibaba.druid.pool.DruidDataSource   # Druid 连接池
        
    sharding:
      master-slave-rules:
        ds0:  # 主从逻辑数据源 定义 ds0 为 uesr_db
          master-data-source-name: m1
          slave-data-source-name: s1
                      
      tables:  #分表策略，固定调配到 ds0 的实在表
        t_user:   
          actual-data-nodes: ds0.t_user        # 表的名字