分库分表终极问题解答-高可用性实现方式：一致性hash

面试必考题

面试时候经常会问单表数据量过大如何拆分，拆分后数据迁移如何做，如何保证高可用，如何分页，如何多条件查询,如何保证事务一致性……一连串的问题问的满眼五角星。抽时间整理了一些文章发出来，希望可以帮到你，让你的面试官对你刮目相看。

今天主讲分库分表的高可用实现方式一致性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

如图纯手绘：

节点信息

假如查找数据的时候根据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取模分配就好，其它节点数据不用动。

弊端：数据倾斜容易造成雪崩。

如上图，4个节点不是均匀分配的，这样我们会造成数据分配不均（倾斜），比如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的范围内自己计算好，均匀的起名均匀的分布。

扫描下面的二维码，分库分表-sharding-jdbc分页，排序，条件查询优化的答案

 

写的不好请多指教哈，如果觉着对你有帮助请扫描关注呀，