sharding-jdbc系列（一）：概念

前话

前段时间公司项目比较忙，天天都忙于码代码，最近好不容易项目上线了，后期就是试运行解决线上问题，要闲一些了，看了下公司以前的一些项目，发现其中居然有用到sharding-jdbc，想到以前自己也使用过，但是仅仅是会用过，对一些原理还不了解，所以决定趁这段时间学习一下。

核心概念

一、 背景

在互联网海量数据时代的今天，我们需要存储的数据也越来越多，在使用关系型数据库例如mysql等时，单表所需要存储的数据也越来越多，但是关系型数据库在单表数据库量较大的情况下，单表性能会急剧下降，面对这个问题，常见的做法就是进行分表，但是单纯的分表只能减少单表的压力，不能减轻数据库的压力，所以在分表的同时往往也会进行分库操作。

二、分库分表

分库分表主要是为了解决互联网应用的大数据量存储问题，分表通常分为：垂直划分、水平划分；垂直划分通常是根据业务场景将一个多字段大表拆分成多个多个少字段小表，水平划分是根据某个分片策略将同一个表的数据分开存到多个相同结构表中。

三、sharding-jdbc核心概念

1、ShardingSphere简介

sharding-jdbc是ShardingSphere的其中一个模块，摘抄官网一段简介:

（官方中文文档：https://shardingsphere.apache.org/document/current/cn/overview/）

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

ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术探索的前沿，放眼未来，拥抱变化，是非常值得推荐的。反之，也可以用另一种思路看待问题，放眼未来，关注不变的东西，进而抓住事物本质。 关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆。

2、sharding-jdbc简介

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

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

功能列表：

数据分片

• 分库 & 分表
• 读写分离
• 分片策略定制化
• 无中心化分布式主键

分布式事务

• 标准化事务接口
• XA强一致事务
• 柔性事务

数据库治理

• 配置动态化
• 编排 & 治理
• 数据脱敏
• 可视化链路追踪
• 弹性伸缩(规划中)

3、sharding-jdbc核心概念

• 逻辑表（LogicTable）：进行水平拆分的时候同一类型（逻辑、数据结构相同）的表的总称。例：订单数据根据主键尾数拆分为10张表，分别是t_order_0到t_order_9，他们的逻辑表名为t_order。
• 真实表（ActualTable）：在分片的数据库中真实存在的物理表。即上个示例中的t_order_0到t_order_9。
• 数据节点（DataNode）：数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。
• 动态表（DynamicTable）：逻辑表和物理表不一定需要在配置规则中静态配置。如，按照日期分片的场景，物理表的名称随着时间的推移会产生变化。
• 绑定表（BindingTable）：指分片规则一致的主表和子表。例如：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);

其中t_order在FROM的最左侧，ShardingSphere将会以它作为整个绑定表的主表。 所有路由计算将会只使用主表的策略，那么t_order_item表的分片计算将会使用t_order的条件。故绑定表之间的分区键要完全相同。

• 分片键（ShardingColumn）：分片字段用于将数据库（表）水平拆分的字段，支持单字段及多字段分片。例如上例中的order_id。
• 分片算法（ShardingAlgorithm）：进行水平拆分时采用的算法，分片算法需要应用方开发者自行实现，可实现的灵活度非常高。目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

1、精确分片算法
对应PreciseShardingAlgorithm，必选，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。

2、范围分片算法
对应RangeShardingAlgorithm，可选，用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。如果不配置RangeShardingAlgorithm，SQL中的BETWEEN AND将按照全库路由处理。需要配合StandardShardingStrategy使用。

3、复合分片算法
对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。

4、Hint分片算法
对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。

 

• 分片策略（ShardingStrategy）：包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供5种分片策略。

1、标准分片策略
对应StandardShardingStrategy。提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的，用于处理=和IN的分片。RangeShardingAlgorithm是可选的，用于处理BETWEEN AND分片，如果不配置RangeShardingAlgorithm，SQL中的BETWEEN AND将按照全库路由处理。

2、复合分片策略
对应ComplexShardingStrategy。复合分片策略。提供对SQL语句中的=, IN和BETWEEN AND的分片操作支持。ComplexShardingStrategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。

3、行表达式分片策略
对应InlineShardingStrategy。使用Groovy的表达式，提供对SQL语句中的=和IN的分片操作支持，只支持单分片键。对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的Java代码开发，如: t_user_$->{u_id % 8} 表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。

4、Hint分片策略
对应HintShardingStrategy。通过Hint而非SQL解析的方式分片的策略。

5、不分片策略
对应NoneShardingStrategy。不分片的策略。

4、sharding-jdbc架构图：

 

由图可知，在sql执行过程中需要经过几个过程：

例如现在有一条查询语句：

select * from t_user where id=10；

进行了分库分表操作，2个库ds0，ds1，采用的分片键为id，逻辑表为t_user,真实表为t_user_0、t_user_1两张表，分库、分表算法为均为取余（%2）。

• sql解析：通过解析sql语句提取分片键列与值进行分片，例如比较符 =、in 、between and，及查询的表等。
• sql改写：根据解析结果，及采用的分片逻辑改写sql，上例经过sql改写后，真实语句为：

select * from t_user_0 where id=10；

• sql路由：找到sql需要去哪个库、哪个表执行语句，上例sql根据采用的策略可以得到将在ds0库，t_user_0表执行语句。
• sql执行：执行改写后的sql。
• 结果归并：当我们执行某些复杂语句时，sql可能会在多个库、多个表中执行，sql分别对应执行后会对结果集进行归并操作，得到最终的结果。