分布式哈希表和一致性哈希

 

参考： http://apps.hi.baidu.com/share/detail/15756976

分布式哈希(DHT)
两个key point：每个节点只维护一部分路由；每个节点只存储一部分数据。从而实现整个网络中的寻址和存储。
DHT只是一个概念，提出了这样一种网络模型。并且说明它是对分布式存储很有好处的。但具体怎么实现，并不是DHT的范畴。

一致性哈希：
DHT的一种实现。本质还是一个哈希算法。回想平时我们做负载均衡，按querystring签名对后端节点取模是最简单也是最常用的算法，但节点的增删所造成的问题显而易见：原有的请求几乎都落不到同一台机器上。优化一点的是carp算法，只让1/n的数据受到影响。
一致性哈希，似乎最早提出是在分布式缓存里面的，让节点震荡的时候，影响最小。不过现在已经应用在分布式存储和p2p系统里面。

一致性哈希也只是提出四个概念和原则，并没有提及具体实现：

1、balance：哈希结果尽可能的平均分散到各个节点上，使得每个节点都能得到充分利用。

2、Monotonicity：上面也说了，如果是用签名取模算法，节点变更会使得整个网络的映射关系更改。如果是carp，会使得1/n的映射关系更改。一致性哈希的目标，是节点变更，不会改变网络的映射关系。

3、spread：同一份数据，存储到不同的节点上，换言之就是系统冗余。一致性哈希致力于降低系统冗度。

4、load：负载分散，和balance其实是差不多的意思，不过这里更多是指数据存储的均衡，balance是指访的均衡。


Chord算法：
一致性哈希有多种实现算法，最关键的问题在于如何定义数据分割策略和节点快速查询。

chord算是最为经典的实现。cassandra中的DHT，基本是chord的简化版。

网络中每个节点分配一个唯一id，可以通过机器的mac地址做sha1，是网络发现的基础。

假设整个网络有N 个节点，并且网络是呈环状。两个节点间的距离定义为每个节点会存储一张路由表(finger表)，表内顺时针按照离本节点2、4、8、16、32.……2i的距离选定log2N个其他节点的ip信息来记录。

 

 

存储方面：数据被按一定规则切割，每一份数据也有一个独立id(查询key)，并且和节点id的值域是一样的。然后查找节点，如果存在和数据id一样的节点id，则将这份数据存在该节点上；如果不存在，则存储到离该数据id距离最近的节点上。同时，为了保证数据的可靠性，会顺时针往下找K个冗余节点，存储这份数据。一般认为K=3是必须的。

查询方面：先从自己的路由表中，找一个和数据id距离最近、并且存活在网络中的节点next。如果该节点的id巧合和数据id相等，那么恭喜你。如果不相等，则到next进行递归查找。一般或需要经过多次查询才能找到数据所在的节点，而这个次数是可以被证明小于等于log2N的。

在这个查询的过程中就体现了路由表的选取优势了，其实是实现了一个二分查找，从每个节点来观察网络，都是将网络分成了log2N块，最大一块里面有N/2个节点。路由表里面其实是记录了每一块的第一个节点。这样每一次查询，最少排除了一半的节点。保证在log2N次内找到目标节点。

新增一个节点i，需要预先知道网络中已经存活的一个节点j，然后通过和节点j交互，更新自己和其他节点的路由表。并且，需要将离自己距离最近的节点中的数据copy过来，以提供数据服务。

损失一个节点，路由算法会自动跳过这个节点，并且依靠数据的冗余来持续提供服务。

KAD算法(Kademlia)
个人觉得，kad算法其实是在chord上做的优化。主要是两个点：
1、用二进制(32/64/128)表示一个节点的id，两节点的id异或运算得到节点间的距离。
2、 每个节点保持的路由信息更丰富，同样是将整个网络按照划分成log2N份，在chord中，是保持log2N个路由节点，但在kad里面，是保存了log2N个队列。每个队列长度为配置值K，记录网络中对应节点区域的多个节点，并且根据活跃时间对这些节点进行换入换出。
第一点是方便进行网络划分，节点按照二进制中每一bit的0或1建成一棵二叉树。

第二点是使得节点查询更迅速。从分割情况我们就可以得知，最坏情况不会差于chord，但保存更多的节点使得命中概率更高。另外队列中根据活跃时间进行换入换出，更有利于在p2p这种节点变更频繁的网络中快速找到有效的节点。

关于kad的介绍，这篇文章讲的比较详细wenku.baidu.com/view/ee91580216fc700abb68fcae.html