分布式哈希表及chord探究.ppt

* * * * 分布式哈希表及chord 一致性哈希(Consistent Hash) 一致性哈希算法在1997年由麻省理工学院提出。指出了在动态变化的Cache环境中，哈希算法应该满足的4个适应条件： 1、平衡性(Balance) 平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 2、单调性(Monotonicity) 　　单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。 　　 一致性哈希(Consistent Hash) 2、单调性(Monotonicity) ——续 　　简单的哈希算法往往不能满足单调性的要求，如最简单的线性哈希： 　　x → (ax + b) mod (P) 　　在上式中，P表示全部缓冲的大小。不难看出，当缓冲大小发生变化时(从P1到P2)，原来所有的哈希结果均会发生变化，从而不满足单调性的要求。 　　哈希结果的变化意味着当缓冲空间发生变化时，所有的映射关系需要在系统内全部更新。而在P2P系统内，缓冲的变化等价于Peer加入或退出系统，这一情况在P2P系统中会频繁发生，因此会带来极大计算和传输负荷。单调性就是要求哈希算法能够避免这一情况的发生。 一致性哈希(Consistent Hash) 3、分散性(Spread) 　　在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希 过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区 中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法 应能够尽量避免不一致的情况发生，也就是尽量降低分散性。 4、负载(Load) 　　负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。 一致性哈希(Consistent Hash) 从表面上看，一致性哈希针对的是分布式缓冲的问题，但是如果将缓冲看作P2P系统中的Peer，将映射的内容看作各种共享的资源(数据，文件，媒体流等)，就会发现两者实际上是在描述同一问题。 例：假定有一个分布式WEB缓存系统，那么其数据缓存的算法可以有两种。 1、hash模余算法： ????根据hash(key)% N的结果决定存储到哪个节点（key:数据的关键字键值，N:服务器个数），此计算方法简单，数据的分散性也相当优秀。 ??? 其缺点是当添加或移除服务器时，缓存重组的代价相当巨大。添加/删除服务器后（或者是某台服务器出现故障之后），余数就会产生巨变，这样就无法保证获取时计算的服务器节点与保存时相同，从而影响缓存的命中率——造成原有的缓存数据将大规模失效。 一致性哈希(Consistent Hash) 2、一致性哈希（Consistent Hashing）我们采用了一种新的方式来解决问题，处理服务器的选择不再仅仅依赖key的hash本身而是将服务实例（节点）的配置也进行hash运算。 1）首先求出每个服务节点的hash，并将其配置到一个0~232的圆环（continuum）区间上。 2）其次使用同样的方法求出所需要存储的key的hash，也将其配置到这个圆环（continuum）上。 3）然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务节点上。如果超过232仍然找不到服务节点，就会保存到第一个服务节点上。 一致性哈希(Consistent Hash) 一致性哈希(Consistent Hash) 一致性哈希(Consistent Hash) 为了维护上述路由信息，在节点加入/退出系统时，相邻的节点必须及时更新路由信息。这就要求节点不仅存储直接相连的下行节点位置信息，还要知道一定深度 (n跳)的间接下行节点信息，并且动态地维护节点列表。当节点退出系统时，它的上行节点将尝试直接连接到最近的下行节点，连接成功后，从新的下行节点获得下行节点列表并更新自身的节点列表。同样的，当新的节点加入到系统中时，首先根据自身的ID找到下行节点并获得下行节点列表，然后要求上行节点修改其下行节点列表，这样就恢复了路由关系。 为了构建查询所需的路