现在的位置: 首页 > 综合 > 正文

MEMCACHED在集群环境下对并发更新是否保持数据一致

2013年10月13日 ⁄ 综合 ⁄ 共 1782字 ⁄ 字号 评论关闭
    今天在和同事查找菜单数据清CACHE时为什么出问题,其中有谈到MEMCACHED在集群环境下是否会保持数据的一致性,我的印象中好像memcached是有通过版本控制来实现的,不过只是有点模糊的印象,为了查了究竟也为了解决这个问题,我查了一下资料,不过顺便在这里也把菜单系统的CACHE实现在这里YY几句,知道的就当我废话了。
    菜单系统有以下几个特点:
    1、从其本身上来说,是属于不经常性变化的数据,读取的频率远大于写的频率;
    2、从数据量上来看,也不大,也就是数据几K到十K左右的数据;
    3、访问量比较大,每天都会有上百万的访问;
    4、每个用户都会有菜单数据;
    5、菜单系统是属于多个系统共用。
    从以上的数据变化性比较小、数据量比较小、访问量比较频繁以、高命中率、属于分布式应用,我们是将菜单数据放到了Memcached中,当然,通常使用Memcached也最好符合这几个条件,否则会起不到相应的效果。
    菜单系统本身有权限限制,用户与用户之间看到的菜单是不同的,不过这个权限没有定义到人头的千人千面,是通过用户分组来实现的,用户组的菜单CACHE键是通过当前用户组所具有的权限组合出来的,因为每个用户组可以查看的菜单是确定的,目前的方式是将每个用户组的菜单分别存放到MemCached中,也避免了频繁的读取数据库以及再次验权的问题。不过这个时候产生了一个新的问题,需要将CACHE中用户组的菜单给删除,这样才能够立即展示后台菜单管理系统对菜单操作的变化效果,但是用户组的CACHE键的数量及名称是根据用户拥用的权限组合起来的,也就是CACHE
KEYS的值以及数量是不确定的,并且MEMCACHED本身不支持对键的遍历,也就是我们要清除一个菜单CACHE项,首先要知道这个CACHE项的键,菜单后台管理系统是一套单独的系统,为了清理CACHE中所有的菜单数据,后台系统必须要拿到所有用户组的CACHE KEYS,因而就需要有有一个地方存放这些键,现在采取的方式,将所有存放用户组权限菜单的CACHE KEYS,单独存放到一个CACHE项中,在后台菜单和管理系统中清理菜单之前,先获取这个存放所有用户组权限菜单的CACHE
KEYS,再根据这个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中的唯一标识将会改变,写操作就会失败。

本文出自:冯立彬的博客

抱歉!评论已关闭.