一致性哈希

扯淡:
百度面试的还在门口等的时候,听见前面面试的铁哥们(俺舍友)貌似就在被问如何对数据进行哈希然后分布到多台机器上,在门外各种焦急,就差短信进去了,但估计发五个字又解释不清。很幸运的,我一进门第一道问题也是这个,面试开了个好头后面就比较容易,都是常规的大数据量处理以及字符串处理的一些算法,然后扯了扯搜索广告系统,很顺利的直接去三面聊天谈offer了,很lucky~

一致性哈希的什么四个要素可以看这里。简单的说就是将缓存的数据和存储数据的机器使用相同的哈希函数映射到同一地址空间上上,每个机器负责整个地址空间中的一定范围内的数据。

通常的模N的哈希算法会导致系统中机器数发生变化时需要进行大量的数据重分布,而一致性哈希的地址空间采用环状结构,每个节点i都一个哈希空间上的token(Ti),则该节点负责的数据一般为(Ti-1, Ti],即token落到从前一个节点位置到自身的半开半闭区间的所有数据,如下图(大名鼎鼎的memcache)。



其中地址空间为0~2^32,地址空间上每一个数据都存在顺时针方向的下一个Node上,因此当网络中某个Node i退出时,只需要将该Node负责的数据转移至顺时针方向的Node i+1即可,而当添加一个节点时,也只需要将从添加节点位置到它的predecessor位置的数据移动即可(如下图),最大限度上抑制了数据的重分布。

面试中说针对这种情况采用一致性哈希并描述给面试官以后,接下来面试的问题就是这种设计可能会有什么问题,回答,如果哈希函数散列的对数据散列的效果不良或者节点位置分布不均容易导致整个地址空间中的负载不均。常用的解决方案如下

  1. 虚拟节点(virutal nodes),即地址空间中的每一个节点都是一个虚拟的节点,而一个物理节点可以根据自身的性能,参数等状况划分为多个虚拟节点,即环上的多个节点对应一台机器,Amazon Dynamo模型就采用的此种方法。
  2. 移动节点位置:Avinash & Prashant在Cassandra的Paper中提到面对此种问题的两种方式,一种是前面Dynamo的每一个节点get multi position,另外一种参考Chord的模式,是分析环上的负载,根据负载信息来使得环上的节点移动位置从而减轻负载。Cassandra偏向采用后一种方式,通过负载分析,移动节点来减轻负载,更具备针对性

一致性哈希环在十多年前被提出,在P2P研究中就占到了很重要的位置,特别是根据在一致性哈希基础上提出Chord协议在P2P研究中也起到了很重要的作用。

参考:

memcache全面剖析 (这个强烈推荐阅读)

Avinash & Prashant:  Cassandra A Decentralized Structured Storage System

Ion Stoica , Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan  Chord: A Scalable Peer-to-peer Lookup Service for Internet 文章长了点,但中间的那段Chord Procotol的原理还是值得看下的。

转载请注明来源:Leoncom-《一致性哈希》
Trackback

no comment untill now

Add your comment now