一、ShardingSphere背景

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，由以下部分组成。

  1. Sharding-JDBC - 提供标准化的数据分片
  2. Sharding-Proxy - 分布式事务
  3. Sharding-Sidecar（计划中）- 数据库治理功能

可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

二、概念 & 功能

2.1 背景

传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。

在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的NoSQL的尝试越来越多。 但NoSQL对SQL的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。
分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。 除此之外，分库还能够用于有效的分散对数据库单点的访问量；分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。 使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。
数据分片的拆分方式又分为垂直分片和水平分片。

2.2 垂直分片

按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。

下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。
在这里插入图片描述
使用垂直切分方案的主要优点如下：

  1. 拆分后业务清晰，符合微服务的总体设计理念；
  2. 子系统之间的整合与扩展相对容易；
  3. 按照不同的业务类型，将不同的库表放在不同的数据库服务器上，便于管理；
  4. 根据业务数据的“冷”、“热”状态，采用不同的缓存和数据库模式设计方案；

垂直切分的缺点如下：

  1. 跨库的Join查询，需要使用不同子系统的API接口读取后在内存中完成关联查询，提高系统复杂度
  2. 如果某一种类型的业务呈现爆发式地增长，该业务对应的库表还是会存在单DB的IO读写的瓶颈问题，从这一点来说垂直切分并未从根本解决单库单表数据量过大的问题；
  3. 存在跨库事务的一致性问题，解决起来比较麻烦，当然也可以采用分布式事务来解决；

2.3 水平分片

水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 例如：根据主键分片，偶数主键的记录放入0库（或表），奇数主键的记录放入1库（或表），如下图所示。
在这里插入图片描述
使用水平切分方案的主要优点如下：

  1. 单库单表的数据容量可以维持在一个量级，有助于提高业务SQL的执行效率和系统性能；
  2. 不管是利用ShardingJdbc组件还是MyCat框架，业务系统的应用层涉及改造得都较少，只需要根据实际的业务情况来设计数据分片的路由规则即可；
  3. 可以提高业务系统的稳定性和负载能力；

使用水平切分方案的主要缺点如下：

  1. 数据水平切分后，分布在多库多表中，跨库Join查询比较复杂；
  2. 分片数据的一致性较为难保证；
  3. 对于历史数据的迁移和数据库的扩容需要较大的维护工作量；

三、Sharding-JDBC核心概念

3.1 基本概念

定位为轻量级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。

3.2 核心概念

逻辑表（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为：
广播表: 指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。
逻辑索引:某些数据库（如：PostgreSQL）不允许同一个库存在名称相同索引，某些数据库（如：MySQL）则允许只要同一个表中不存在名称相同的索引即可。 逻辑索引用于同一个库不允许出现相同索引名称的分表场景，需要将同库不同表的索引名称改写为索引名 + 表名，改写之前的索引名称成为逻辑索引。
分片键（ShardingColumn）：分片字段用于将数据库（表）水平拆分的字段，支持单字段及多字段分片。例如上例中的order_id。
分片算法（ShardingAlgorithm）：进行水平拆分时采用的算法，分片算法需要应用方开发者自行实现，可实现的灵活度非常高。目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

3.3 分片

3.3.1 分片算法

通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。

1.精确分片算法
对应PreciseShardingAlgorithm，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。
2.范围分片算法
对应RangeShardingAlgorithm，用于处理使用单一键作为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景。需要配合StandardShardingStrategy使用。
3.复合分片算法
对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。
4.Hint分片算法
对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。

3.3.2 分片策略

分片策略：可用于分片操作的是分片键 + 分片算法
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。不分片的策略。

3.3 核心架构

在这里插入图片描述
由图可知，在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分别对应执行后会对结果集进行归并操作，得到最终的结果。

 

转载于：https://blog.csdn.net/weixin_42338555/article/details/104782010?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-9.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-9.channel_param