一致性HASH技术的困境

三年前我曾介绍过一致性HASH可能会面临的问题，最近再次思考这个问题，记录一下。

一、背景

三年前，我曾写过两篇文章来介绍一致性HASH技术。
第一篇《一致性hash基础知识》介绍的是一致性HASH的基础知识，也就是一致性HASH是什么，怎么实现的，为什么选择它。
第二篇《一致性hash基础知识(二)》则介绍了在项目实际使用一致性HASH的时，尤其是在高并发与高可靠的场景下，会面临哪些问题。
最近几天，我在思考系统自动化扩容的时候，再次遇到一致性HASH在高并发场景中必然面临的问题。

这些问题我称为一致性HASH的困境。
不是因为这些问题无法解决，而是有多种解决方案。
但是每种解决方案又都会引入新的问题。
我们面对这些解决方案的时候，需要作出抉择，作出取舍。

下面我们就分别来看看这些问题吧。

二、是什么

这里以缓存系统为例来简单回顾一下一致性HASH解决了什么问题，以及怎么解决的。

在缓存的数据量比较小的时候，我们单机就可以储存下所有数据。
那个时候，我们只需要将所有的缓存实例放在路由表下面即可。

业务每次请求的时候，会随机的路由到某一个缓存实例，然后做相对应的逻辑操作。
这里面有一个特征：一次请求可能随机路由到任何一个缓存实例。
即所有的缓存实例是均等的。

后来，随着数据量的增多，单实例不能储存下所有数据了。
单机不能全部储存，意味着命中率的下降，这个在某些时候是不能接受的。

所以我们希望通过多个实例来共同储存一份数据，比如三台机器，每台存三分之一的数据。
这个时候，业务请求的时候，就面临一个问题：该去哪个机器拉取数据。

正常情况下我们会维护一张路由表，然后把 KEY 通过 HASH 取模的方法找到对应的机器。
但是这种方法有一个问题：每次新增机器或者减少机器时，请求 KEY 与缓存机器之间的映射会发生很大的变化。
这种变化意味着，短时间内所有请求都将不能命中缓存。
作为一个高并发的缓存系统，这种状况往往是不能接受的。

所以我们引入了一致性HASH的技术来尽量防止命中率降低。
这里的关键思想在于：新增机器或者减少机器的时候，其他的机器与KEY的映射关系尽量保持不变。
实现方法是：将所有机器 HASH 映射到一个闭环区间上，定义机器节点顺时针上连续线段属于这个机器的。
这样，请求的KEY 也映射到这个闭环区间时，肯定会属于某一个机器。
而当添加或减少机器时，只会影响变更机器对应区间线段的映射关系。

假设我们有三台机器，每台机器占用三分之一的区间线段。后来要减少一台机器。
按照上面的规则进行管理的话，则有一台机器会占用三分之二的区间，而另一台机器不变。