memcached CAS

memcached的锁机制

 

最近笔者自己的项目中，遇到了乐观锁的需求。但是redis没有这个操作，无奈，看了memcache天然的支持这种并发原语，即：GETS和CAS操作。因此准备打算继续使用REDIS，业务没有那么强的时序执行要求，因此可以使用没有CAS的算法在某种程度上解决。 

    我们为什么要使用这种并发原语呢？如果是单机版的，我们可以通过通过加锁同步就可以解决执行时序的问题。但是我们的应用是分布式的，无状态的应用服务器通过负载均衡，部署到了多台。加锁也解决不了多台服务器的时序执行。 

    如果不采用CAS，则有如下的情景： 
第一步，A取出数据对象X； 
第二步，B取出数据对象X； 
第三步，B修改数据对象X，并将其放入缓存； 
第四步，A修改数据对象X，并将其放入缓存。 
我们可以发现，第四步中会产生数据写入冲突。 

    如果采用CAS协议，则是如下的情景。 
第一步，A取出数据对象X，并获取到CAS-ID1； 
第二步，B取出数据对象X，并获取到CAS-ID2； 
第三步，B修改数据对象X，在写入缓存前，检查CAS-ID与缓存空间中该数据的CAS-ID是否一致。结果是“一致”，就将修改后的带有CAS-ID2的X写入到缓存。 
第四步，A修改数据对象Y，在写入缓存前，检查CAS-ID与缓存空间中该数据的CAS-ID是否一致。结果是“不一致”，则拒绝写入，返回存储失败。 
我们可以通过重试，或者其他业务逻辑解决第四步设置失败的问题。 

Memcached于1.2.4版本新增CAS(Check and Set)协议类同于Java并发的CAS(Compare and Swap)原子操作，处理同一item被多个线程更改过程的并发问题。 
在Memcached中，每个key关联有一个64-bit长度的long型惟一数值，表示该key对应value的版本号。这个数值由Memcached server产生，从1开始，且同一Memcached server不会重复。在两种情况下这个版本数值会加1：1、新增一个key-value对；2、对某已有key对应的value值更新成功。删除item版本值不会减小。