设为首页 收藏本站
查看: 1720|回复: 0

[经验分享] Memcached探索(系列二)

[复制链接]

尚未签到

发表于 2015-9-1 13:35:40 | 显示全部楼层 |阅读模式
  今天探讨一下关于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 所示的那样。
   DSC0000.jpg
  图 1 环形 hash 空间
  
  
  2、把对象映射到hashing空间中
  接下来考虑 4 个对象 object1~object4 ,通过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。
  hash(object1) = key1;
  … …
  hash(object4) = key4;
   DSC0001.jpg
  图 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;
   DSC0002.jpg
  图 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 。
   DSC0003.jpg
  图 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 。
   DSC0004.jpg
  图 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 。
   DSC0005.jpg
  图 6 引入"虚拟节点"后的映射关系
  
  
  此时,对象到"虚拟节点"的映射关系为:
  objec1->cache A2 ; objec2->cache A1 ; objec3->cache C1 ; objec4->cache C2;
  因此对象 object1 和 object2 都被映射到了 cache A 上,而 object3 和 object4 映射到了 cache C 上;平衡性有了很大提高。
  引入“虚拟节点”后,映射关系就从 { 对象 -> 节点 } 转换到了 { 对象 -> 虚拟节点 } 。查询物体所在 cache 时的映射关系如图 7 所示。
   DSC0006.jpg
  图 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的客户端具体代码和使用.
  
  
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-108396-1-1.html 上篇帖子: Memcached使用文档安装软件及例子 下篇帖子: .NET平台上的Memcached客户端介绍
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表