一致性哈希算法原理设计

 

一.前言

一致性哈希(Consistent Hashing)，最早由MIT的Karger于1997年提出，主要用于解决易变的分布式Web系统中，由于宕机和扩容导致的服务震荡。现在这个算法思路被大量应用，并且在实践中得到了很大的发展。

 

二.算法设计

1.问题来源

在做服务器负载均衡时候可供选择的负载均衡的算法有很多，包括： 轮循算法（Round Robin）、哈希算法（HASH）、最少连接算法（Least Connection）、响应速度算法（Response Time）、加权法（Weighted ）等。其中哈希算法是最为常用的算法.

 

一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义：

1、平衡性(Balance)：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。

2、单调性(Monotonicity)：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。

3、分散性(Spread)：在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

4、负载(Load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同 的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

典型的应用场景是： 有N台服务器提供缓存服务，需要对服务器进行负载均衡，将请求平均分发到每台服务器上，每台机器负责1/N的服务。

常 用的算法是对hash结果取余数 (hash() mod N)：对机器编号从0到N-1，按照自定义的hash()算法，对每个请求的hash()值按N取模，得到余数i，然后将请求分发到编号为i的机器。但这 样的算法方法存在致命问题，如果某一台机器宕机，那么应该落在该机器的请求就无法得到正确的处理，这时需要将当掉的服务器从算法从去除，此时候会有(N- 1)/N的服务器的缓存数据需要重新进行计算；如果新增一台机器，会有N /(N+1)的服务器的缓存数据需要进行重新计算。对于系统而言，这通常是不可接受的颠簸（因为这意味着大量缓存的失效或者数据需要转移）。那么，如何设 计一个负载均衡策略，使得受到影响的请求尽可能的少呢？

在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing算法，可以说Consistent Hashing 是分布式系统负载均衡的首选算法。

 

一个由6台服务器组成的服务，每台Server负责存储1/6的数据，当Server1出现宕机之后，服务重新恢复可用时的场景。

如下表格可以很清楚的看到，当Server1宕机时，Hash1的服务完全不可用了，所以需要ReHash由剩余5台机器提供所有的数据服务，但由于每台机器负责的数据段大小不相同，那么需要在不同的服务器之间大量迁移数据，并且数据迁移完成之前服务会不可用。

Hash	0	1		2		3		4		5
正常	Server0	Server1		Server2		Server3		Server4		Server5
S1宕机	Server0			Server2		Server3		Server4		Server5
ReHash	0		1		2		3		4
恢复	Server0		Server2		Server3		Server4		Server5

2.经典一致性哈希算法

针对ReHash的弊端，Karger提出了一种算法，算法的核心是"虚拟节点"。

将所有的数据映射成一组大于服务器数量的虚拟节点，虚拟节点再映射到真实的服务器。所以当服务器宕机时，由于虚拟节点的数量固定不变，所有不需要ReHash，而只需要将服务不可用的虚拟节点重新迁移，这样只需要迁移宕机节点的数据。

经典的算法中，宕机服务器的下一个真实节点将提供服务。

虚拟节点	0-4	5-9	10-14	15-19	20-24	24-29
正常	Server0	Server1	Server2	Server3	Server4	Server5
S1宕机	Server0		Server2	Server3	Server4	Server5
恢复	Server0	Server2	Server2	Server3	Server4	Server5

三.算法改进

1.经典一致性哈希算法的问题

经典的算法只是解决了ReHash算法的缺陷，当本身并不完美。主要存在以下几个问题：

(1)Server1宕机会导致Server2的服务承受一倍的数据服务，且如果Server1就此退役，那么整个系统的负载完全不均衡了。

(2)如果所有的Server都能承受一倍的数据读写，那么如果在正常情况下所有的数据写两份到不同的服务器，主备或者负载均衡，宕机时直接读备份节点的数据，根本不需要出现经典算法中的数据迁移。

虚拟节点

0-4

5-9

10-14

15-19

20-24

24-29

正常

S0

S1

S1

S2

S2

S3

S3

S4

S4

S5

S5

S0

S1宕机

S0

S2

S2

S3

S3

S4

S4

S5

S5

S0

恢复

S0

S2

S2

S3

S3

S4

S4

S5

S5

S0

2.Dynamo改进实践

Amazon的大数据存储平台"Dynamo"使用了一致性哈希，但它并没有使用经典算法，而是使用了故障节点ReHash的思路。

系统将所有的虚拟节点和真实服务器的对应关系保存到一个配置系统，当某些虚拟节点的服务不可用时，重新配置这些虚拟节点的服务到其他真实服务器，这样既不用大量迁移数据，也保证了所有服务器的负载相对均衡。

虚拟节点	0-4/5	10-14/6	15-19/7	20-24/8	24-29/9
恢复	Server0	Server2	Server3	Server4	Server5

四.算法扩展

一致性哈希算法本身是用于解决服务器宕机与扩容的问题，但"虚拟节点"的算法思想有所发展，一些分布式的系统用于实现系统的负载均衡和最优访问策略。

在真实的系统情况下，相同部署的两套系统可能不能提供相同的服务，主要原因：

(1)硬件个体差异导致服务器性能不同。

(2)机房交换机和网络带宽导致IDC服务器之间的网络通信效率不同。

(3)用户使用不同的网络运营商导致电信IDC和联通IDC提供的服务性能不同。

(4)服务器所在网络或机房遭遇攻击。

所以完全相同的两套系统可能也需要提供差异化的服务，通过使用虚拟节点可以灵活的动态调整，达到系统服务的最优化。

对于由2个节点，每个节点3台服务器组成的分布式系统，S0-1为分布式系统1的Server0，系统配置管理员可以根据系统真实的服务效率动态的调整虚拟节点与真实服务器的映射关系，也可以由客户系统自身根据响应率或响应时间等情况调整自身的访问策略。

虚拟节点	0-2	3-4	5-7	8-9	10-12	13-14
服务器	S0-1	S0-2	S1-1	S1-2	S2-1	S2-2

五.Reference

(1)一致哈希(wiki)
(2)Consistent hashing
(3)Dynamo: Amazon’s Highly Available Key-value Store

 

 

原文：http://blog.zheezes.com/consistent-hashing-algorithm-design-principles.html