乐趣区

关于java:ShardingJDBC入门

作者：

jiezi

在

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%。

基准测试性能比

业务场景 JDBC Sharding-JDBC1.5.2 Sharding-JDBC1.5.2/JDBC损耗
单库单表查问 493 470 4.7%
单库单表更新 6682 6303 5.7%
单库单表插入 6855 6375 7%
业务场景 业务平响应工夫(ms) 业务TPS
JDBC单库单表查问 7 493
Sharding-JDBC单库单表查问 8 470

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

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

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

业务场景 JDBC单库两表 Sharding-JDBC两库各两表 性能晋升至
查问 1736 3331 192%
更新 9170 17997 196%
插入 11574 23043 199%

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

业务场景 JDBC单库单表 Sharding-JDBC两库各一表 性能晋升至
查问 1586 2944 185%
更新 9548 18561 194%
插入 11182 21414 192%

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        # 表的名字

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章