共计 1376 个字符，预计需要花费 4 分钟才能阅读完成。
作者：京东物流 何小坡
1 开篇
面对数据的激增，置信大家也都有分库分表的一些计划，这次的这个分享，算是本人的一个想法，能够当做一个参考计划，也欢送相互讨论。
话不多说，间接进入主题。
日常开发中，实现数据库的分库分表，在常常应用工具方面，罕用的有像 sharding-sphere、TDDL、Mycat 等，而后，依据主键 key 做数据分布，有两种罕用的计划，Hash 取模计划和 Range 范畴两种计划，两种路由算法，通过指定的 key 值进行运算后进行数据路由。两种计划也各有各的优缺点，上面做个梳理。
2 Hash 取模
这个计划比拟好了解，例如，咱们假如将来几年内，数据可能增长到 3000 万，那，咱们能够设计 3 张表，设表名别离为：table\_0，table\_1, table\_2, 每张表存 1000 万数据，咱们利用 id 作为路由 key，进行算法解决，将 hash 运算后的后果与 3 进行取模，而后依据所得的值，能够将数据寄存到对应的表中。这种形式的长处是，数据能够平均扩散的存储到对应的表中，不会造成数据全副存储到一个表中的状况, 造成热点库表；然而毛病的话也很显著，就是如果当前再须要扩容的话，再新增表后，例如又新增了 table\_3, table\_4, table\_5, 新的取模就从 3 变成了 6，那这时候，之前的表中的数据，就须要做全量的数据迁徙，因为取模的值产生了变动，依照新值取模，可能就找不到数据了。那面对大量的已有数据，数据迁徙就比拟麻烦了。
3 Range 范畴办法
这个计划，也比拟好了解，还假如业务前期数据能增长到 3000 万，也是能够设计 3 张表，设为：table\_0，table\_1, table\_2，我看能够依照范畴，将 id 在 0—1000 万的数据，寄存在 table\_0 中，id 在 1000 万—2000 万，寄存在 table\_1 中，id 在 2000 万—3000 万，寄存在 table\_2 中。这种计划的话，长处很显著，就是即便当前扩容，也很不便，间接减少新的表即可；然而毛病的话，也很显著，数据不能做扩散存储，在某一段儿工夫内，数据都会集中存储在特定的表中，造成单个表压力过大。
基于以上两种形式的劣势和劣势，能够设计一种可能兼顾两者劣势的计划，即能使数据可能扩散存储，也能不便当前的扩容。以下算是一个计划。次要就是利用 hash 算法来实现数据的扩散存储，利用 range 形式可能比拟好的扩容，将两种计划的劣势联合应用。
4 具体计划
咱们假如有一个分组的概念，假如我的项目初期，预期几年内的数据，数据能够达到 6000 万，能够做如下设计：
如果前面波及到扩容，那只须要再间接减少一个分组即可，在分组内，实现数据的扩散存储，扩容也比拟不便。
即每次扩容，只须要整体减少一个分组即可，一个分组下，能够存储将近几年的数据，所以也不必常常扩容。而后，也能够依据业务状况，将旧数据做归档解决，像当初优惠券零碎的数据，旧数据就能够做整体归档解决，不影响失常业务状况，也加重生产库的压力。
5 总结
分库分表作为大型利用我的项目的架构实现计划，的确有肯定的复杂性，能够依据以后我的项目的理论状况，应用适宜的工具，做具体开发，最次要的还是须要联合本人的我的项目的理论业务状况来定，依据数据的散布以及数据的增长速度，来做联合我的项目场景的设计。也欢送大伙一起探讨，如果有别的更精妙的“秘籍”，也心愿不吝赐教，谢谢。