Apache ShardingSphere 是一款分布式 SQL 事务和查询引擎，可通过数据分片、弹性伸缩、加密等能力对任意数据库进行增强。
2020年4月16日成为 Apache 软件基金会的顶级项目

ShardingSphere的历史可以追溯到其前身Sharding-JDBC，该框架最初由当当网架构部开发，2015年诞生。
2016年，Sharding-JDBC正式开源。
2018年，ShardingSphere进入Apache孵化器，
2020年毕业成为Apache顶级项目

​Apache ShardingSphere 5.x 版本开始致力于可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展。 
目前，数据分片、读写分离、多数据副本、数据加密、影子库压测等功能，
以及 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目。 
Apache ShardingSphere 目前已提供数十个 SPI 作为系统的扩展点，仍在不断增加中。


sharding-JDCB  sharding-proxy sharding-sidecar




sharding-JDCB
​定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 
使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

适用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92标准的数据库。



sharding-proxy
​定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 
目前先提供MySQL/PostgreSQL版本，它可以使用任何兼容MySQL/PostgreSQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat等)操作数据，对DBA更加友好。

向应用程序完全透明，可直接当做MySQL/PostgreSQL使用。
适用于任何兼容MySQL/PostgreSQL协议的的客户端。


sharding-sidecar
​定位为Kubernetes的云原生数据库代理，以Sidecar的形式代理所有对数据库的访问。 
通过无中心、零侵入的方案提供与数据库交互的的啮合层，即Database Mesh，又可称数据网格。

​Database Mesh的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。
使用Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。


三个组件的对比

项目 / sharding-JDCB  / sharding-proxy / sharding-sidecar

数据库         任意  mysql MySQL  
连接数消耗      高 低 高 
支持开发语言    java  任意 任意 
性能           低   高  低 
是否无中心化    是 否 是 
静态入口       无  有  无 





核心概念

1、逻辑表
​ 水平拆分的数据库（表）的相同逻辑和数据结构表的总称
 例：订单数据根据主键尾数拆分为10张表，分别是t_order_0到t_order_9，逻辑表名为t_order

2、真实表
​ 在分片的数据库中真实存在的物理表。 比如 t_order_0到t_order_9 

3、数据节点
​ 数据分片的最小单元。由数据源名称和数据表组成， 比如 ds_0.t_order_0

4、绑定表
​ 指分片规则一致的主表和子表。
 例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。
 绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果SQL为：

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

6、分片键
​ 用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。
  例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 
     SQL中如果无分片字段，将执行全路由，性能差。 
     除了对单分片字段的支持，ShardingSphere支持根据多个字段进行分片。

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

​
目前提供4种分片算法
 由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，
 而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。

精确分片算法 PreciseShardingAlgorithm
用于处理使用单一键作为分片键的=与IN进行分片的场景，需要配合StandardShardingStrategy使用

范围分片算法 RangeShardingAlgorithm
用于处理使用单一键作为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景，需要配合StandardShardingStrategy使用

复合分片算法 ComplexKeysShardingAlgorithm
用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度，配合ComplexShardingStrategy使用

Hint分片算法 HintShardingAlgorithm，用于处理使用Hint行分片的场景，配合HintShardingStrategy使用

8、分片策略
​ 包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。
 真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。
 目前提供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