Memcached的CAS机制的实现

Memcached的CAS机制解决的问题及其原理：

1. 实现了Check-and-Set原子操作功能；
2. 其使用方式为：首先使用gets指令一个key-value及key对应value的版本号；其次操作产生新的value值；最后使用cas指令重新提交key-value，并附带刚刚获得到的版本号；
3. 当服务端判断cas操作中的版本号不是最新的时，则认为改key的值已经被修改，本次cas操作失败。程序设计人员通过CAS机制可实现自增和自减的原子操作；

Memcached的CAS机制的实现：

1. Memcached CAS的核心是一个64-bit唯一的版本。服务端会为每个key生成一个64-bit唯一的整数值作为版本号，并保存在item结构体中，具体的存储结构见结构体item的定义：

typedef struct _stritem {
    struct _stritem *next;
    struct _stritem *prev;
    struct _stritem *h_next;    /* hash chain next */
    rel_time_t      time;       /* least recent access */
    rel_time_t      exptime;    /* expire time */
    int             nbytes;     /* size of data */
    unsigned short  refcount;
    uint8_t         nsuffix;    /* length of flags-and-length string */
    uint8_t         it_flags;   /* ITEM_* above */
    uint8_t         slabs_clsid;/* which slab class we're in */
    uint8_t         nkey;       /* key length, w/terminating null and padding */
    /* this odd type prevents type-punning issues when we do
     * the little shuffle to save space when not using CAS. */
    union {
        uint64_t cas;
        char end;
    } data[];
    /* if it_flags & ITEM_CAS we have 8 bytes CAS */
    /* then null-terminated key */
    /* then " flags length\r\n" (no terminating null) */
    /* then data with terminating \r\n (no terminating null; it's binary!) */
} item;

cas的版本号的值存储在item中key之前的位置处。

2. Memcached CAS的开启和关闭由settings.use_cas选项来控制。结构体struct settings存储了Memcached服务器的各种选项存储，其定义的代码如下：

struct settings {
    size_t maxbytes;
    int maxconns;
    int port;
    int udpport;
    char *inter;
    int verbose;
    rel_time_t oldest_live; /* ignore existing items older than this */
    int evict_to_free;
    char *socketpath;   /* path to unix socket if using local socket */
    int access;  /* access mask (a la chmod) for unix domain socket */
    double factor;          /* chunk size growth factor */
    int chunk_size;
    int num_threads;        /* number of worker (without dispatcher) libevent threads to run */
    int num_threads_per_udp; /* number of worker threads serving each udp socket */
    char prefix_delimiter;  /* character that marks a key prefix (for stats) */
    int detail_enabled;     /* nonzero if we're collecting detailed stats */
    int reqs_per_event;     /* Maximum number of io to process on each
                               io-event. */
    bool use_cas;
    enum protocol binding_protocol;
    int backlog;
    int item_size_max;        /* Maximum item size, and upper end for slabs */
    bool sasl;              /* SASL on/off */
    bool maxconns_fast;     /* Whether or not to early close connections */
    bool slab_reassign;     /* Whether or not slab reassignment is allowed */
    bool slab_automove;     /* Whether or not to automatically move slabs */
    int hashpower_init;     /* Starting hash power level */
};

默认情况下settings.use_cas的值为true，在settings_init调用的时候进行初始化设置：

static void settings_init(void) {
    settings.use_cas = true;
    ... ...
}

当启动Memcached服务时，如果指定了-C选项，则关闭cas机制，改部分代码在main函数中：

int main (int argc, char **argv) {
    ... ...
        case 'C' :
            settings.use_cas = false;
            break;
    ... ...
}

3. Memcached在分配item的内存时会根据是否开启settings.use_cas选项来分配内存和设置item->flags：

item *do_item_alloc(char *key, const size_t nkey, const int flags, const rel_time_t exptime, const int nbytes) {
    ... ...
    if (settings.use_cas) {
        ntotal += sizeof(uint64_t);
    }
    ... ...
    it->it_flags = settings.use_cas ? ITEM_CAS : 0;
    ... ...
｝

4. Memcached CAS机制的相关实现：

在Memcached中，所有的命令处理逻辑在process_command中实现，该函数的实现根据不同的命令又细分为不同的处理函数。

gets指令调用process_get_command，该函数当最后的参数为true时，代表处理带cas的get操作，会在response中包含cas的值。

cas指令调用process_update_command，该函数当最后的参数true代表，处理带cas的update操作，最终会调用do_store_item函数来处理update操作。相关的cas的逻辑代码有：

        /* validate cas operation */
        if(old_it == NULL) {
            // LRU expired
            stored = NOT_FOUND;
            pthread_mutex_lock(&c->thread->stats.mutex);
            c->thread->stats.cas_misses++;
            pthread_mutex_unlock(&c->thread->stats.mutex);
        }
        else if (ITEM_get_cas(it) == ITEM_get_cas(old_it)) {
            // cas validates
            // it and old_it may belong to different classes.
            // I'm updating the stats for the one that's getting pushed out
            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 {
            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指令的cas版本值的递增在do_item_link函数中完成：

int do_item_link(item *it, const uint32_t hv) {
    ... ...
    /* Allocate a new CAS ID on link. */
    ITEM_set_cas(it, (settings.use_cas) ? get_cas_id() : 0);
    ... ...
}

5. 其它：
除了显式的gets和cas操作为，incr/decr操作也会使用cas机制；
append/prepend操作也会涉及到cas的相关操作；

 

 

最近笔者自己的项目中，遇到了乐观锁的需求。memcache天然的支持这种并发原语，即：GETS和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是否一致。结果是“不一致”，则拒绝写入，返回存储失败。

我们可以通过重试，或者其他业务逻辑解决第四步设置失败的问题。

没有CAS的方案

if (memcache.get(key) == null) {
  // 3 min timeout to avoid mutex holder crash
  if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
    value = db.get(key);
    memcache.set(key, value);
    memcache.delete(key_mutex);
  } else {
    sleep(50);
    retry();
  }
}

最初的解决方案：

利用memcached的add操作的原子性来控制并发，具体方式如下：

1.申请锁：在校验是否创建过活动前，执行add操作key为key，如果add操作失败，则表示有另外的进程在并发的为该key创建活动，返回创建失败。否则表示无并发

2.执行创建活动

3.释放锁：创建活动完成后，执行delete操作，删除该key。

问题：

1.memcached中存放的值有有效期，即过期后自动失效，如add过M1后，M1失效，可以在此add成功

2.即使通过配置，可以使memcached永久有效，即不设有效期，memcached有容量限制，当容量不够后会进行自动替换，即有可能add过M1后，M1被其他key值置换掉，则再次add可以成功。

3.此外，memcached是基于内存的，掉电后数据会全部丢失，导致重启后所有memberId均可重新add。

解决方案

针对上述的几个问题，根本原因是add操作有时效性，过期，被替换，重启，都会是原来的add操作失效。解决该问题有方法

1.减轻时效性的影响，使用memcached CAS（check and set）方式。

使用CAS的方案

CAS的基本原理

基本原理非常简单，一言以蔽之，就是“版本号”。每个存储的数据对象，多有一个版本号。我们可以从下面的例子来理解：

package com.home.phl;

import net.rubyeye.xmemcached.CASOperation;
import net.rubyeye.xmemcached.GetsResponse;
import net.rubyeye.xmemcached.MemcachedClient;
import net.rubyeye.xmemcached.MemcachedClientBuilder;
import net.rubyeye.xmemcached.XMemcachedClientBuilder;
import net.rubyeye.xmemcached.command.BinaryCommandFactory;
import net.rubyeye.xmemcached.utils.AddrUtil;

/**
 * 参考文章
 * @author piaohailin
 * @date   2014-6-28
*/
public class TestCAS {

  public static void main(String[] args) throws Exception {
    MemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil.getAddresses("192.168.56.3:11211"));
    builder.setCommandFactory(new BinaryCommandFactory());
    MemcachedClient memcachedClient = builder.build();
    memcachedClient.set("key", 0, value);
    final GetsResponse<Object> response = memcachedClient.gets("key");
    System.out.println(response.getValue());
    System.out.println(response.getCas());
    boolean flag = memcachedClient.cas("key", new CASOperation<Object>() {
      @Override
      public int getMaxTries() {
        return 3;
      }

      @Override
      public Object getNewValue(long currentCAS,
                     Object currentValue) {
        if (currentCAS != response.getCas()) {
          throw new RuntimeException("CAS不对");
        }
        value = db.get(key);
        return value;
      }
    });
    System.out.println(flag);
    memcachedClient.shutdown();
  }
}