这篇文章给大家介绍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乐观锁问题是什么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
