ketama开源库-一致性Hash的处理

Ketama的作者是Richard Jones，他的主页是

☆ 作者主页： http://www.metabrew.com/article/libketama-consistent-hashing-algo-memcached-clients

需要了解一下这个第三方库的使用，库下载页面是

☆ 库下载引用页： https://github.com/RJ/ketama

（1）一般Hash函数（取余）的局限性
假设有三台服务器：Node1、Node2、Node3，共有1~12共计12个数字要散列到这三台服务器，采用一般的取余操作会得到：
Node1：1, 4, 7, 10
Node2：2, 5, 8, 11
Node3：3, 6, 9, 12
看出散列效果不错，达到了良好的负载均衡的目的；但此时，op同学们希望能够添置一台新的服务器Node4，那么新的取余操作会得到：
Node1：1, 5, 9
Node2：2, 6, 10
Node3：3, 7, 11
Node4：4, 8, 12
添加节点后键分散到的服务器会发生巨大变化，12个数字只有1, 2, 3在原来的服务器上，其它的全部都移到了其它服务器。类似的，在删除节点的时候也会出现此类情况。

（2）一致性Hash的处理方法
一致性Hash的处理方法如下所示：实现求出服务器（节点）的Hash值，并将其配置到0~232的圆上。然后用同样的方法求出存储数据的键的Hash值，并映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到第一个服务器上。如果超过232仍然找不到服务器，就保存到第一台服务器上。
 



从上图的状态中添加一台memcached服务器。余数分布式算法由于保存键的服务器会发生巨大变化而影响缓存的命中率，但Consistent Hashing中，只有在continuum上增加服务器的地点逆时针方向的第一台服务器上的键会受到影响。



因此，Consistent Hashing最大限度地抑制了键的重新分布。而且，有的Consistent Hashing的实现方法还采用了虚拟节点的思想。使用一般的hash函数的话，服务器的映射地点的分布非常不均匀。因此，使用虚拟节点的思想，为每个物理节点（服务器）在continuum上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。