分布式缓存系统 Memcached CAS协议

Memcached在1.2.4版本后新增了CAS(Check and Set)协议，主要用于并发控制：memcached中同一个item同时被多个线程（多个客户端）更改的并发问题。CAS协议最本质的东西——版本号，即将每个item都关联一个全局唯一的编号，从而利用该唯一的编号来判断item数据在某个线程操作期间有无被其他的线程所更改（每次更改版本号都会改变，因此可作为判断的标识）。

如果不采用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中，每个key关联都一个64-bit长度的long型惟一数值，表示该key对应value的版本号。这个数值由Memcached server产生，从1开始，且同一Memcached server中不会重复。在两种情况下这个版本数值会加1：新增一个key-value对 和 对某已有key对应的value值更新成功。删除item，而版本值不会减小。

可由如下例子看出：

MemcachedClient client = new MemcachedClient();  
  client.set("fKey", "fValue");  
  //第一次set, 在Memcached server中会维护fKey对应的value的版本号，假设是548;  
  
  client.set("fKey", "sValue");  
  //再次set，则这个fKey对应的value的版本号变为549;  
  
  CASValue casValue = client.gets("fKey");  
  //这样就可以得到对应key的cas版本号和实际value(各个Memcached client都有类似的对象表示，名字可能不一样，但效果类同)，如 casValue.getValue = "sValue"，casValue.getCas=549; 

注：get命令返回给定key的value值。 而gets则会返回给定key的value和cas版本号值。如下图：

其中，先set 一次name,再gets name的返回值为：“VALUE  name 0 3 2", 然后再进行一次set name，  这时gets name的返回值为”VALUE  name 0 3 3“,最后一个字段由2变为了3，即版本号因为set更改了value值而被增加了一，而get name的返回值为”VALUE name 0 3“,与gets的返回值相比，少最后的版本号的字段。

CAS协议在并发控制中的具体应用：

一个memcached server在有多个额客户端时，分析下多个client并发set同一个key的场景。如clientA想把当前key的value set为"x"，且操作成功；clientB却把当前key的value值由"x"覆盖set为"y"，这时clientA再根据key去取value时得到"y"而不是期望的"x"，它使用这个值，但不知道这个值已经被其它线程修改过，就可能会出现问题。

而CAS协议正是用于解决这种并发修改问题。有线程试图修改当前key-value对的value时，先由gets方法得到item的版本号，操作完成提交数据时，则先比较获取的版本号与当前item key中的版本号是否一致，如果是相同的，则提交数据，完整set等更改操作。反之，如果不一致，则说明在该线程对item操作过程中，这个key-value对被其它线程更改过（当然也就更改了版本号），于是放弃此次修改(乐观锁概念)。

Memcached默认是打开cas属性的，每次执行更改操作后，存储数据时，都会生成其cas值并和item一起尝试这存储（是否存储成功，需要有版本号cas值是否一致来决定）如果操作成功则更改原版本号为该cas值，否则放弃本次操作。在进行gets操作会返回系统生成的cas值。

看下在存储item时的操作函数stor_item的相关代码：

 //为新的item生成cas值  
uint64_t get_cas_id(void)  
{  
    static uint64_t cas_id = 0;  
    return ++cas_id;  
}  
//执行cas存储时执行的判断逻辑，  
else if (ITEM_get_cas(it) == ITEM_get_cas(old_it))//版本号cas值一致  
{  
    pthread_mutex_lock(&c->thread->stats.mutex);  
    c->thread->stats.slab_stats[old_it->slabs_clsid].cas_hits++;  
    pthread_mutex_unlock(&c->thread->stats.mutex);  
  
    item_replace(old_it, it, hv);//执行存储逻辑  
    stored = STORED;  
}  
else //版本号cas值不一致，不进行实际的存储  
{  
    pthread_mutex_lock(&c->thread->stats.mutex);  
    c->thread->stats.slab_stats[old_it->slabs_clsid].cas_badval++; //更新统计信息  
    pthread_mutex_unlock(&c->thread->stats.mutex);  
  
    if (settings.verbose > 1)  
    {  
        //打印错误日志  
        fprintf(stderr, "CAS:  failure: expected %llu, got %llu\n",  
                (unsigned long long) ITEM_get_cas(old_it),  
                (unsigned long long) ITEM_get_cas(it));  
    }  
    stored = EXISTS;  
}

当因为cas值冲突，而不能完成对item的更改操作时，可以通过比如重试等方式，待没有其他线程同时来更改该item时，则能顺利完成更改操作。