认识一致性哈希

工程师常使用服务器集群来设计和实现数据缓存，以下是常见的策略：
、

1. 无论是添加、查询还是删除数据，都先 将数据的id 通过哈希函数 换成一个哈希值，记为key
2. 如果目前机器有N台，则计算 key%N 的值，这个值就是该数据所属的机器编号，无论是添加、删除还是查询
   操作，都只在这台机器上进行。
   请分析这种缓存策略可能带来的问题，并提出改进的方案。

题目中描述的缓存从策略的潜在问题是：如果增加或删除机器时（N变化）代价会很高，所有的数据都不得不根据
id重新计算一遍哈希值，并将哈希值对新的机器数进行取模，然后进行大规模的数据迁移。

为了解决这些问题，下面介绍一下一致性哈希算法，这是一种很好的数据缓存设计方案。我们假设数据的id通过哈
希函数转换成的哈希值范围是2^{32，也就是0~(2}32)-1的数字空间中。现在我们可以将这些数字头尾相连，想象成一个闭合的环形，那么一个数据id在计算出哈希值之后认为对应到环中的一个位置上，如图所示

接下来想象有三台机器也处在这样一个环中，这三台机器在环中的位置根据机器id（主机名或者主机IP，是主机唯
一的就行）设计算出的哈希值对2^32取模对应到环上。那么一条数据如何确定归属哪台机器呢？我们可以在该数据
对应环上的位置顺时针寻找离该位置最近的机器，将数据归属于该机器上：

将机器m1的ip弄到哈希函数中，并对应到环上

其经过哈希函数计算之后，会得到一个哈希值，这个时候不进行 取余（一致性哈希结构 不存在取余）
得到的一个哈希值会 打到环上的位置！
接着顺时针找到距离最近的机器。

假设机器的哈希值如下：

然后假设一个字符串“zuo”算出来的哈希值是 136
然后用二分的方法，进行查找
先打到9，然后打到130，然后打到270，即“zuo”应该用m4，这就是顺时针找到离其最近距离的方法

问题一：增加机器时，可能会打破现有的平衡：

不过迁移的代价很小；
比如，这段原来是 属于m3的，

如果要把m4减掉，则把m4的数据扔回m3即可，数据迁移完毕。

问题二：机器较少时，通过机器id哈希将机器对应到环上之后，几个机器可能没有均分环，那么这样会导致负载不均。

即 量太少了，哈希函数均匀性的性质体现不出来！有可能把两台机器的距离打的很近！

且即便可以使用某些技术手段，使得三台机器分得很均匀，但是在加入一个机器，又不均匀了！

只要把这两个问题解决，那么既可以做到负载均匀，又能够轻松完成数据迁移

一个技术可以解决这两个问题！

虚拟节点机制

比如，我们给三台机器分别 分配1000个节点！

然后准备一张路由表

路由表：从真实的物理机器，去查它有哪些虚拟节点；也可从虚拟节点反查有哪些物理机器

然后我们用这3000个虚拟节点抢这个环，这些 虚拟节点各自负责的域，一律给其对应的物理机器处理

此时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射（通过路由表完成的），比如上图的查找表。当某一条数据计算出归属于 m2-1 时再根据查找表的跳转，数据将最终归属于实际的m1物理机器。

增加机器，则随之继续增加虚拟节点
一致性哈希结构，可以把数据迁移的代价，弄得很低！且可以实现负载均衡！
一致性哈希结构：几乎所有需要集群化，抗压力的，都进行了一致性哈希改造

初级6 02.03.57