本文原创，使用本文请注明出处。
本文总结较为浅显，有兴趣的同学可直接参考官方文档
背景
为解决关系型数据库面对海量数据由于数据量过大而导致的性能问题时，将数据进行分片是行之有效的解决方案，而将集中于单一节点的数据拆分并分别存储到多个数据库或表，称为分库分表。 分库可以有效分散高并发量，分表虽然无法缓解并发量，但仅跨表仍然可以使用数据库原生的ACID事务。而一旦跨库，涉及到事务的问题就会变得无比复杂。
分库分表一般有两种拆分方式。按照业务拆分的方式称为垂直拆分。
例如，根据业务的不同将订单库拆成两个相同的数据库，称之为垂直拆分。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治，如果垂直拆分之后的订单数量依然超过单节点所能承载的阈值，则需要水平拆分来进一步处理。 将一个表中的数据按照一定的业务规则拆分至不同表和数据库中，称之为水平拆分。例如，原来的订单数据在order_ds.t_order表中，如果按照订单的user_id将订单拆分为2个库，再按照订单的order_id在每个库中分成4个表，那么拆分的结果则是order_ds_0.t_order_0，order_ds_0.t_order_1，order_ds_0.t_order_2，order_ds_0.t_order_3，order_ds_1.t_order_0，order_ds_1.t_order_1，order_ds_1.t_order_2，order_ds_1.t_order_3。 这只是简单的水平拆分案例，在实际使用中，将库和表拆分的更加分散也是十分常见的。
虽然数据分片解决了性能问题，但也额外的引入了其他问题。面对如此散乱的分库分表之后的数据，应用开发和运维人员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要知道什么样的数据需要从哪个具体的数据库的分表中去获取。透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平拆分之后的数据库，是分库分表中间件的主要功能。
分片的概念
分片键
用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。例：订单表订单ID分片尾数取模分片，则订单ID为分片字段。SQL中如果无分片字段，将执行全路由，性能较差，支持多分片字段。
分片算法
通过分片算法将数据分片，支持通过等号、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。不分片的策略。
Hint
对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录ID分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。
实践
首先建立两个相同单命名不同的库
然后在项目中（本文使用spring boot框架）
引入maven依赖
基于Java编码的分库规则配置（DataConfig.java）
查询语句（更新语句同理）
当执行查询或更新语句时，系统会根据DataConfig中的配置路由到对应的库下面的表中，“platformId”、“orderId”是路由的关键，“platformId”、“orderId”作为分片键，必须是唯一的。
分布式主键的概念
实现动机
传统数据库软件开发中，主键自动生成技术是基本需求。而各个数据库对于该需求也提供了相应的支持，比如MySQL的自增键，Oracle的自增序列等。 数据分片后，不同数据节点生成全局唯一主键是非常棘手的问题。同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。 虽然可通过约束自增主键初始值和步长的方式避免碰撞，但需引入额外的运维规则，使解决方案缺乏完整性和可扩展性。
目前有许多第三方解决方案可以完美解决这个问题，如UUID等依靠特定算法自生成不重复键，或者通过引入主键生成服务等。 但也正因为这种多样性导致了Sharding-Sphere如果强依赖于任何一种方案就会限制其自身的发展。
基于以上的原因，Sharding-Sphere最终采用以接口来实现对于生成主键的访问，而将底层具体的主键生成实现分离出来。
默认分布式主键生成器
采用snowflake算法实现，生成的数据为64bit的长整型数据。
其二进制表示形式包含四部分，从高位到低位分表为：1bit符号位(为0)，41bit时间位，10bit工作进程位，12bit序列位。
该算法保证不同进程的主键肯定是不同的，同一个进程首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。 同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。例如MySQL的Innodb存储引擎的主键。
在数据库中应该用大于等于64bit的数字类型的字段来保存该值，比如在MySQL中应该使用BIGINT。
类名称：io.shardingjdbc.core.keygen.DefaultKeyGenerator
时间位(41bit)
从2016年11月1日零点到现在的毫秒数，时间可以使用到2156年，满足大部分系统的要求。
工作进程位(10bit)
该标志在Java进程内是唯一的，如果是分布式应用部署应保证每个进程的工作进程Id是不同的。该值默认为0，可通过调用静态方法DefaultKeyGenerator.setWorkerId("xxxx")设置。
序列位(12bit)
该序列是用来在同一个毫秒内生成不同的Id。如果在这个毫秒内生成的数量超过4096(2的12次方)，那么生成器会等待到下个毫秒继续生成。
