一些关于一致哈希的后续问题

时间:2014-01-11 05:57:08

标签: distributed-caching distributed-system consistent-hashing

我已经阅读了一些解释一致哈希背后理论的文章。但是他们中的大多数并没有提供有关如何处理添加/删除节点的详细信息。我知道如果它在缓存层中使用,如memcached,我们可能不需要做任何事情,但如果它在分布式存储中使用,将一些数据移动到正确的节点是非常关键的。当我们需要添加/删除节点时到底发生了什么?

其他一些问题是:

  1. 应对不同规模的服务器的最佳方式是什么
  2. 如何一次添加和删除多台计算机
  3. 如何应对复制和容错
  4. 希望有人能指出我解释这些内容的文章。

2 个答案:

答案 0 :(得分:1)

对于您原来的问题,您只需要另外一种方法将对象从一个节点切换到另一个节点。这可能是你添加和删除节点的一​​个因素,而不是一致的哈希工作方式。

一种假设的方法是在重新平衡时考虑存在中间状态,其中有两个一致的哈希值,一个用于旧拓扑,一个用于新拓扑。区分它们,每个服务器应该能够告诉它需要做什么来符合新拓扑。例如,每个服务器使用旧的一致性哈希从旧服务器请求它没有的对象。一旦我们达到某种“完成”状态,我们就可以删除旧副本(如有必要)。

  1. 通过调整副本数量,一致性哈希允许您为服务器赋予权重。这可能是HRW一致散列的最佳优势。

  2. 这可能只是添加一台机器。

  3. HRW有一个有用的想法,即一致的散列没有像通常所解释的那样获得后续节点。也就是说,它不是为您提供对象的“the”节点,而是为您提供“对象的有序节点列表”。如果您决定要为每个对象设置3个副本,则从列表中选择前三个,而不是仅从第一个开始。

  4. 你可以在一致性哈希中获得相同的效果,虽然它不那么直观:只需继续绕过“圆圈”,直到你有N个唯一的节点。

答案 1 :(得分:0)

  

但是他们中的大多数都没有详细说明如何处理添加/删除节点。

您是否阅读过Dynamo: Amazon’s Highly Available Key-value Store?第4节将对此进行详细介绍。

  

应对不同规模的服务器的最佳方法是什么

没有什么可以阻止您在类似Dynamo或Cassandra的系统中将不同数量的数据放在不同的服务器上。它会增加大量的复杂性,特别是在故障恢复情况下,但不会以任何方式打破protcol的基本原理。