couchbase的CAS乐观锁问题是什么样的

这篇文章给大家介绍couchbase的CAS乐观锁问题是什么样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

场景：同步播放记录
OPS: 30w

cas问题
CAS:Compare and Swap, 翻译成比较并交换。
java.util.concurrent包中借助CAS实现了区别于synchronized同步锁的一种乐观锁。
其原理是CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。
当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

     /**
     * Atomically sets the value to the given updated value
     * if the current value {@code ==} the expected value.
     *
     * @param expect the expected value
     * @param update the new value
     * @return {@code true} if successful. False return indicates that
     * the actual value was not equal to the expected value.
     */
    public final boolean compareAndSet(int expect, int update) {
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

在高并发的场景下，写入couchbase会引起cas问题。
即如果未使用cas，那么后写入的数据，会覆盖前面写入的数据。
如果启用的cas，那么因为同时读到了一个数据，只有第一个会写入成功，
其余的因为 compare and swap 失败，未能写入。

此处要注意，
虽然couchbase客户端的upsert方法，虽然支持cas，
但是写入的时候，如果cas错误，那么也不会抛出异常，要使用replace方法
如下面两张图所示

当我们使用正确的cas之后，需要处理cas带来的数据一致性问题，这时候，我们可以采用各自的解决方案来解决。

本人采用的是redisson的getBlockingQueue的drainTo方法，配合定时任务，实现批处理。

延伸：cas问题在服务端，如果设计的不合理会引发aba问题，
简言之
首先
X和Y同时处理数据
X先将A 改为 B
然后将B改为 A
此时Y将A改为其他值，也是成功的。
但是此时数据已经经过了A->B->A的变化

所以这时候会引用一个单独的值，来唯一区分两个值是不一样的。比如uuid等。

关于couchbase的CAS乐观锁问题是什么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。