shardingJdbc专题系列(一)之shardingJdbc简介

た入场券 2022-12-25 08:53 227阅读 0赞

分库分表的概念已经炒了很久了，我也很久没有写博客了，这段确实有点忙，前段时间恰好在公司分享了一下关于shardingJdbc的用法，索性整理成文章，希望能对大家有帮助。

分库分表这种概念，个人认为应该还是属于技术发展过程中的一种过渡方案，如果有一天mysql支持高性能水平扩展，或者出现了更为成熟的数据库产品，那么这种技术也就没有存在的必要了。

这一讲我们主要介绍 一些概念性的东西。

# 一。分库分表简介 #

### 1.1 为什么要使用分库分表 ###

**分表前提**： 当单表数据量太大，会极大的影响sql的执行性能，这时sql会跑的很慢。根据实战经验来说，当单表到几百万的时候，性能就会有所下降

**分库前提**：单库而言，最大的并发可能就2000左右，但是一个健壮的单库来说最好的并发保持在1000左右。单数据库增大或者并发增加的时候，可以将一个库的数据拆分到多个库中

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70][]

### 1.2 什么时候进行分库分表 ###

阿里巴巴手册如是说道。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 1][]

# 二。 ShardingSphere 简介 #

官网地址： [http://shardingsphere.apache.org/index\_zh.html][http_shardingsphere.apache.org_index_zh.html]

ShardingSphere 已于2020年4月16日成为 Apache 软件基金会的顶级项目。

Apache ShardingSphere \- 版本: 5.0.0-alpha ( 发布日期: Nov 10, 2020 )

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 2][]

### 功能列表： ###

数据分片

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

分布式事务

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

数据库治理

*  分布式治理
 *  弹性伸缩
 *  可视化链路追踪
 *  数据加密

### 2.2 水平拆分和垂直拆分 ###

垂直拆分： 也叫纵向拆分，指的是按照业务将库/表，进行分类，分出来的各个部分结构不同。

水平拆分： 将同一个库/表拆分成多个结构相同的库/表

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 3][]                                                             ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 4][]

### 2.3 核心概念 ###

*  逻辑表： 水平拆分的数据表的相同逻辑和数据结构表的总称。例如：订单表根据主键拆分为10张表，分别是t\_order\_0到 t\_order\_9, 那么他们的逻辑表名为t\_order
 *  真实表： 在分片的数据库中真实存在的物理表。即上个示例中的t\_order\_0到t\_order\_9
 *  数据节点：数据分片的最小单元。有数据源名称和数据表组成，例如：ds\_0.t\_order\_0
 *  绑定表：指分片规则一致的主表和字表。例如t\_order表和t\_order\_item表，均按照order\_id分片，则这两张表为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联效率将大大提升。

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);

*  广播表：指所有分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进相关联查询的场景，例如：字典表

### 2.4 四种分片算法 ###

*  精确分片算法 - PreciseShardingAlgorithm
    
    用于处理使用单一键做为分片键的 = 与 in 进行分片的场景。需要配合StandardShardingStrategy使用。
 *  范围分片算法 - RangeShardingAlgorithm
    
    用于处理使用单一键作为分片键的Between And 进行分片的场景。需要配合配合StandardShardingStrategy使用
 *  复合分片算法 - ComplexKeysShardingAlgorithm
    
    用于处理使用多键做为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用
    
    **注** ： 我们在业务开发中，经常有根据用户id 查询某用户的记录列表，又有根据某个业务主键查询该用户的某记录的需求，这就需要用到复合分片算法。比如，订单表中，我们既需要查询某个userId的某时间段内的订单列表数据，又需要根据orderId查询某条订单数据。这里，orderId与userId就属于复合分片键。
 *  Hint分片算法 - HintShardingAlgorithm
    
    Hint分片指的是对于分片字段非SQL决定，而是由其他外置条件决定的场景，可以通过使用SQL Hint 灵活注入分片字段。
    
    Hint分片策略是绕过SQL解析的，因此能够通过实现该算法来实现sharding-jdbc不支持的语法限制。用于处理使用Hint行分片的场景，需要配合HintShardingStrategy使用

### 2.5 五种分片策略 ###

*  标准分片策略 - StandardShardingStrategy
    
    提供对SQL语句中的 = ， in, between and的分片操作支持。StandardShardingStrategy只支持单分片键，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个算法。
    
    PreciseShardingAlgorithm是必选的，用于处理 = 和 in分片。PreciseShardingAlgorithm是可选的，用于处理 Between and分片，如果不配置RangeShardingAlgorithm，Sql中的between and将按照全库路由处理。
 *  复合分片策略 - ComplexShardingStrategy
    
    提供对SQL语句中的=，in, 和between and的分片操作支持。ComplexShardingStrategy支持多分片键，由于多分片键之间的关系复杂，因此并未进行过多封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度。
 *  行表达式分片策略 - InlineShardingStrategy
    
    使用groovy的表达式，提供对sql语句中的 = 和 in的分片操作支持，只支持单分片。使用简单的分片算法，可以通过简单的配置使用，从而避免繁琐的java代码开发，如 t\_user$->\{u\_id%8\}表示t\_user表根据u\_id模8，而分成8张表，表名为 t\_user\_0 到 t\_user\_7
 *  Hint分片策略 - HintShardingStrategy
    
    通过Hint而非SQL解析的方式进行分片的策略
 *  不分片策略 - NoneShardingStrategy
    
    该策略为不分片策略

关于一些概念性的东西我们就介绍到这，写一篇文章我们进行实战

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70]: /images/20221120/ef95d684672345c5977ba52512f49fff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 1]: /images/20221120/cd5a85a656cf4b8482c1fd158e140eb6.png
[http_shardingsphere.apache.org_index_zh.html]: http://shardingsphere.apache.org/index_zh.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 2]: /images/20221120/c9b1e32b315146339b154bd3cd6a0a77.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20201201110744617.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20201201110807803.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzcWluZ2Zlbmc=,size_16,color_FFFFFF,t_70