应用场景分析：

如原来MEMCACHED中的KES的内容为A，客户端C1和客户端C2都把A取了出来，C1往准备往其中加B，C2准备往其中加C，这就会造成C1和C2执行后的CACHE KEYS要么是AB要么是AC，而不会出现我们期望的ABC。这种情况，如果不是在集群环境中，而只是单机服务器，可以通过在写CACHE KEYS时增加同步锁，就可以解决问题，可是在集群环境中，同步锁是显然解决不了问题的。

memcached是原子的吗？宏观
         所有的被发送到memcached的单个命令是完全原子的。如果您针对同一份数据同时发送了一个set命令和一个get命令，它们不会影响对方。它们将被串行化、先后执行。即使在多线程模式，所有的命令都是原子的；命令序列不是原子的。如果您通过get命令获取了一个item，修改了它，然后想把它set回memcached，我们不保证这个item没有被其他进程（process，未必是操作系统中的进程）操作过。在并发的情况下，您也可能覆写了一个被其他进程set的item。
memcached 1.2.5以及更高版本，提供了gets和cas命令，它们可以解决上面的问题。如果您使用gets命令查询某个key的item，memcached会 给您返回该item当前值的唯一标识。如果您覆写了这个item并想把它写回到memcached中，您可以通过cas命令把那个唯一标识一起发送给 memcached。如果该item存放在memcached中的唯一标识与您提供的一致，您的写操作将会成功。如果另一个进程在这期间也修改了这个 item，那么该item存放在memcached中的唯一标识将会改变，您的写操作就会失败。

微观分析

memcache为了避免一些竞争，加入了一些特殊原子操作：add cas incr decr

"add" means "store this data, but only if the server *doesn't* already；

“cas” is a check and set operation which means “store this data but only if no one else has updated since I last fetched it.” ；

它们的实现原理基于CAS（check and save）模式：

下面是一个全新的CAS模式实现：

1.预先在memcached中设置一个key值，假设为CREATKEY＝1

2.每次创建活动时，在规则校验前先get出CREATEKEY＝x；

3.进行规则校验

4.执行incr CREATEKEY操作，检验返回值是否为所期望的x＋1，如果不是，则说明在此期间有另外的进程执行了incr操作，即存在并发，放弃更新。否则

5.执行创建活动

memcached保存的key value都有一个唯一标识casUnique，在进行incr decr操作时，首先获取casUnique，执行incr，检验返回值是否casUnique+1，如果是，则更新，否则，失败不更新！

尽管这种设计在处理并发时还存在缺陷，但可以通过简单的重试来解决问题！

接口分析：

返回MemcachedItem对象：

public MemcachedItem gets(String key) {
               return client.gets(key);
          }

public MemcachedItem gets(String key, Integer hashCode) {
                   return gets(OPCODE_GET, key, hashCode, false);
         }

普通的get方法，返回Value对象

public Object get(String key) {
              return client.get(key);
         }

casUnique：是唯一标识
        public boolean cas(String key, Object value, long casUnique) {
             return client.cas(key, value, casUnique);
        }

public boolean cas(String key, Object value, long casUnique) {
               return set(OPCODE_SET, key, value, null, null, casUnique, primitiveAsString);
          }

MemcachedItem类结构：

public final class MemcachedItem {
              public long casUnique;
               public Object value;

}

其它约束：

32位无符号整数

 下面一片文章是对memcache add原子性实际应用的使用：

原文出自：http://blog.csdn.net/jiangbo_hit/article/details/6211704

引子

一个使用缓存进行并发控制的讨论，让我学习到成本与收益间的平衡，以及何为真正的可用性......

防止并发有多种方式，本文只涉及使用缓存memcached控制。

并发场景：

用例：SNS系统中具有高级会员资格的人发起活动。

业务规则：1.一个人同时只能创建一个活动。2.具有高级会员资格。

基本流程如下：

这个流程中存在明显的并发问题，当进程A校验过会员M有资格，并且为创建过活动，但为开始执行创建操作，此时另一个进程B也进行了规则判断，顺利通过，并完成创建操作，此时A继续执行，则会产生两条M的活动。（这个并发场景很简单，很普遍）

最初的解决方案：

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

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

2.执行创建活动

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

问题：

如此实现存在一些问题：

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

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

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

应对问题：

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

1.采用持久化的缓存解决方法，如TT（Tokyo Tyrant：http://fallabs.com/tokyotyrant/）

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

第一种不必解释了，很简单，原来的所有问题都是时效性惹得祸，时效性源于memcached是基于内存的，那么采用持久话存储的TT可以彻底根治这个问题。

第二种方式需要简单介绍下：

memcached中除了add操作是原子的，还有另外两个操作也是原子的：incr和decr，使用CAS模式即：

1.预先在memcached中设置一个key值，假设为CREATKEY＝1

2.每次创建活动时，在规则校验前先get出CREATEKEY＝x；

3.进行规则校验

4.执行incr CREATEKEY操作，检验返回值是否为所期望的x＋1，如果不是，则说明在此期间有另外的进程执行了incr操作，即存在并发，放弃更新。否则

5.执行创建活动

对比这两种方法，从效果上看可以发现第一种时100％可靠的，不存在问题；第二种，可能存在误判，即本来不存在并发，却被判为并发，如缓存重启，或key值失效后，incr值可能不同于期望值，导致误判。

但是从成本上考虑，TT是持久化的缓存解决方案，完美意味着高成本，我们必须维护持久化数据，而使用memcached的CAS方式，可以以几乎0成本的方式解决时效性问题，尽管存在一点小缺陷，但这种缺陷可以通过简单的重试即可解决。考虑实际的产出比，采用memcached的CAS方式更适合实际情况。

成本与收益间的平衡，做科学与做工程的区别～