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为：

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

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

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

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

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

4、sharding-jdbc架构图：

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

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

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

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

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