本文分享自华为云社区《看完这一篇，ShardingSphere-jdbc 实战再也不怕了》，作者：勇哥java实战分享 。

1 ShardingSphere 生态

Apache ShardingSphere 是一款分布式的数据库生态系统，它包含两大产品：

  • ShardingSphere-Proxy

  • ShardingSphere-JDBC

ShardingSphere-Proxy

ShardingSphere-Proxy 被定位为透明化的数据库代理端，供给封装了数据库二进制协议的服务端版别，用于完结对异构言语的支持。

理论+实战，详解Sharding Sphere-jdbc

代理层介于运用程序与数据库间，每次恳求都需求做一次转发，恳求会存在额定的时延。

这种方式关于运用十分友好，运用基本零改动，和言语无关，能够通过衔接共享削减衔接数消耗。

ShardingSphere-JDBC

ShardingSphere-JDBC 是 ShardingSphere 的第一个产品，也是 ShardingSphere 的前身， 咱们经常简称之为：sharding-jdbc 。

它定位为轻量级 Java 结构，在 Java 的 JDBC 层供给的额定服务。它运用客户端直连数据库，以 jar 包形式供给服务，无需额定布置和依靠，可理解为增强版的 JDBC 驱动，彻底兼容 JDBC 和各种 ORM 结构。

理论+实战，详解Sharding Sphere-jdbc

当咱们在 Proxy 和 JDBC 两种形式选择时，能够参阅下表对照：

理论+实战，详解Sharding Sphere-jdbc
越来越多的公司都在出产环境运用了 sharding-jdbc ，最中心的原因便是：简略（原理简略，易于完结，便利运维）。

2 基本原理

在后端开发中，JDBC 编程是最基本的操作。不管 ORM 结构是 Mybatis 还是 Hibernate ，亦或是 spring-jpa ，他们的底层完结是 JDBC 的模型。

理论+实战，详解Sharding Sphere-jdbc

sharding-jdbc 的实质上便是完结 JDBC 的中心接口。

理论+实战，详解Sharding Sphere-jdbc

理论+实战，详解Sharding Sphere-jdbc
虽然咱们理解了 sharding-jdbc 的实质，但是真实完结起来还有十分多的细节，下图展现了 Prxoy 和 JDBC 两种形式的中心流程。

理论+实战，详解Sharding Sphere-jdbc

SQL 解析

分为词法解析和语法解析。 先通过词法解析器将 SQL 拆分为一个个不行再分的单词。再运用语法解析器对 SQL 进行理解，并终究提炼出解析上下文。

解析上下文包含表、选择项、排序项、分组项、聚合函数、分页信息、查询条件以及或许需求修改的占位符的符号。

履行器优化

兼并和优化分片条件，如 OR 等。

SQL 路由

依据解析上下文匹配用户装备的分片战略，并生成路由途径。现在支持分片路由和播送路由。

SQL 改写

将 SQL 改写为在实在数据库中能够正确履行的语句。SQL 改写分为正确性改写和优化改写。

SQL 履行

通过多线程履行器异步履行。

成果归并

将多个履行成果集归并以便于通过共同的 JDBC 接口输出。成果归并包含流式归并、内存归并和运用装修者形式的追加归并这几种方式。

本文的重点在于实战层面， sharding-jdbc 的完结原理细节咱们会在后续的文章逐个给咱们呈现 。

3 实战事例

笔者曾经为武汉一家 O2O 公司订单服务做过分库分表架构规划 ，当企业用户创立一条采购订单 ， 会生成如下记载：

  • 订单根底表t_ent_order ：单条记载

  • 订单概况表t_ent_order_detail ：单条记载

  • 订单明细表t_ent_order_item：N 条记载

订单数据选用了如下的分库分表战略：

  • 订单根底表依照 ent_id (企业用户编号) 分库 ，订单概况表保持共同；

  • 订单明细表依照 ent_id (企业用户编号) 分库，一起也要依照 ent_id (企业编号) 分表。

首要创立 4 个库，分别是：ds_0、ds_1、ds_2、ds_3 。

这四个分库，每个分库都包含 订单根底表 ， 订单概况表 ，订单明细表 。但是因为明细表需求分表，所以包含多张表。

理论+实战，详解Sharding Sphere-jdbc

然后 springboot 项目中装备依靠 ：

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

装备文件中装备如下：

理论+实战，详解Sharding Sphere-jdbc

  • 装备数据源，上面装备数据源是： ds0、ds1、ds2、ds3 ；

  • 装备打印日志，也便是：sql.show ，在测验环境建议翻开 ，便于调试；

  • 装备哪些表需求分库分表 ，在 shardingsphere.datasource.sharding.tables 节点下面装备：

理论+实战，详解Sharding Sphere-jdbc

上图中咱们看到装备分片规矩包含如下两点：

实在节点

关于咱们的运用来讲，咱们查询的逻辑表是：t_ent_order_item 。

它们在数据库中的实在形态是：t_ent_order_item_0 到 t_ent_order_item_7。

实在数据节点是指数据分片的最小单元，由数据源名称和数据表组成。

订单明细表的实在节点是：ds$->{0..3}.t_ent_order_item_$->{0..7} 。

分库分表算法

装备分库战略和分表战略 , 每种战略都需求装备分片字段（ sharding-columns ）和分片算法。

4 基因法 & 自定义复合分片算法

分片算法和阿里开源的数据库中间件 cobar 路由算法十分类似的。

假设现在需求将订单表均匀拆分到4个分库 shard0 ，shard1 ，shard2 ，shard3 。

首要将 [0-1023] 均匀分为4个区段：[0-255]，[256-511]，[512-767]，[768-1023]，然后对字符串（或子串，由用户自定义）做 hash， hash 成果对 1024 取模，终究得出的成果 slot 落入哪个区段，便路由到哪个分库。

理论+实战，详解Sharding Sphere-jdbc

看起来分片算法很简略，但咱们需求依照订单 ID 查询订单信息时仍然需求路由四个分片，效率不高，那么怎么优化呢 ？

答案是：基因法 & 自定义复合分片算法。

基因法是指在订单 ID 中带着企业用户编号信息，咱们能够在创立订单 order_id 时运用雪花算法，然后将 slot 的值保存在 10位作业机器 ID 里。

理论+实战，详解Sharding Sphere-jdbc

通过订单 order_id 能够反查出 slot , 就能够定位该用户的订单数据存储在哪个分片里。

 Integer getWorkerId(Long orderId) {
  Long workerId = (orderId >> 12) & 0x03ff;
  return workerId.intValue();
 }

下图展现了订单 ID 运用雪花算法的生成进程，生成的编号会带着企业用户 ID 信息。

理论+实战，详解Sharding Sphere-jdbc

解决了分布式 ID 问题，接下来的一个问题：sharding-jdbc 可否支持依照订单 ID ，企业用户 ID 两个字段来决议分片路由吗？

答案是：自定义复合分片算法。咱们只需求完结 ComplexKeysShardingAlgorithm 类即可。

理论+实战，详解Sharding Sphere-jdbc

复合分片的算法流程十分简略：

1.分片键中有主键值，则直接通过主键解析出路由分片；

2.分片键中不存在主键值 ，则依照其他分片字段值解析出路由分片。

5 扩容计划

既然做了分库分表，怎么完结滑润扩容也是一个十分有趣的话题。

在数据同步之前，需求整理搬迁规模。

1.事务仅有主键；

在进行数据同步前，需求先整理所有表的仅有事务 ID，只有确认了仅有事务 ID 才干完结数据的同步操作。

需求注意的是：事务中是否有运用数据库自增 ID 做为事务 ID 运用的，假如有需求事务先进行改造 。另外确保每个表是否都有仅有索引，一旦表中没有仅有索引，就会在数据同步进程中造成数据重复的风险，所以咱们先将没有仅有索引的表依据事务场景添加仅有索引（有或许是联合仅有索引）。

2.搬迁哪些表，搬迁后的分库分表规矩；

分表规矩不同决议着 rehash 和数据校验的不同。需逐个表整理是用户ID纬度分表还是非用户ID纬度分表、是否只分库不分表、是否不分库不分表等等。

接下来，进入数据同步环节。

全体计划见下图，数据同步基于 binlog ，独立的中间服务做同步，对事务代码无侵入。

理论+实战，详解Sharding Sphere-jdbc

首要需求做前史数据全量同步：也便是将旧库搬迁到新库。

单独一个服务，运用游标的方式从旧库分片 select 语句，通过 rehash 后批量刺进 （batch insert）到新库，需求装备jdbc 衔接串参数 rewriteBatchedStatements=true 才干使批处理操作收效。

因为前史数据也会存在不断的更新，假如先敞开前史数据全量同步，则刚同步完结的数据有或许不是最新的。

所以咱们会先敞开增量数据单向同步（从旧库到新库），此刻只是敞开积压 kafka 音讯并不会真实消费；然后在开端前史数据全量同步，当前史全量数据同步完结后，在敞开消费 kafka 音讯进行增量数据同步（进步全量同步效率削减积压也是关键的一环），这样来确保搬迁数据进程中的数据共同。

增量数据同步考虑到灰度切流稳定性、容灾 和可回滚才能 ，选用实时双向同步计划，切流进程中一旦新库呈现稳定性问题或者新库呈现数据共同问题，可快速回滚切回旧库，确保数据库的稳定和数据牢靠。

增量数据实时同步的大体思路 ：

1.过滤循环音讯

需求过滤掉循环同步的 binlog 音讯 ;

2.数据兼并

同一条记载的多条操作只保存终究一条。为了进步功能，数据同步组件接到 kafka 音讯后不会立刻进行数据流转，而是先存到本地阻塞队列，然后由本地守时任务每X秒将本地队列中的N条数据进行数据流转操作。此刻N条数据有或许是对同一张表同一条记载的操作，所以此处只需求保存终究一条（类似于 redis aof 重写）;

3.update 转 insert

数据兼并时，假如数据中有 insert + update 只保存终究一条 update ，会履行失败，所以此处需求将 update 转为 insert 语句 ;

4.按新表兼并

将终究要提交的 N 条数据，依照新表进行拆分兼并，这样能够直接依照新表纬度进行数据库批量操作，进步刺进效率。

扩容计划文字来自 《256变4096：分库分表扩容怎么完结滑润数据搬迁》，笔者做了些许调整。

6 总结

sharding-jdbc 的实质是完结 JDBC 的中心接口，架构相对简略。

实战进程中，需求装备数据源信息，逻辑表对应的实在节点和分库分表战略（分片字段和分片算法）

完结分布式主键直接路由到对应分片，则需求运用基因法 & 自定义复合分片算法 。

滑润扩容的中心是全量同步和实时双向同步，工程上有不少细节。

实战代码地址：

github.com/makemyownli…

理论+实战，详解Sharding Sphere-jdbc

参阅资料：

  • 256变4096：分库分表扩容怎么完结滑润数据搬迁？

  • 黄东旭：分布式数据库前史、发展趋势与 TiDB 架构

点击关注，第一时间了解华为云新鲜技能~