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

[经验分享] MEMCACHED在集群环境下对并发更新是否保持数据一致

[复制链接]

尚未签到

发表于 2015-11-19 01:14:11 | 显示全部楼层 |阅读模式
  
    今天在和同事查找菜单数据清CACHE时为什么出问题,其中有谈到MEMCACHED在集群环境下是否会保持数据的一致性,我的印象中好像memcached是有通过版本控制来实现的,不过只是有点模糊的印象,为了查了究竟也为了解决这个问题,我查了一下资料,不过顺便在这里也把菜单系统的CACHE实现在这里YY几句,知道的就当我废话了。    菜单系统有以下几个特点:    1、从其本身上来说,是属于不经常性变化的数据,读取的频率远大于写的频率;    2、从数据量上来看,也不大,也就是数据几K到十K左右的数据;    3、访问量比较大,每天都会有上百万的访问;    4、每个用户都会有菜单数据;    5、菜单系统是属于多个系统共用。    从以上的数据变化性比较小、数据量比较小、访问量比较频繁以、高命中率、属于分布式应用,我们是将菜单数据放到了Memcached中,当然,通常使用Memcached也最好符合这几个条件,否则会起不到相应的效果。    菜单系统本身有权限限制,用户与用户之间看到的菜单是不同的,不过这个权限没有定义到人头的千人千面,是通过用户分组来实现的,用户组的菜单CACHE键是通过当前用户组所具有的权限组合出来的,因为每个用户组可以查看的菜单是确定的,目前的方式是将每个用户组的菜单分别存放到MemCached中,也避免了频繁的读取数据库以及再次验权的问题。不过这个时候产生了一个新的问题,需要将CACHE中用户组的菜单给删除,这样才能够立即展示后台菜单管理系统对菜单操作的变化效果,但是用户组的CACHE键的数量及名称是根据用户拥用的权限组合起来的,也就是CACHEKEYS的值以及数量是不确定的,并且MEMCACHED本身不支持对键的遍历,也就是我们要清除一个菜单CACHE项,首先要知道这个CACHE项的键,菜单后台管理系统是一套单独的系统,为了清理CACHE中所有的菜单数据,后台系统必须要拿到所有用户组的CACHE KEYS,因而就需要有有一个地方存放这些键,现在采取的方式,将所有存放用户组权限菜单的CACHE KEYS,单独存放到一个CACHE项中,在后台菜单和管理系统中清理菜单之前,先获取这个存放所有用户组权限菜单的CACHEKEYS,再根据这个CACHE项中存放的所有CACHE KEYS,循环删除所有的用户组权限菜单CACHE项。    这里插一句memcached的命令执行方式,所有的被发送到memcached的单个命令是完全原子的。如针对同一份数据同时发送了一个set命令和一个get命令,它们不会影响对方。它们将被串行化、先后执行。即使在多线程模式,所有的命令都是原子的,除非程序有bug:)。但是命令序列不是原子的。如果通过get命令获取了一个item,修改了它,然后想把它set回memcached,我们不保证这个item没有被其他进程(process,未必是操作系统中的进程)操作过。在并发的情况下,也可能覆写了一个被其他进程set的item。    也就是说大家都是操作的同一份存放在MEMCACHED中的CACHE KEYS,在并发的情况也会出现问题的,如原来MEMCACHED中的KES的内容为A,客户端C1和客户端C2都把A取了出来,C1往准备往其中加B,C2准备往其中加C,这就会造成C1和C2执行后的CACHE KEYS要么是AB要么是AC,而不会出现我们期望的ABC。这种情况,如果不是在集群环境中,而只是单机服务器,可以通过在写CACHE KEYS时增加同步锁,就可以解决问题,可是在集群环境中,同步锁是显然解决不了问题的。    不过,也不要悲观,出现问题时,总会有解决办法的出现,memcached 1.2.5以及更高版本,提供了gets和cas命令,它们可以解决上面的问题。如果使用gets命令查询某个key的item,memcached会返回该item当前值的唯一标识。如果覆写了这个item并想把它写回到memcached中,可以通过cas命令把那个唯一标识一起发送给 memcached。如果该item存放在memcached中的唯一标识与提供的一致,写操作将会成功。如果另一个进程在这期间也修改了这个item,那么该item存放在memcached中的唯一标识将会改变,写操作就会失败。
  本文出自:冯立彬的博客
  

  


  
         版权声明:本文为博主原创文章,未经博主允许不得转载。

运维网声明 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-140841-1-1.html 上篇帖子: [转]Linux下缓存服务器Memcached的应用 下篇帖子: Memcached源码分析之do_item_alloc操作
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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