Memcached探索(系列二)

今天探讨一下关于Memcached如何进行"分布式"应用的。

memcached虽然一直是说分布式缓存应用,但是这个分布并不是由ms(memcached server)来去实现如何分布,ms之间间并不互相通信。

所以真正实现分布式缓存是由mc(memcached client)来实现,那具体的实现算法是什么呢?

memcached的分布算法一般有两种选择：

 

一种是hash模余算法

唯一键值的哈希值与存放服务器列表中服务器(服务器地址记录不是唯一的)的数量进行模数运算来选择服务器的地址的。所以数据缓存在哪台服务器取决于缓存数据的唯一键值所产生的哈希值和存放服务器列表中服务器的数量值(也就是hash(key)% sessions.size()),所以访问memcached服务的所有客户端操作数据时都必须使用同一种哈希算法和相同的服务器列表配置，否则就会或取不到数据或者重复存取数据。由于不同数据的唯一键所对应的哈希值不同，所以不同的数据就有可能分散到不同的服务器上，达到多个服务器负载平衡的目的。

但也有其缺点。那就是当添加或移除服务器时,缓存重组的代价相当巨大。添加/删除服务器后(特别是某台服务器down机之后)，余数就会产生巨变，映射公式变成了 hash(object)%(sessions.size()-1),这样就无法保证获取时计算的服务器节点与保存时相同,这意味着突然之间几乎所有的 cache 都失效,从而影响缓存的命中率——造成原有的缓存数据将大规模失效。

 

另一种就是Consistent hashing算法

Consistent hashing算法我从网上搜索了一下,把完全的算法原理贴出来.

Consistent hashing 是一种 hash 算法，简单的说，在移除/添加一个 cache 时,它能够尽可能小的改变已存在 key 映射关系,尽可能的满足单调性的要求。

 

1、环形hashing空间

考虑通常的 hash 算法都是将 value 映射到一个 32 为的 key 值，也即是 0~2^32-1 次方的数值空间；我们可以将这个空间想象成一个首（ 0 ）尾（ 2^32-1 ）相接的圆环，如下面图 1 所示的那样。

图 1 环形 hash 空间

 

2、把对象映射到hashing空间中

接下来考虑 4 个对象 object1~object4 ，通过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。

hash(object1) = key1;

… …

hash(object4) = key4;

图 2 4 个对象的 key 值分布

 

3、把cache是映射到hashing空间中

Consistent hashing 的基本思想就是将对象和 cache 都映射到同一个 hash 数值空间中，并且使用相同的 hash 算法。

假设当前有 A,B 和 C 共 3 台 cache ，那么其映射结果将如图 3 所示，他们在 hash 空间中，以对应的 hash 值排列。

hash(cache A) = key A;

… …

hash(cache C) = key C;

图 3 cache 和对象的 key 值分布

说到这里，顺便提一下 cache 的 hash 计算，一般的方法可以使用 cache 机器的 IP 地址或者机器名作为 hash 输入。

 

4、把对象再与cache映射上

现在 cache 和对象都已经通过同一个 hash 算法映射到 hash 数值空间中了，接下来要考虑的就是如何将对象映射到 cache 上面了。

在这个环形空间中，如果沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上，因为对象和 cache 的 hash 值是固定的，因此这个 cache 必然是唯一和确定的。这样不就找到了对象和 cache 的映射方法了吗？！

依然继续上面的例子（参见图 3 ），那么根据上面的方法，对象 object1 将被存储到 cache A 上； object2 和 object3 对应到 cache C ； object4 对应到 cache B ；

 

5、考察cache的变动

前面讲过，通过 hash 然后求余的方法带来的最大问题就在于不能满足单调性，当 cache 有所变动时， cache 会失效，进而对后台服务器造成巨大的冲击，现在就来分析分析 consistent hashing 算法。

 

5.1 移除 cache

考虑假设 cache B 挂掉了，根据上面讲到的映射方法，这时受影响的将仅是那些沿 cache B 逆时针遍历直到下一个 cache （ cache C ）之间的对象，也即是本来映射到 cache B 上的那些对象。

因此这里仅需要变动对象 object4 ，将其重新映射到 cache C 上即可；参见图 4 。

图 4 Cache B 被移除后的 cache 映射

 

5.2 添加 cache

再考虑添加一台新的 cache D 的情况，假设在这个环形 hash 空间中， cache D 被映射在对象 object2 和 object3 之间。这时受影响的将仅是那些沿 cache D 逆时针遍历直到下一个 cache （ cache B ）之间的对象（它们是也本来映射到 cache C 上对象的一部分），将这些对象重新映射到 cache D 上即可。

因此这里仅需要变动对象 object2 ，将其重新映射到 cache D 上；参见图 5 。

图 5 添加 cache D 后的映射关系

 

6、虚拟节点

考量 Hash 算法的另一个指标是平衡性 (Balance) ，定义如下：

 

平衡性

平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。

hash 算法并不是保证绝对的平衡，如果 cache 较少的话，对象并不能被均匀的映射到 cache 上，比如在上面的例子中，仅部署 cache A 和 cache C 的情况下，在 4 个对象中， cache A 仅存储了 object1 ，而 cache C 则存储了 object2 、 object3 和 object4 ；分布是很不均衡的。

 

为了解决这种情况， consistent hashing 引入了“虚拟节点”的概念，它可以如下定义：

“虚拟节点”（ virtual node ）是实际节点在 hash 空间的复制品（ replica ），一实际个节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在 hash 空间中以 hash 值排列。

仍以仅部署 cache A 和 cache C 的情况为例，在图 4 中我们已经看到， cache 分布并不均匀。现在我们引入虚拟节点，并设置“复制个数”为 2 ，这就意味着一共会存在 4 个“虚拟节点”， cache A1, cache A2 代表了 cache A ； cache C1, cache C2 代表了 cache C ；假设一种比较理想的情况，参见图 6 。

图 6 引入"虚拟节点"后的映射关系

 

此时，对象到"虚拟节点"的映射关系为：

objec1->cache A2 ； objec2->cache A1 ； objec3->cache C1 ； objec4->cache C2;

因此对象 object1 和 object2 都被映射到了 cache A 上，而 object3 和 object4 映射到了 cache C 上；平衡性有了很大提高。

引入“虚拟节点”后，映射关系就从 { 对象 -> 节点 } 转换到了 { 对象 -> 虚拟节点 } 。查询物体所在 cache 时的映射关系如图 7 所示。

图 7 查询对象所在 cache

 

"虚拟节点"的 hash 计算可以采用对应节点的 IP 地址加数字后缀的方式。例如假设 cache A 的 IP 地址为 202.168.14.241 。

引入"虚拟节点"前，计算 cache A 的 hash 值：

Hash(“202.168.14.241”);

引入"虚拟节点"后，计算"虚拟节点" cache A1 和 cache A2 的 hash 值：

Hash("202.168.14.241#1"); // cache A1

Hash("202.168.14.241#2"); // cache A2

 

上面的Consistent hashing算法的原理已经贴出来了;在上一篇中曾经列举了.Net平台下的几种Memcached的客户端

其中memcacheddotnet这个还是使用求余算法.

enyim.Caching这个对分布式算法进行了优化,已支持consistent hashing算法.

而MemcachedProviders是对Enyim.Caching的再次封装.

后面我们将会详细的讲一下上面enyim.Caching和MemcachedProviders的客户端具体代码和使用.

 

 

 

转载于:https://www.cnblogs.com/tangzhenjie/p/3243342.html