分库分表的原则
- 当数据量较大时，需要分库分表。通常为保证某个用户的数据在同一个库同一个表中，都是按照customerId进行分库分表的。
- 有时每天产生大量数据，这些数据只是为了对账，也可以按月分库，按天分表。比如分为12个库，366张表(考虑闰年)，但数据每天用完后，可以把这些数据再迁移到历史表中，或者类似hdfs这样的表中。
- 分库分表后考虑数据库的扩容问题，同时还要保证在业务系统不停机的时候继续正常的读写数据，需要保证
3.1 如何保证业务系统不停机？
3.2 如何保证扩容时候尽量少的迁移数据？
分库分表的流水号
一般情况下，我们使用customerId作为分库分表键，但有时我们也会产生一个业务ID，并把该业务ID暴露出去，供其他业务系统来查询。这就要求暴露出去的业务ID也是一个分库分表键，这里只需要将分库分表的信息记录在该ID中即可。
比如ID为:01110001002817070500000001036815
这个ID一共32位，由以下几个含义组成
01:Version
11:区域信息
0001:代表这是某个类型的数据
0028:代表数据位于第28张表,
170705:数据产生与17年7月5号
00000001036815:Sequence，全局唯一的流水号
我们可以看到，0028 这个字段就含有分库分表信息。通过算法可以推导出位于第0000库的第0028表。
一致性hash
概述
假如我们用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。
| userId | userName | Sex |
|---|---|---|
| 1001 | 张三 | 0 |
| 1002 | 李四 | 1 |
假如查找数据的时候根据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的优势
分库分表的算法，通过一致性hash，扩容数据只需要迁移一半的数据
比如我们有32个库，每库32张表，则
0库：存在下标为0,1,2......31的表
1库：存在下标为32,33,34......63的表
.......
31库:存在下标为992,993,994,1023的表
对于这样的分库分表，假定按照customerId来分库分表，请看分库分表的算法
//取得customerId的hashCode
int customerIdHashCode = Math.abs(customerId.hashCode());
//使用一致性Hash算法取得customerId应该位于的数据库
int dbIndex = (customerIdHashCode % 4096) / (4096 / 32);
//假定每库为32张表
int tableCountPerDb = 32;
//取得customerId位于的数据库的启始表索引
int tableStartIndex = dbIndex * tableCountPerDb;
//用customerId % 每库表的数量，得到customerId的步长
int tableStep = customerIdHashCode % tableCountPerDb;
//表的起始索引+步长就是customerId应该位于的数据表
int tableIndex = tableStartIndex + tableStep;
return tableIndex
弊端：数据倾斜容易造成雪崩
节点不是均匀分配的，这样我们会造成数据分配不均（倾斜），比如上图中node_7100和node_4100之间的距离比较大，那落在这一区间的概率也比较大，造成node_7100的数据量过大，请求量过大导致雪崩。
解决办法就是建立虚拟节点
虚拟节点并非是一个真实的节点，而是和真实节点之间的一个映射，落在虚拟节点上的数据最终会被转移到真实节点上。
虚拟节点的重建
- node_6100和node_8100就是虚拟节点。这两个节点并非真实节点，而是我们自己添加的节点。
- 当有数据落在node_6100和node_4100之间时，数据会落在node_6100上，这个时候我们做判断发现node_6100是虚拟节点并且映射到了node_4100上，然后我们把数据直接放在node_4100上就可以了。
- node_8100也是虚拟节点操作和node_6100一样被映射到了node_2100上。
那虚拟节点什么时候加呢？
肯定不是在后期加的，尽量在真实节点确认后就设定虚拟节点，虚拟节点没有数量限制，原则上设定的越多分配就越越均匀。不过太多也不便于管理。
这个一致性分表也一样，如果我们key.hashcode%3 我们会创建table_1,table_2,table_3三张表，三张表是后缀是连续的，所以我们尽量不要这么做，而是在2^32-1的范围内自己计算好，均匀的起名均匀的分布。
