ShardingSphere源码阅读-总览篇
ShardingSphere的最早 只有jdbc这样一款产品，前身是 Sharding-JDBC（来自当当网），也是这个系列中最成熟的部分。经过2.0-现在5.0的变化，现在拥有了Proxy 和 Sidecar（规划中）另外两个产品
数据分片
首先ShardingSphere最早时候出现是因为传统型数据库的局限性。传统数据库大部分使用b+树类型的索引，在数据量超过阈值的情况下（单表数据超2千万，单库数据超过1tb），索引深度增加导致的查询性能瓶颈严重的影响了业务的开展。同时，高并发的访问请求使得集中性数据库很难承载这样的大量io请求。
在传统的关系型数据库没法满足业务需求的时候，大量业务尝试迁移到新型nosql数据库，但是nosql数据库不够成熟，易丢失数据，事务支持不够完整，稳定的情况，导致关系型数据库在重要数据的存储上还是必不可少的。
数据分片将原有单表的数据均匀的分布到不同的数据库或表中，将性能的瓶颈大大的提升了，同时也能更好的支持高并发的访问需求。通过分库和分表的数据拆分，能使各个表的数据都保持在性能阈值之下，可以对海量数据进行疏导和分发。
垂直分片
一般来讲，拆分前所有的业务全部都在一个库中的不同的数据表中，等于说应用的所有业务都要打到这个库的io上，根据下图的示例可见，我们可以把一个库中不同业务拆分到不同的数据库中，专库专用，从而分散压力
垂直分片的问题在于一般需要同步修改大量业务代码，如果在设计上并未非常完备的区分业务，可能会导致非常大的技术债，难以在短时间内使用垂直分片方法分库分表。且垂直分片以后还是可能有单表数据超出了性能阈值，导致需要水平分片。 但是垂直分片其实也是一种程序架构的设计思路，即业务拆分，以及最大化解藕，使得各个业务相互之间因为新增需求的影响降至最小。
水平分片
水平分片又称为横向拆分。 相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 如下图所示：
水平分片解决了单表数据阈值的问题
数据分片脑图
由上图可知，ShardingSphere的分片概念中，分为核心概念，和sql处理。
ShardingSphere的所有产品的sql处理逻辑是一致的由sql解析开始，到结果归并结束：
数据分片支持功能
- 分库分表
- 读写分离
- 分片策略定制化
- 无中心化分布式主键
数据分片分库分表
从sql来说水平分表拆分相同的逻辑和数据结构表，比如原有t_order的订单表经过拆分以后变为 t_order0到t_order_10 10张相同结构的数据表。 根据分片键和分片算法，以及分片策略，将数据均匀的分布在这十个表中 可以通过单一分片键以及单一分片策略分表，也可以通过多个分片键，以及复合分片策略分表。 最后达成数据分散读写的需求
业务分析
需求阐明
新的产品中注册数据是存储在mysql中的库中，数据量大的时候可能达到单表上亿级数据。需要分库分表
技术选型
ShardingSphere jdbc 可以嵌入spring boot 中配置使用，产品成熟，学习成本小。 ShardingSphere proxy 更多的是应用于不同语言场景，公司业务使用java作为后端语言，体现不出proxy项目的优点。proxy产品相较于ShardingSphere jdbc，应用的公司较少，上线的时间较短，所以在公司的新项目中不予采用。
其他部分
分库分表功能是要使用的，加密脱敏功能，因为等保需求会抓取日志中数据，所以倾向于在代码中实现加密脱敏，以及项目中数据存储通过flink流式引擎保存数据，需要更多的测试flink与ShardingSphere jdbc的通用性，如果可以完美支持flink sink方法sink数据，就可以直接尝试在新产品中使用 ShardingSphere jdbc这个数据库中间件。
