近年来B2C、O2O等商业概念的提出和移动端的发展，使得分布式系统流行了起来。分布式系统相对于单系统，解决了流量大、系统高可用和高容错等问题。功能强大也意味着实现起来需要更多技术的支持。例如系统访问层的负载均衡，缓存层的多实例主从复制备份，数据层的分库分表等。我们以负载均衡为例，常见的负载均衡方法有很多，但是它们的优缺点也都很明显：

• 随机访问策略。系统随机访问，缺点：可能造成服务器负载压力不均衡，俗话讲就是撑的撑死，饿的饿死。
• 轮询策略。请求均匀分配，如果服务器有性能差异，则无法实现性能好的服务器能够多承担一部分。
• 权重轮询策略。权值需要静态配置，无法自动调节，不适合对长连接和命中率有要求的场景。
• Hash取模策略。不稳定，如果列表中某台服务器宕机，则会导致路由算法产生变化，由此导致命中率的急剧下降。
• 一致性哈希策略。

以上几个策略，排除本篇介绍的一致性哈希，可能使用最多的就是 Hash取模策略了。Hash取模策略的缺点也是很明显的，这种缺点也许在负载均衡的时候不是很明显，但是在涉及数据访问的主从备份和分库分表中就体现明显了。

Hash算法原理

Hash，一般翻译做散列，也有直接音译为哈希，就是把任意长度的输入（又叫做预映射， pre-image），通过散列算法，变换成固定长度的输出，该输出就是散列值，下图为Hash算法中常用的除留余数法。

根据上面的算法，普通的Hash算法均匀地将这些数据项打散到了这些节点上，并且分布最少和最多的存储节点数据项数目小于1%。之所以分布均匀，主要是依赖Hash算法（实现使用的MD5算法）能够比较随机的分布。

使用Hash取模的问题

负载均衡

负载均衡时，假设现有3台服务器(编号分别为0、1、2)，使用哈希取模的计算方式则是：对访问者的IP，通过固定算式hash(IP) % N（N为服务器的个数），使得每个IP都可以定位到特定的服务器。

例如现有IP地址 10.58.34.31，对IP哈希取模策时，计算结果为2，即访问编号为2的服务器：

String ip = "10.58.34.31";

int v1 = hash(ip) % 3;

System.out.println("访问服务器：" + v1);// 访问服务器：2

如果此时服务器2宕机了，则会导致所有计算结果为2的 IP 对应的用户都访问异常（包括上例中的IP）。或者你新增了一台服务器3，这时不修改N值的话那么服务器3永远不会被访问到。

当然如果你能动态获取到当前可用服务器的个数，亦即N值是根据当前可用服务器个数动态来变化的，则可解决此问题。但是对于类似要在特定地区或特定IP来访问特定服务器的这种需求就会造成访问偏差。

分库分表

负载均衡中有这种问题，那么分库分表中同样也有这样的问题。例如随着业务的飞速增长，我们的注册用户也越来越多，单个用户表数量已经达到千万级甚至更大。由于Mysql的单表建议百万级数据存储，所以这时为了保证系统查询和运行效率，肯定会考虑到分库分表。对于分库分表，数据的分配是个重要的问题，你需要保证数据分配在这个服务器，那么在查询时也需要到该服务器上来查询，否则会造成数据查询丢失的问题。

通常是根据用户的 ID 哈希取模得到的值然后路由到对应的存储位置，计算公式为：hash(userId) % N，其中N为分库或分表的个数。

例如分库数为2时，计算结果为1，则ID为1010的用户存储在编号为1对应的库中：

String userId = "1010";

int v1 = hash(userId) % 2;

System.out.println("存储：" + v1);// 存储：1

之后业务数量持续增长，又新增一台用户服务库，当我们根据ID=1010去查询数据时，路由计算方式为：

int v2 = hash(userId) % 3;

System.out.println("存储：" + v2);// 存储：0

我们得到的路由值是0，最后的结果就不用说了，存在编号1上的数据我们去编号为0的库上去查询肯定是得不到查询结果的。

为了数据可用，你需要做数据迁移，按照新的路由规则对所有用户重新分配存储地址。每次的库或表的数量改变你都需要做一次全部用户信息数据的迁移。不用想这其中的工作量是有多费时费力了。

是否有某种方法，有效解决这种分布式存储结构下动态增加或删除节点所带来的问题，能保证这种不受实例数量变化影响而准确路由到正确的实例上的算法或实现机制呢？解决这些问题，一致性哈希算法诞生了。

一致性hash算法的原理

consistent hashing 是一种 hash 算法，简单的说，在移除 / 添加一个 cache 时，它能够尽可能小的改变已存在 key 映射关系，尽可能的满足单调性的要求。下面就来按照 5 个步骤简单讲讲 consistent hashing 算法的基本原理。

环形hash 空间

考虑通常的 hash 算法都是将 value 映射到一个 32 位的 key 值，也即是 0~2^32-1 次方的数值空间；我们可以将这个空间想象成一个首（ 0 ）尾（ 2^32-1 ）相接的圆环，如下面图 1 所示的那样。

图 1 环形 hash 空间

把对象映射到hash 空间

接下来考虑 4 个对象 object1~object4 ，通过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。

hash(object1) = key1;

… …

hash(object4) = key4;

把cache 映射到hash 空间

Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中，并且使用相同的 hash 算法。假设当前有 A,B 和 C 共 3 一 cache ，那么其映射结果将如图 3 所示，他们在 hash 空间中，以对应的 hash 值排列。

hash(cache A) = key A;

… …

hash(cache C) = key C;

说到这里，顺便提一下 cache 的 hash 计算，一般的方法可以使用 cache 机器的 IP 地址或者机器名作为 hash 输入。

把对象映射到cache

现在 cache 和对象都已经通过同一个 hash 算法映射到 hash 数值空间中了，接下来要考虑的就是如何将对象映射到 cache 上面了。在这个环形空间中，如果沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上，因为对象和 cache 的 hash 值是固定的，因此这个 cache 必然是唯一和确定的。这样不就找到了对象和 cache 的映射方法了吗？！依然继续上面的例子（参见图 3 ），那么根据上面的方法，对象 object1 将被存储到 cache A 上；object2 和 object3 对应到 cache C ；object4 对应到 cache B ；

考察cache 的变动

前面讲过，通过 hash 然后求余的方法带来的最大问题就在于不能满足单调性，当 cache 有所变动时， cache 会失效，进而对后台服务器造成巨大的冲击，现在就来分析分析 consistent hashing 算法。

1）移除 cache

考虑假设 cache B 挂掉了，根据上面讲到的映射方法，这时受影响的将仅是那些沿 cache B 逆时针遍历直到下一个 cache （ cache C ）之间的对象，也即是本来映射到 cache B 上的那些对象。因此这里仅需要变动对象 object4 ，将其重新映射到 cache C 上即可；参见图 4 。

2）添加 cache

再考虑添加一台新的 cache D 的情况，假设在这个环形 hash 空间中， cache D 被映射在对象 object2 和 object3 之间。这时受影响的将仅是那些沿 cache D 逆时针遍历直到下一个 cache （ cache B ）之间的对象（它们是也本来映射到 cache C 上对象的一部分），将这些对象重新映射到 cache D 上即可。因此这里仅需要变动对象 object2 ，将其重新映射到 cache D 上；参见图 5

hash 算法并不是保证绝对的平衡，如果 cache 较少的话，对象并不能被均匀的映射到 cache 上，比如在上面的例子中，仅部署 cache A 和 cache C 的情况下，在 4 个对象中， cache A 仅存储了 object1 ，而 cache C 则存储了 object2 、 object3 和 object4 ；分布是很不均衡的。

虚拟节点

考量 Hash 算法的另一个指标是平衡性 (Balance) ，定义如下：平衡性

　　平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。

hash 算法并不是保证绝对的平衡，如果 cache 较少的话，对象并不能被均匀的映射到 cache 上，比如在上面的例子中，仅部署 cache A 和 cache C 的情况下，在 4 个对象中， cache A 仅存储了 object1 ，而 cache C 则存储了 object2 、 object3 和 object4 ；分布是很不均衡的。为了解决这种情况， consistent hashing 引入了“虚拟节点”的概念，它可以如下定义：“虚拟节点”（ virtual node ）是实际节点在 hash 空间的复制品（ replica ），一实际个节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在 hash 空间中以 hash 值排列。

仍以仅部署 cache A 和 cache C 的情况为例，在图 4 中我们已经看到， cache 分布并不均匀。现在我们引入虚拟节点，并设置“复制个数”为 2 ，这就意味着一共会存在 4 个“虚拟节点”， cache A1, cache A2 代表了 cache A ；cache C1, cache C2 代表了 cache C ；假设一种比较理想的情况，参见图 6 。

此时，对象到“虚拟节点”的映射关系为：objec1->cache A2 ；objec2->cache A1 ；objec3->cache C1 ；objec4->cache C2 ；因此对象 object1 和 object2 都被映射到了 cache A 上，而 object3 和 object4 映射到了 cache C 上；平衡性有了很大提高。引入“虚拟节点”后，映射关系就从 { 对象 -> 节点 } 转换到了 { 对象 -> 虚拟节点 } 。查询物体所在 cache 时的映射关系如图 7 所示。

“虚拟节点”的 hash 计算可以采用对应节点的 IP 地址加数字后缀的方式。例如假设 cache A 的 IP 地址为 202.168.14.241 。引入“虚拟节点”前，计算 cache A 的 hash 值：Hash(“202.168.14.241”);引入“虚拟节点”后，计算“虚拟节”点 cache A1 和 cache A2 的 hash 值：Hash(“202.168.14.241#1”); // cache A1 Hash(“202.168.14.241#2”); // cache A2

总结

一致性哈希一般在分布式缓存中使用的也比较多，本篇只介绍了服务的负载均衡和分布式存储，对于分布式缓存其实原理是类似的，读者可以自己举一反三来思考下。其实，在分布式存储和分布式缓存中，当服务节点发生变化时（新增或减少），一致性哈希算法并不能杜绝数据迁移的问题，但是可以有效避免数据的全量迁移，需要迁移的只是更改的节点和它的上游节点它们两个节点之间的那部分数据。另外，我们都知道 hash算法 有一个避免不了的问题，就是哈希冲突。对于用户请求IP的哈希冲突，其实只是不同用户被分配到了同一台服务器上，这个没什么影响。但是如果是服务节点有哈希冲突呢？这会导致两个服务节点在哈希环上对应同一个点，其实我感觉这个问题也不大，因为一方面哈希冲突的概率比较低，另一方面我们可以通过虚拟节点也可减少这种情况。

最后，如果我的文章对你有所帮助或者有所启发，欢迎关注公众号（微信搜索公众号：首席架构师专栏），里面有许多技术干货，也有我对技术的思考和感悟，还有作为架构师的验验分享；关注后回复 【面试题】，有我准备的面试题、架构师大型项目实战视频等福利 ， 小编会带着你一起学习、成长，让我们一起加油！！！