一致性Hash问题总结

作者：陈章义
链接：http://www.zhihu.com/question/39311007/answer/80724939
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

特别是当memchache的节点很多时，除非类似于算md5，否则很难保证不碰撞。

不冲突的hash算法是 不存在 的， 只要虚拟节点够多， 保证在 概率上每个真实节点的负载是相等 的就好了。

存在多个memchache客户端访问同一个memchache集群，那就存在一种不可避免的情况： memchache客户端1与node a连接正常，但是memchache客户端2与node a却断开了...总而言之，没法保证各memchache客户端之间维护的node列表是完全一致的，

这个是经典的分布式中的partition的问题，  一致性hash算法本身就要解决这个问题 ，而且得到了证明(具体证明可以去google一下一致性hash最早的论文). 这个性质叫分散性 (Spread) : 当上游的机器看到不同的下游列表时(在上线时及不稳定的网络中比较常见), 同一个请求 尽量映射到少量的节点中 。

另外说句题外话， 这个问题和 分布式一致性 没有任何关系. 分布式一致性英文叫做 distributed consensus. 一致性hash叫做 consistent hashing. 完全是两回事情， 不能混为一谈，一致性hash保证不了任何的分布式一致性， 只是一种降低cachemiss的负载均衡而已。

作者：王斌
链接：http://www.zhihu.com/question/39311007/answer/92763767
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

问题的关键点在于“节点很多”，“hash碰撞”， “心跳”， “失效处理”。

1. 首先说节点不会很多
实际使用中，不只数据库需要垂直切分，缓存也需要垂直切分，以避免在资源紧张的情况下不同业务对资源的争抢。MC是不知道你的业务哪个最重要，也没法屏蔽垃圾代码。
如果你确实有如此大的业务模块，那我觉得你其它地方早已经产生瓶颈了。

2. 其次说hash碰撞
综上一个C段好了把，200+机器，hash碰撞概率极小了。

3. 然后是心跳
200+机器规模下，就算长连接也可接受，当然有些浪费。
一般的处理逻辑是发现节点失效，使用下一节点。

4. 失效处理
一致性哈希失效处理是有些问题，但和问题中描述的不太相同。
应该尽量确保服务组件和MC集群之间网络的稳定性。缓存肯定是就近部署的，要不然还有啥用。
而且可以这么理解，如果你集群内部网络都出问题了，那对外提供的服务。。。
其实比较容易出现的问题是漂移的问题：某个节点失效了，缓存都漂到下个节点了；然后一会它又恢复了，这时候它就有脏数据了。
解决办法一是每个节点引入集群。
不用集群想彻底解决这个问题，可能需要引入第三方健康检查组件，如Consul，发现节点不稳定立即删除下线。

5. 缓存命中率及单一热点问题
一致性哈希解决的是某节点宕机后缓存失效的问题，只会导致相邻节点负载增加。但是因为宕机后需要重新从数据库读取，会导致此时缓存命中率下降及db压力增加。
也无法避免单一热点问题。某一数据被海量请求，不论怎么哈希，哈希环多大，数据只存在一个节点，早晚有被打垮的时候。

此时的解决策略是每个节点主备或主主集群。

https://blog.csdn.net/mergerly/article/details/52132168