memcached CAS-CSDN博客

本文链接：https://blog.csdn.net/qq_15457239/article/details/48442917

本文探讨了Memcached中用于解决并发写入冲突的CAS机制。在分布式环境下，通过GETS和CAS操作确保数据的一致性，避免多服务器间的时序执行问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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版本值不会减小。