对于分布式一致性哈希的思考

时间：2014-11-26 22:49:09 阅读：335 评论：0 收藏：0 [点我收藏+]

标签：style blog http ar color os sp java on

看了几个相关的文章.对4个特性也有了一定的理解。不过还是有些疑问，如果有知情人士能跟我讨论，我会很感激的！！！

平衡性(Balance)
尽量将数据平衡的分布到每一个节点上去。
单调性(Monotonicity)
简单讲就是hash结果不能被其他因素干扰导致错误的情况（例如节点宕机）。
分散性(Spread)
主要是针对同样的数据被分散到不同的节点上，导致数据不一致的情况。只要保证同样的数据产生的哈希一定是一致的，那么就可以避免这类问题。
负载(Load)
原意:

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

我原以为是跟平衡性相关的节点负载问题。其实只要解决分散性的问题，这个问题自然就没有了。

翻不了墙，只能baidu。翻了20来页，说的都是差不多的内容：

用虚拟节点(N)来保证数据的的平衡性&单调性。采取类似 hash(data)%N 的方式让数据平均分布。

在起始时就规定好大小（学术上写的是2^32次方，其实就是一个比较大的值。让你的节点平均分布到这个值上并形成一个环）。

假设约定的虚拟节点数是7。现阶段有3个节点（A,B,C）。

那么按[平均分配、末尾负载]原则，得到的映射关系如下：

[A,A,B,B,C,C,C]

理想情况应该是每个节点负载的范围应该是相同的。所以对于虚拟节点数的设定最好是稳定节点的倍数。

在这个例子中可以设定9，那么得到的映射关系就会是：

[A,A,A,B,B,B,C,C,C]

现在假设其中B结点宕机了，按照下一个节点备份上一个节点的数据的逻辑。那么为了服务可用，B节点部分就会让C节点去替换：

[A,A,A,C,C,C,C,C,C]

这样就保证了单调性、分散性以及负载的问题。

其实仔细想像，由于数据本身的随即性很大，那么怎么才能得到平衡呢？hash本身是保证不了平衡性的。

一旦出现宕机，不平衡的的情况就越发严重。

这其实就是一个hashMap的实现罢了。