Sharding-JDBC 实战（史上最全）

在开始 Sharding-JDBC分库分表具体实战前，

必要先了解分库分表的一些核心概念。

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

随着业务数据量的增加，所有原始数据都在一个数据库络上IO及文件IO都集中在一个数据库上，所以CPU、内存、文件IO、网络IO可能成为系统瓶颈。

当业务系统的数据容量接近或超过单个服务器的容量时，QPS/TPS接近或超过单个数据库实例的处理极限，

此时，数据服务和数据存储通常采用垂直和水平的数据拆分方法分布在多个数据库服务器上。

在性能方面，关系数据库多采矿 B 树型索引，

数据量超过一定大小，B Tree 索引的高度就会增加，而每增加一层高度，整个索引扫描就会多一次 IO 。

当数据量超过阈值时，索引深度的增加也会使磁盘访问 IO 次数增加，导致查询性能下降；

一般的存储容量是多少呢？ 请参见 3 高架构秒杀部分内容。

同时，并发访问请求也使集中数据库成为系统最大的瓶颈。

一般吞吐量是多少？ 请参见 3 高架构秒杀部分内容。

当传统的关系数据库法满互联场景需要时，数据存储原始分布式 NoSQL 的尝试越来越多。

但 NoSQL 它不能治愈所有疾病，但关系数据库的地位仍然不可动摇。

如果进行sql、nosql如何选择数据库？ 请参见 推动中台架构的内容。

存储领域采用分治模式：数据分?

数据分是指存储在单个数据库中的数据， 分散存储多个数据库或表中，以提高性能瓶颈和性能。

有效的数据分段是对关系数据库进入分库和分表。

分库能有效分散数据库单点的访问量；

分库的合理时机， 请参见 3 高架构秒杀部分内容。

在有效数据量超过可承受阈值的情况下，分表可以产生查询瓶颈， 解决MySQL 单表性能问题

合理的时机分表， 请参见 3 高架构秒杀部分内容。

可以有效避免数据单点，从而提高数据架构的可用性。

通过分库和分表进?数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进?疏导应对?访问量，是应对?并发和海量数据系统的有效?段。

分为垂直分和平分。

但由于目前大多采用柔性事务，事实上，分库的事务性能也很高，关于柔性事务，请参见疯狂创客圈的专题博文：

分布式事务面试题 (史上最完整、最持续、最新)

Sharding-JDBC 是当当网开源适用于微服务的分布式数据访问基础库，完全实现了分库表、读写分离和分布式关键功能，初步实现了柔性事务。

从 2016 年开源至今，在经历了整体架构的数次精炼以及稳定性打磨后，如今它已积累了足够的底蕴。

官方网站如下：

http://shardingsphere.apache.org/index_zh.html

ShardingSphere它是由开源分布式数据库中间件解决方案组成的生态系统Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar这三种产品相互独立。

他们都提供标准化的数据分片和分布式事务 和 可适用于数据库治理功能Java各种应用场景，如同构、异构语言、云原生等。

Apache ShardingSphere 它是由开源分布式数据库中间件解决方案组成的生态系统 JDBC、Proxy 和 Sidecar(规划)这个 3 模型是独立的，但可以混合部署产品组成。 它们都提供标准化的数据分片、分布式事务和数据库治理功能，适用于例如 Java 各种应用场景，如同构、异构语言、云原生等。

Apache ShardingSphere 定位为关系数据库的中间部分，旨在在分布式场景中充分合理地利用关系数据库的计算和存储能力，而不是实现新的关系数据库。 它通过不变，然后抓住事物的本质。关系数据库仍然占据着巨大的市场，是各公司核心业务的基石，未来难以动摇。现阶段，我们更加关注原有增量，而不是颠覆。

Apache ShardingSphere 5.x 版本开始致力于可插拔架构，项目的功能组件可以通过可插拔的方式灵活扩展。 目前，数据分片、读写分离、数据加密、影子库压力测试等功能 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 在协议的支持下，项目通过插件编织。 开发者可以定制自己独特的系统，就像使用积木一样。Apache ShardingSphere 已提供数十个 SPI 作为系统的扩展点，仍在增加。

ShardingSphere 2020年4月16日 Apache 顶级软件基金会项目。

Sharding-JDBC直接封装JDBC API，可理解为增强版JDBC旧代码迁移的成本几乎为零：

• 可适用于任何基础Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
• 可以基于任何第三方数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
• 理论上可以支持任意实现JDBC标准化数据库。虽然目前只支持MySQL，但已有支持Oracle、SQLServer计划等数据库。

Sharding-JDBC定位为轻量Java使用客户端直接连接数据库的框架jar以包的形式提供服务，没有proxy代理，无需额外部署，无需其他依赖，DBA也不需要改变原来的运维方式。

Sharding-JDBC分片策略灵活，可支持等号，between、in等多维分片，也可支持多分片键。

SQL完善的分析功能，支持聚合、分组、排序limit、or等待查询，并支持Binding Table还有笛卡尔积表查询。

下表仅列出了几个在数据库分片领域非常有影响力的项目：

从上表可以看出，Cobar（MyCat）在应用程序和和中间层方案MySQL之间建一层Proxy。

基于应用程序和数据库之间的中间层需要转发JDBC该协议没有额外的转发，直接由应用程序连接到数据库，具有一定的性能优势。这并不意味着中间层不能像客户那样直接连接。除了性能外，还有许多因素需要考虑，中间层更容易实现监控、数据迁移、连接管理等功能。

Cobar-Client、TDDL和Sharding-JDBC均属于客户端直接连接方案。

该方案的优点是轻便、兼容、性能和性能DBA影响小。其中Cobar-Client以实现为基础ORM（Mybatis）框架的兼容性和可扩展性不如基于框架JDBC协议的后两者。

目前常用的是Cobar（MyCat）与ShardingJDBC两种方案

MyCAT是社区爱好者在阿里cobar基础上进行二次开发，解决了cobar当时存 在的一些问题，并且加入了许多新的功能在其中。目前MyCAT社区活 跃度很高，

目前已经有一些公司在使用MyCAT。

总体来说支持度比 较高，也会一直维护下去，发展到目前的版本，已经不是一个单纯的MySQL代理了，

它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。

MyCAT是一个强大的数据库中间件，不仅仅可以用作读写分离，以及分表分库、容灾管理，而且可以用于多租户应用开发、云平台基础设施，让你的架构具备很强的适应性和灵活性，

借助于即将发布的MyCAT只能优化模块，系统的数据访问瓶颈和热点一目了然，

根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表隐射到不同存储引擎上，而整个应用的代码一行也不用改变。

MyCAT是在Cobar基础上发展的版本，两个显著提高：

• 后端由BIO改为NIO，并发量有大幅提高；

• 增加了对Order By, Group By, Limit等聚合功能

（虽然Cobar也可以支持Order By, Group By, Limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成, 适用于有专门团队维护的大型企业、或者大团队。）

Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。

所以 ，适用于中小企业、或者中小团队。

Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。

SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。

• 分库 & 分表
• 读写分离
• 分布式主键

一般情况下，开发维度的数据分片，大多是以水平切分模式（水平分库、分表）为基础来说的，

垂直分片主要在于 运维维度，或者 或者做存储的深级改造的时候。

简单来说，数据分片的工作分为两大工作 :

参见视频

表的拆分：

将一张大表 t_order ，拆分生成数个表结构完全一致的小表 t_order_0、t_order_1、···、t_order_n，

每张小表，只存储大表中的一部分数据，

当执行一条SQL时，会通过 路由策略 ， 将数据**route(路由)**到不同的分片内。

面临的问题：

• 分片建的选择

• 分片策略的选择

• 分片算法的选择

按照分片规则把数据分到若干个shard、partition当中

一种是按照 range 来分，就是每个片，一段连续的数据，这个一般是按比如时间范围/数据范围来的，但是这种一般较少用，因为很容易发生数据倾斜，大量的流量都打在最新的数据上了。

比如，安装数据范围分片，把1到100个数字，要保存在3个节点上

按照顺序分片，把数据平均分配三个节点上

• 1号到33号数据保存到节点1上
• 34号到66号数据保存到节点2上
• 67号到100号数据保存到节点3上

此种分片规则将数据分成n份（通常dn节点也为n），从而将数据均匀的分布于各个表中，或者各节点上。

扩容方便。

ID取模分片常用在关系型数据库的设计

具体请参见 秒杀视频的 亿级库表架构设计

使用hash 算法，获取key的哈希结果，再按照规则进行分片，这样可以保证数据被打散，同时保证数据分布的比较均匀

哈希分布方式分为三个分片方式：

• 哈希取余分片
• 一致性哈希分片
• 虚拟槽分片

例如1到100个数字，对每个数字进行哈希运算，然后对每个数的哈希结果除以节点数进行取余，余数为1则保存在第1个节点上，余数为2则保存在第2个节点上，余数为0则保存在第3个节点，这样可以保证数据被打散，同时保证数据分布的比较均匀

比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上

哈希取余分片是非常简单的一种分片方式

即当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分布

哈希取余分片，建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。

数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据

哈希取余分片优点：

• 配置简单：对数据进行哈希，然后取余

哈希取余分片缺点：

• 数据节点伸缩时，导致数据迁移
• 迁移数量和添加节点数据有关，建议翻倍扩容

一致性哈希原理：

将所有的数据当做一个token环，

token环中的数据范围是0到2的32次方。

然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个范围内的数据。

对每一个key进行hash运算，被哈希后的结果在哪个token的范围内，则按顺时针去找最近的节点，这个key将会被保存在这个节点上。

在下面的图中：

• 有4个key被hash之后的值在在n1节点和n2节点之间，按照顺时针规则，这4个key都会被保存在n2节点上

• 如果在n1节点和n2节点之间添加n5节点，当下次有key被hash之后的值在n1节点和n5节点之间，这些key就会被保存在n5节点上面了

下图的例子里，添加n5节点之后：

• 数据迁移会在n1节点和n2节点之间进行
• n3节点和n4节点不受影响
• 数据迁移范围被缩小很多

同理，如果有1000个节点，此时添加一个节点，受影响的节点范围最多只有千分之2。所以，一致性哈希一般用在节点比较多的时候，节点越多，扩容时受影响的节点范围越少

分片方式：哈希 + 顺时针(优化取余)

一致性哈希分片优点：

• 一致性哈希算法解决了分布式下数据分布问题。比如在缓存系统中，通过一致性哈希算法把缓存键映射到不同的节点上，由于算法中虚拟节点的存在，哈希结果一般情况下比较均匀。
• 节点伸缩时，只影响邻近节点，但是还是有数据迁移

“但没有一种解决方案是银弹，能适用于任何场景。所以实践中一致性哈希算法有哪些缺陷，或者有哪些场景不适用呢？”

一致性哈希分片缺点：

一致性哈希在大批量的数据场景下负载更加均衡，但是在数据规模小的场景下，会出现单位时间内某个节点完全空闲的情况出现。

Redis Cluster在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现；

虚拟槽分片是Redis Cluster采用的分片方式.

虚拟槽分片 ，可以理解为范围分片的变种， hash取模分片+范围分片， 把hash值取余数分为n段，一个段给一个节点负责

代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。

分片的数量只能在索引创建前指定，并且索引创建后不能更改。（why，大家可以独立思考一下!）

分片配置建议：

每个分片大小不要超过30G，硬盘条件好的话，不建议超过100G.

（官方推荐，每个shard的数据量应该在20GB - 50GB）。

总而言之，每个分片都是一个Lucene实例，当查询请求打到ES后，ES会把请求转发到每个shard上分别进行查询，最终进行汇总。

这时候，shard越少，产生的额外开销越少

一条数据是如何落地到对应的shard上的？

当索引一个文档的时候，文档会被存储到一个主分片中。

Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？

es的路由过程是根据下面这个算法决定的：

Redis Cluster在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现；

虚拟槽分片是Redis Cluster采用的分片方式.

在该分片方式中：

• 首先 预设虚拟槽，每个槽为一个hash值，每个node负责一定槽范围。
• 每一个值都是key的hash值取余，每个槽映射一个数据子集，一般比节点数大

Redis Cluster中预设虚拟槽的范围为0到16383

[root@localhost redis-cluster]# docker exec -it redis-cluster_redis1_1 redis-cli --cluster check 172.18.8.164:6001
172.18.8.164:6001 (c4cfd72f...) -> 0 keys | 5461 slots | 1 slaves.
172.18.8.164:6002 (c15a7801...) -> 0 keys | 5462 slots | 1 slaves.
172.18.8.164:6003 (3fe7628d...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 172.18.8.164:6001)
M: c4cfd72f7cbc22cd81b701bd4376fabbe3d162bd 172.18.8.164:6001
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: a212e28165b809b4c75f95ddc986033c599f3efb 172.18.8.164:6006
   slots: (0 slots) slave
   replicates 3fe7628d7bda14e4b383e9582b07f3bb7a74b469
M: c15a7801623ee5ebe3cf952989dd5a157918af96 172.18.8.164:6002
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 5e74257b26eb149f25c3d54aef86a4d2b10269ca 172.18.8.164:6004
   slots: (0 slots) slave
   replicates c4cfd72f7cbc22cd81b701bd4376fabbe3d162bd
S: 8fb7f7f904ad1c960714d8ddb9ad9bca2b43be1c 172.18.8.164:6005
   slots: (0 slots) slave
   replicates c15a7801623ee5ebe3cf952989dd5a157918af96
M: 3fe7628d7bda14e4b383e9582b07f3bb7a74b469 172.18.8.164:6003
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

1.把16384槽按照节点数量进行平均分配，由节点进行管理 2.对每个key按照CRC16规则进行hash运算 3.把hash结果对16383进行取模 4.把余数发送给Redis节点 5.节点接收到数据，验证是否在自己管理的槽编号的范围

• 如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果
• 如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中

需要注意的是：Redis Cluster的节点之间会共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽

虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。

当节点扩容或者缩容时，对数据槽进行重新分配迁移即可，数据不会丢失。

表的拆分：

将一张大表 t_order ，拆分生成数个表结构完全一致的小表 t_order_0、t_order_1、···、t_order_n，

每张小表，只存储大表中的一部分数据，

当执行一条SQL时，会通过 路由策略 ， 将数据**route(路由)**到不同的分片内。

• 数据源的路由

• 表的路由

面临的问题：

• 分片key的选择
• 分片策略的选择
• 分片算法的选择

⽤于分⽚的字段，是将数据库（表）⽔平拆分的关键字段。

在对表中的数据进行分片时，首先要选出一个分片键（Shard Key），即用户可以通过这个字段进行数据的水平拆分。

例：

将订单表中的订单主键的尾数取模分⽚，则订单主键为分⽚字段。

我们将 t_order 表分片以后，当执行一条 SQL 时，通过对字段 order_id 取模的方式来决定要执行的表, 这条数据该在哪个数据库中的哪个表中执行，此时 order_id 字段就是分片健。

这样以来同一个订单的相关数据就会存在同一个数据库表中，大幅提升数据检索的性能，

• 除了使用单个字段作为分片件， sharding-jdbc 还支持根据多个字段作为分片健进行分片。

• SQL 中如果⽆分⽚字段，将执⾏全路由，性能较差。

数据节点是分库分表中一个不可再分的最小数据单元（表），它由数据源名称和数据表组成，

例如上图中 ds1.t_user_0 就表示一个数据节点。

逻辑表是指一组具有相同逻辑和数据结构表的总称。

比如我们将订单表 t_order 拆分成 t_order_0 ··· t_order_9 等 10 张表。

此时我们会发现分库分表以后数据库中已不在有 t_order 这张表，取而代之的是 t_order_n，但我们在代码中写 SQL 依然按 t_order 来写。

此时 t_order 就是这些拆分表的逻辑表。

例如上图中 t_user 就表示一个数据节点。

真实表也就是上边提到的 t_order_n 数据库中真实存在的物理表。

例如上图中 t_user _0就表示一个真实表。

分片策略是一种抽象的概念，实际分片操作的是由分片算法和分片健来完成的。

真正可⽤于分⽚操作的是分⽚键 + 分⽚算法，也就是分⽚策略。

为什么要这么设计，是出于分⽚算法的独⽴性，将其独⽴抽离。

ShardingSphere-JDBC考虑更多的灵活性，把分片算法单独抽象出来，方便开发者扩展；

标准分片策略适用于单分片键，此策略支持 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 两个分片算法。

其中 PreciseShardingAlgorithm 是必选的，用于处理 = 和 IN 的分片。

RangeShardingAlgorithm 用于处理BETWEEN AND， >， <，>=，<= 条件分片，

RangeShardingAlgorithm 是可选的， 如果不配置RangeShardingAlgorithm，SQL中的条件等将按照全库路由处理。

复合分片策略对应 ComplexShardingStrategy。

同样支持对 SQL语句中的 =，>， <， >=， <=，IN和 BETWEEN AND 的分片操作。

不同的是它支持多分片键，具体分配片细节完全由应用开发者实现。

ComplexShardingStrategy ⽀持多分⽚键，由于多分⽚键之间的关系复杂，因此并未进⾏过多的封装，而是直接将分⽚键值组合以及分⽚操作符透传⾄分⽚算法，完全由应⽤开发者实现，提供最⼤的灵活度。

行表达式分片策略，支持对 SQL语句中的 = 和 IN 的分片操作，但只支持单分片键。

这种策略通常用于简单的分片，不需要自定义分片算法，可以直接在配置文件中接着写规则。

t_order_$->{t_order_id % 4} 代表 t_order 对其字段 t_order_id取模，拆分成4张表，而表名分别是t_order_0 到 t_order_3。

Hint 分片策略，通过指定分片健而非从 SQL 中提取分片健的方式进行分片的策略。

对于分⽚值⾮ SQL 决定，不是来自于分片建，甚至连分片建都没有 ，而由其他外置条件决定的场景，可使⽤Hint 分片策略 。

前面的分片策略都是解析 SQL 语句， 提取分片建和分片值，并根据设置的分片算法进行分片。

Hint 分片算法 指定分⽚值而⾮从 SQL 中提取，而是手工设置的⽅式，进⾏分⽚的策略。

例：内部系统，按照员⼯登录主键分库，而数据库中并⽆此字段。

对应 NoneShardingStrategy。不分⽚的策略。

这种严格来说不算是一种分片策略了。

只是ShardingSphere也提供了这么一个配置。

上边我们提到可以用分片健取模的规则分片，但这只是比较简单的一种，

在实际开发中我们还希望用 >=、<=、>、<、BETWEEN 和 IN 等条件作为分片规则，自定义分片逻辑，这时就需要用到分片策略与分片算法。

从执行 SQL 的角度来看，分库分表可以看作是一种路由机制，把 SQL 语句路由到我们期望的数据库或数据表中并获取数据，分片算法可以理解成一种路由规则。

咱们先捋一下它们之间的关系，分片策略只是抽象出的概念，它是由分片算法和分片健组合而成，分片算法做具体的数据分片逻辑。

分库、分表的分片策略配置是相对独立的，可以各自使用不同的策略与算法，每种策略中可以是多个分片算法的组合，每个分片算法可以对多个分片健做逻辑判断。

sharding-jdbc 提供了多种分片算法：

提供了抽象分片算法类：ShardingAlgorithm，根据类型又分为：精确分片算法、区间分片算法、复合分片算法以及Hint分片算法；

• 精确分片算法：对应PreciseShardingAlgorithm类，主要用于处理 = 和 IN的分片；
• 区间分片算法：对应RangeShardingAlgorithm类，主要用于处理 BETWEEN AND, >, <, >=, <= 分片；
• 复合分片算法：对应ComplexKeysShardingAlgorithm类，用于处理使用多键作为分片键进行分片的场景；
• Hint分片算法：对应HintShardingAlgorithm类，用于处理使用 Hint 行分片的场景；

精确分片算法（PreciseShardingAlgorithm）用于单个字段作为分片键，SQL中有 = 与 IN 等条件的分片，

需要配合 StandardShardingStrategy 使⽤。

范围分片算法（RangeShardingAlgorithm）用于单个字段作为分片键，SQL中有 BETWEEN AND、>、<、>=、<= 等条件的分片，需要需要配合 StandardShardingStrategy 使⽤。

对应 ComplexKeysShardingAlgorithm，⽤于处理使⽤ 多键作为分⽚键 进⾏分⽚的场景，

（多个字段作为分片键），同时获取到多个分片健的值，根据多个字段处理业务逻辑。

包含多个分⽚键的逻辑较复杂，需要应⽤开发者⾃⾏处理其中的复杂度。

需要配合 ComplexShardingStrategy 使⽤。

需要在复合分片策略（ComplexShardingStrategy ）下使用。

Hint 分片算法（HintShardingAlgorithm）稍有不同

前面的算法（如StandardShardingAlgorithm）都是解析 SQL 语句， 提取分片值，并根据设置的分片算法进行分片。

Hint 分片算法 指定分⽚值而⾮从 SQL 中提取，而是手工设置的⽅式，进⾏分⽚的策略。

对于分⽚值⾮ SQL 决定，不是来自于分片建，甚至连分片建都没有 ，而由其他外置条件决定的场景，可使⽤Hint 分片算法 。

就需要通过 Java API 等方式 指定 分片值，这也叫强制路由、或者说 暗示路由。

例： 内部系统，按照员⼯登录主键分库，而数据库中并⽆此字段。

SQL Hint ⽀持通过 Java API 和 SQL 注释（待实现）两种⽅式使⽤。

整个ShardingJDBC 分库分表的核心就是在于**配置 分片策略+分片算法 **。

我们的这些实战都是使用的inline分片算法，即提供一个分片键和一个分片表达式来制定分片算法。

这种方式配置简单，功能灵活，是分库分表最佳的配置方式，并且对于绝大多数的分库分片场景来说，都已经非常好用了。

但是，如果针对一些更为复杂的分片策略，例如多分片键、按范围分片等场景，inline分片算法就有点力不从心了。

所以，我们还需要学习下ShardingSphere提供的其他几种分片策略。

ShardingSphere目前提供了一共五种分片策略：

• NoneShardingStrategy 不分片

• InlineShardingStrategy

最常用的分片方式

按照分片表达式来进行分片。

分片策略基本和上面的分片算法对应，包括：标准分片策略、复合分片策略、Hint分片策略、内联分片策略、不分片策略；\

• 内联分片策略：

对应InlineShardingStrategy类，没有提供分片算法，路由规则通过表达式来实现；

在使用中我们并没有直接使用上面的分片策略类，ShardingSphere-JDBC分别提供了对应策略的配置类包括：

• InlineShardingStrategyConfiguration

有了以上相关基础概念，接下来针对每种分片策略做一个简单的实战，

在实战前首先准备好库和表；

具体请参见视频，和配套源码

分别准备两个库：ds0、ds1；然后每个库分别包含4个表

CREATE TABLE `t_user_0` (`user_id` bigInt NOT NULL, `name` VARCHAR(45) NULL, PRIMARY KEY (`user_id`));
CREATE TABLE `t_user_1` (`user_id` bigInt NOT NULL, `name` VARCHAR(45) NULL, PRIMARY KEY (`user_id`));
CREATE TABLE `t_user_2` (`user_id` bigInt NOT NULL, `name` VARCHAR(45) NULL, PRIMARY KEY (`user_id`));
CREATE TABLE `t_user_3` (`user_id` bigInt NOT NULL, `name` VARCHAR(45) NULL, PRIMARY KEY (`user_id`));

我们这里有两个数据源，这里都使用java代码的方式来配置：

  @Before

    public void buildShardingDataSource() throws SQLException { 
        
        /* * 1. 数据源集合：dataSourceMap * 2. 分片规则：shardingRuleConfig * */

        DataSource druidDs1 = buildDruidDataSource(
                "jdbc:mysql://cdh1:3306/sharding_db1?useUnicode=true&characterEncoding=utf8&allowMultiQueries=true&useSSL=true&serverTimezone=UTC",
                "root", "123456");

        DataSource druidDs2 = buildDruidDataSource(
                "jdbc:mysql://cdh1:3306/sharding_db2?useUnicode=true&characterEncoding=utf8&allowMultiQueries=true&useSSL=true&serverTimezone=UTC",
                "root", "123456");
        // 配置真实数据源
        Map<String, DataSource> dataSourceMap = new HashMap<String, DataSource>();
        // 添加数据源.
        // 两个数据源ds_0和ds_1
        dataSourceMap.put("ds0",druidDs1);
        dataSourceMap.put("ds1", druidDs2);

        /** * 需要构建表规则 * 1. 指定逻辑表. * 2. 配置实际节点》 * 3. 指定主键字段. * 4. 分库和分表的规则》 * */
        // 配置分片规则
        ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();
        //消息表分片规则
        TableRuleConfiguration userShardingRuleConfig = userShardingRuleConfig();
        shardingRuleConfig.getTableRuleConfigs().add(userShardingRuleConfig);
        // 多数据源一定要指定默认数据源
        // 只有一个数据源就不需要
        shardingRuleConfig.setDefaultDataSourceName("ds0");

        Properties p = new Properties();
        //打印sql语句，生产环境关闭
        p.setProperty("sql.show", Boolean.TRUE.toString());

        dataSource= ShardingDataSourceFactory.createDataSource(
                dataSourceMap, shardingRuleConfig, p);

    }

这里配置的两个数据源都是普通的数据源，最后会把dataSourceMap交给ShardingDataSourceFactory管理；

表规则配置类TableRuleConfiguration，包含了五个要素：

逻辑表、真实数据节点、数据库分片策略、数据表分片策略、分布式主键生成策略；

  /** * 消息表的分片规则 */
    protected TableRuleConfiguration userShardingRuleConfig() { 
        
        String logicTable = USER_LOGIC_TB;

        //获取实际的 ActualDataNodes
        String actualDataNodes = "ds$->{0..1}.t_user_$->{0..1}";

        TableRuleConfiguration tableRuleConfig = new TableRuleConfiguration(logicTable, actualDataNodes);

        //设置分表策略
        // inline 模式
        ShardingStrategyConfiguration tableShardingStrategy =
                new InlineShardingStrategyConfiguration("user_id", "t_user_$->{user_id % 2}");
                //自定义模式
// TableShardingAlgorithm tableShardingAlgorithm = new TableShardingAlgorithm();
// ShardingStrategyConfiguration tableShardingStrategy = new StandardShardingStrategyConfiguration("user_id", tableShardingAlgorithm);

        tableRuleConfig.setTableShardingStrategyConfig(tableShardingStrategy);

        // 配置分库策略（Groovy表达式配置db规则）
        // inline 模式
        ShardingStrategyConfiguration dsShardingStrategy = new InlineShardingStrategyConfiguration("user_id", "ds${user_id % 2}");
        //自定义模式
// DsShardingAlgorithm dsShardingAlgorithm = new DsShardingAlgorithm();
// ShardingStrategyConfiguration dsShardingStrategy = new StandardShardingStrategyConfiguration("user_id", dsShardingAlgorithm);
        tableRuleConfig.setDatabaseShardingStrategyConfig(dsShardingStrategy);
        tableRuleConfig.setKeyGeneratorConfig(new KeyGeneratorConfiguration("SNOWFLAKE", "user_id"));
        return tableRuleConfig;
    }

• 逻辑表：这里配置的逻辑表就是t_user，对应的物理表有t_user_0，t_user_1；

• 真实数据节点：这里使用行表达式进行配置的，简化了配置；上面的配置就相当于配置了：

  db0
    ├── t_user_0 
    └── t_user_1 
  db1
    ├── t_user_0 
    └── t_user_1
  
  

• 数据库分片策略：

  这里的库分片策略就是上面介绍的五种类型，

  这里使用的InlineShardingStrategy，需要设置 内联表达式，groovy表达式；

  
          //设置分表策略
          // inline 模式
          ShardingStrategyConfiguration tableShardingStrategy =
                  new InlineShardingStrategyConfiguration("user_id", "t_user_$->{user_id % 2}");
                  //自定义模式
  // TableShardingAlgorithm tableShardingAlgorithm = new TableShardingAlgorithm();
  // ShardingStrategyConfiguration tableShardingStrategy = new StandardShardingStrategyConfiguration("user_id", tableShardingAlgorithm);
  
          tableRuleConfig.setTableShardingStrategyConfig(tableShardingStrategy);
  

  这里的shardingValue就是user_id对应的真实值，每次和2取余；availableTargetNames可选择就是{ds0，ds1}；看余数和哪个库能匹配上就表示路由到哪个库；

• 数据表分片策略：指定的**分片键(order_id)**和分库策略不一致，其他都一样；

• 分布式主键生成策略：ShardingSphere-JDBC提供了多种分布式主键生成策略，后面详细介绍，这里使用雪花算法；

行表达式的使⽤⾮常直观，只需要在配置中使⽤ ${ expression } 或 $->{ expression } 标识 行表达式即可。

⽬前⽀持数据节点和分⽚算法这两个部分的配置。

行表达式的内容使⽤的是 Groovy 的语法，Groovy 能够⽀持的所有操作， 行表达式均能够⽀持。例如： ${begin…end} 表⽰范围区间 ${[unit1, unit2, unit_x]} 表⽰枚举值

行表达式中如果出现连续多个 ${ expression } 或 $->{ expression } 表达式，整个表达式最终的结果将会根据每个表达式的结果进笛卡尔组合。 例如，以下⾏表达式： [ ′ o n l i n e ′ , ′ o f f l i n e ′ ] t a b l e {['online', 'offline']}_table [′online′,′offline′]t​able{1…3} 最终会解析为： online_table1, online_table2, online_table3, offline_table1, offline_table2,offline_table3

配置数据节点时对于均匀分布的数据节点，如果数据结构如下：

db0
├── t_order0
└── t_order1
db1
├── t_order0
└── t_order1