一般情况下，我们使用customerId作为分库分表键，但有时我们也会产生一个业务ID，并把该业务ID暴露出去，供其他业务系统来查询。这就要求暴露出去的业务ID也是一个分库分表键，这里只需要将分库分表的信息记录在该ID中即可。
比如ID为:01110001002817070500000001036815
这个ID一共32位，由以下几个含义组成
01:Version
11:区域信息
0001:代表这是某个类型的数据
0028:代表数据位于第28张表,
170705:数据产生与17年7月5号
00000001036815:Sequence，全局唯一的流水号
我们可以看到，0028 这个字段就含有分库分表信息。通过算法可以推导出位于第0000库的第0028表。
假如我们用sharding-jdbc分了15张表，之后业务需要扩展到20张表，那问题就来了，之前根据order_id取模15后的数据分散在了各个表中，现在需要重新对所有数据重新取模20来分配数据，工作量太大，有没有更好的方法呢？答案是有的：一致性hash。
先了解下一致性hash, 例子中四个节点一般都是用节点前缀 +（ip+端口）.hahcode%n作为名称。
一致性hash 是个可以理解为圆形，这个圆形称为hash环，环上可以最多建立2的32次方减1个节点。
存数据： 一般根据key.hashcode%n=k,如果k 的范围 1<k<2100，按照顺时针方向，把数据放在node_2100这个节点上。
查找数据：用同样方式取模key.hashcode%n得到的值，然后顺时针查找，刚好卡在1到2100之间，那就去获node_2100上取数据，如果没找到，就去第一个节点上找。这里的key就是表里的某个属性。例如user表用户id作为分表策略就是1001.hashcode%n。
假如查找数据的时候根据key.hashcode%n=1000,那顺时针找1<1000<2100,数据就落在了node_2100这个节点上，存取数据都是这个规则。
假如我们现在需要增加第五个节点，这时候只需要把紧邻第五个节点的下一个节点重新做一次hashcode%5取模就行，不用改动其它节点数据。
原来应该落在node_7100和node_1之间的数据，现在中间多了一个node_7200，数据就有可能被分配到node_7200上，然后我们取数据会发现有时候7200>key.hashcode%5>7100的数据取不到，因为老数据在node_1节点上，那怎么办呢？很简单只需要对该节点重新key.hashcode%5取模分配就好，其它节点数据不用动。
分库分表的算法，通过一致性hash，扩容数据只需要迁移一半的数据
比如我们有32个库，每库32张表，则
0库：存在下标为0,1,2......31的表
1库：存在下标为32,33,34......63的表
.......
31库:存在下标为992,993,994,1023的表
对于这样的分库分表，假定按照customerId来分库分表，请看分库分表的算法
节点不是均匀分配的，这样我们会造成数据分配不均（倾斜），比如上图中node_7100和node_4100之间的距离比较大，那落在这一区间的概率也比较大，造成node_7100的数据量过大，请求量过大导致雪崩。
解决办法就是建立 虚拟节点
虚拟节点并非是一个真实的节点，而是和真实节点之间的一个映射，落在虚拟节点上的数据最终会被转移到真实节点上。
虚拟节点的重建
那虚拟节点什么时候加呢？
肯定不是在后期加的，尽量在真实节点确认后就设定虚拟节点，虚拟节点没有数量限制，原则上设定的越多分配就越越均匀。不过太多也不便于管理。
这个一致性分表也一样，如果我们key.hashcode%3 我们会创建table_1,table_2,table_3三张表，三张表是后缀是连续的，所以我们尽量不要这么做，而是在2^32-1的范围内自己计算好，均匀的起名均匀的分布。