shardingjdbc分库分表数据均衡性讨论
问题引入
最近一个业务系统中，因为数据量很大，经过技术选型，综合权衡选择了sharding-Jdbc，本文主要讨论的是分库分表的表达式
我们有一个批次总表A，还有一个明细表B，我们需要对明细表B进行水平拆分，考虑系统数据的可扩展性和mysql的负载，我们打算针对B表进行分表，分4个数据库，每个数据库64张表，使用A表的主键批次id【fnQpid】来作为分片键。
问题演进
第一版本
一开始选用了一个最简单的hash路由策略，如下：
分库策略为
fnQpid % 4
分表策略为
fnQpid % 64
乍一看，没啥问题，仔细琢磨后发现了一个问题，这样分会导致数据分布不均衡，为啥会导致数据不均衡呢？
假设某一个fnQpid的数据分在了0库的1分表，那么这个fnQpid需要满足什么条件呢？
第一，分在了0库需要满足，fnQpid=4m 【m为整数】 ====》可以推测出fnQpid为偶数
第二，分在1分表需要满足，fnQpid=64n+1 【n为整数】====》可以推测出fnQpid为奇数
毫无疑问，这样的fnQpid是不存在的，也就是某一个fnQpid的数据分在了0库的1分表这个假设不成立，也就是这样分库分表会导致数据分布不均衡。
第二版本
发现上面的问题后，优化了一版分库分表的算法
分库策略
(fnQpid % 256)/64
分表策略
(fnQpid % 256) % 64
简单介绍一下这个方案的思路
- 先计算总的逻辑表的数量，也就是4*64=256
- 然后计算fnQpid % 256的值，这个值的范围是[0,255]，把这256个数据当成是一个整体来看，计算其所在的数据库(fnQpid % 256)/64，该值的范围是[0,3]
- 最后计算所在分表(fnQpid % 256) % 64，该值的数据范围是[0,63]
按照这样的分库分表方式，不会出现第一种情况（有些表永远不会有数据出现），但是这样的路由策略有一个美中不足，如图
当批次号连续自增的时候，明细表的数据分布是这样的，前256个批次的数据在0库，接着在1库，接着在2库，最后在3库，再接着又回到0库，如此循环往复。
若每个批次有1000条数据，那么在短时间内，就会有256000的数据落在同一个数据库，这个瞬时数据的写入、查询都是一个不小的压力。可以说这个方案，数据物理上是分布均衡的，但是在短时间内，mysql单个数据库的负载是不均衡的。
第三版本
考虑到上面两种问题后，继续优化
分库策略为
fnQpid % 4
分表策略为
(fnQpid >> 2) % 64
简单介绍下这个方案
这个方案是在方案一的基础上，进行了分表策略的优化。
一开始是直接用fnQpid % 64，这样有问题是fnQpid的最后两位二进制已经参与了数据库（fnQpid % 4）的计算了，再参与分表的计算，就会互相影响。新的方案是，先踢掉最后两位二进制(fnQpid >> 2)，再参与分表计算，数据流入如下图
可以看到，数据是按照顺序从0库到3库先填充满所有的0表，接着填充满所有的1表…,填充所有的63表，再填充满所有的0表，如此循环往复。当瞬时间有大量数据写入的时候，数据是分散在不同的数据库的，因此解决了方案二（数据库负载不均衡）的问题了
问题总结
为什么分表的数量是64呢？为什么不是100呢？
针对这个问题，大家可以思考下为什么HashMap的初始容量要设置成16（2的4次幂）,redisCluser的哈希槽为什么是16384（2的14次幂）？
我个人认为，是为了提升速度。因为无论是HashMap还是redisCluser，都需要频繁的根据key来计算数组的index，这个操作是hash(key)%16、hash(key)%16384，这样做就差点意思。
看过hashMap源码的同学都知道，源代码上使用了hash(key)&15 来计算index，也就是hash(key)&15等价于hash(key)%16，延展下，
若n为2的整数次幂时 m % n 等价于 m & (n-1)
因此，我们的分库分表为了提速，分表数量选择了2的整数次幂。最终的分库分表的表达式是这样
分库策略为
fnQpid & 3
分表策略为
(fnQpid >> 2) & 63
针对分库分表的策略，大家还遇到过什么坑吗？欢迎评论区留言！