ShardingSphere介绍
Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款相互独立，却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。
一、背景
传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
从性能方面来说，由于关系型数据库大多采用B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的IO次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键。
从运维成本方面考虑，当一个数据库实例中的数据达到阈值以上，对于DBA的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在1TB之内，是比较合理的范围。
在传统的关系型数据库无法满足互联网场景需要的情况下，将数据存储至原生支持分布式的NoSQL的尝试越来越多。 但NoSQL对SQL的不兼容性以及生态圈的不完善，使得它们在与关系型数据库的博弈中始终无法完成致命一击，而关系型数据库的地位却依然不可撼动。
数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。 数据分片的有效手段是对关系型数据库进行分库和分表。分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。 除此之外，分库还能够用于有效的分散对数据库单点的访问量；分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。 使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。
通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。 数据分片的拆分方式又分为垂直分片和水平分片。
垂直分片
按照业务拆分的方式称为垂直分片，又称为纵向拆分，它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。 下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。
垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
水平分片
水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 例如：根据主键分片，偶数主键的记录放入0库（或表），奇数主键的记录放入1库（或表），如下图所示。
水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。
二、概念&功能
数据分片
SQL
① 逻辑表
水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为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分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。
⑤ 广播表
指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景，例如：字典表。
分片
① 分片键
用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，ShardingSphere也支持根据多个字段进行分片。
② 分片算法
通过分片算法将数据分片，支持通过=、>=、<=、>、<、BETWEEN和IN分片。分片算法需要应用方开发者自行实现，可实现的灵活度非常高。
目前提供4种分片算法。由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。
- 精确分片算法：对应PreciseShardingAlgorithm，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。
- 范围分片算法：对应RangeShardingAlgorithm，用于处理使用单一键作为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景。需要配合StandardShardingStrategy使用。
- 复合分片算法：对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。
- Hint分片算法：对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。
③ 分片策略
包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供5种分片策略。
- 标准分片策略：对应StandardShardingStrategy。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。StandardShardingStrategy只支持单分片键，提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。PreciseShardingAlgorithm是必选的，用于处理=和IN的分片。RangeShardingAlgorithm是可选的，用于处理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。不分片的策略。
④ SQL Hint
对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。
配置
① 分片规则
分片规则配置的总入口。包含数据源配置、表配置、绑定表配置以及读写分离配置等。
② 数据源配置
真实数据源列表。
③ 表配置
逻辑表名称、数据节点与分表规则的配置。
④ 数据节点配置
用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式。
- 均匀分布：用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式。如：db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1
- 自定义分布：db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4
⑤ 分片策略配置
对于分片策略存有数据源分片策略和表分片策略两种维度。两种策略的API完全相同。
- 数据源分片策略：对应于DatabaseShardingStrategy。用于配置数据被分配的目标数据源。
- 表分片策略：对应于TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在与该数据的目标数据源内。故表分片策略是依赖与数据源分片策略的结果的。
⑥ 自增主键生成策略
通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。
行表达式
行表达式的使用非常直观，只需要在配置中使用${ expression }或$->{ expression }标识行表达式即可。 目前支持数据节点和分片算法这两个部分的配置。行表达式的内容使用的是Groovy的语法，Groovy能够支持的所有操作，行表达式均能够支持。例如：
${begin..end}表示范围区间
${[unit1, unit2, unit_x]}表示枚举值
行表达式中如果出现连续多个${ expression }或$->{ expression }表达式，整个表达式最终的结果将会根据每个子表达式的结果进行笛卡尔组合。
例如，以下行表达式：
${['online', 'offline']}_table${1..3}
最终会解析为：
online_table1, online_table2, online_table3, offline_table1, offline_table2, offline_table3
■ 配置数据节点
对于均匀分布的数据节点，如果数据结构如下：
db0 ├── t_order0 └── t_order1 db1 ├── t_order0 └── t_order1
用行表达式可以简化为：
db${0..1}.t_order${0..1}
或者
db$->{0..1}.t_order$->{0..1}
对于自定义的数据节点，如果数据结构如下：
db0 ├── t_order0 └── t_order1 db1 ├── t_order2 ├── t_order3 └── t_order4
用行表达式可以简化为：
db0.t_order${0..1},db1.t_order${2..4}
或者
db0.t_order$->{0..1},db1.t_order$->{2..4}
对于有前缀的数据节点，也可以通过行表达式灵活配置，如果数据结构如下：
db0 ├── t_order_00 ├── t_order_01 ├── t_order_02 ├── t_order_03 ├── t_order_04 ├── t_order_05 ├── t_order_06 ├── t_order_07 ├── t_order_08 ├── t_order_09 ├── t_order_10 ├── t_order_11 ├── t_order_12 ├── t_order_13 ├── t_order_14 ├── t_order_15 ├── t_order_16 ├── t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20 db1 ├── t_order_00 ├── t_order_01 ├── t_order_02 ├── t_order_03 ├── t_order_04 ├── t_order_05 ├── t_order_06 ├── t_order_07 ├── t_order_08 ├── t_order_09 ├── t_order_10 ├── t_order_11 ├── t_order_12 ├── t_order_13 ├── t_order_14 ├── t_order_15 ├── t_order_16 ├── t_order_17 ├── t_order_18 ├── t_order_19 └── t_order_20
可以使用分开配置的方式，先配置包含前缀的数据节点，再配置不含前缀的数据节点，再利用行表达式笛卡尔积的特性，自动组合即可。 上面的示例，用行表达式可以简化为：
db${0..1}.t_order_0${0..9}, db${0..1}.t_order_${10..20}
或者
db->${0..1}.t_order_0$->{0..9}, db$->{0..1}.t_order_$->{10..20}
■ 配置分片算法
对于只有一个分片键的使用=和IN进行分片的SQL，可以使用行表达式代替编码方式配置。
行表达式内部的表达式本质上是一段Groovy代码，可以根据分片键进行计算的方式，返回相应的真实数据源或真实表名称。
例如：分为10个库，尾数为0的路由到后缀为0的数据源， 尾数为1的路由到后缀为1的数据源，以此类推。用于表示分片算法的行表达式为：
ds${id % 10}
或者
ds$->{id % 10}
分布式主键
在传统企业软件开发中，主键自动生成技术是基本需求，各个数据库对于该自增主键的需求提供了相应的支持，如MySQL的自增键。对于MySQL而言，分库分表之后，不同库、不同表生成全局唯一的主键是非常麻烦的事情。因为同一个逻辑表内的不同物理表之间的自增主键是无法互相感知的，这样会生成重复的主键。
目前有许多第三方解决方案可以完美解决这个问题，比如UUID等依靠特定算法自生成不重复键，或者通过引入主键生成服务（Redis或者ZooKeeper）等。
Sharding-JDBC提供了抽象接口ShardingKeyGenerator，各个实现类通过实现generateKey()方法即可对外提供生成主键的功能。
目前内置了UUID和SNOWFLAKE（雪花算法）两种主键生成策略。在分片规则配置模块可配置每个表的主键生成策略，默认使用雪花算法（snowflake）生成64bit的长整型数据。
UUID：UUIDShardingKeyGenerator
SNOWFLAKE：SnowflakeShardingKeyGenerator
读写分离
主库：添加、更新以及删除数据操作所使用的数据库，目前仅支持单主库。
从库：查询数据操作所使用的数据库，可支持多从库。
主从同步：将主库的数据异步的同步到从库的操作。由于主从同步的异步性，从库与主库的数据会短时间内不一致。
负载均衡策略：通过负载均衡策略将查询请求疏导至不同从库。
分布式事务
① 两阶段事务-XA：采用的是X/OPEN组织所定义的DTP模型，通过抽象出来的AP, TM, RM的概念可以保证事务的强一致性。
② SAGA柔性事务：一个Saga事务是一个有多个短时事务组成的长时的事务。 在分布式事务场景下，我们把一个Saga分布式事务看做是一个由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务。在Saga事务的执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复成为事务执行之前的状态。
③ SEATA柔性事务：Seata是阿里集团和蚂蚁金服联合打造的分布式事务框架，截止到0.5.x版本包含了AT事务和TCC事务。其中AT事务的目标是在微服务架构下，提供增量的事务ACID语意，让用户像使用本地事务一样，使用分布式事务，核心理念同ShardingSphere一脉相承。
弹性伸缩
① 弹性伸缩作业：指一次将数据由旧分片规则伸缩至新分片规则的完整流程。
② 数据节点：同数据分片中的数据节点
③ 存量数据：在弹性伸缩作业开始前，数据分片中已有的数据。
④ 增量数据：在弹性伸缩作业执行过程中，业务系统所产生的新数据。
