couchbase的CAS樂觀鎖問題是什么樣的

這篇文章給大家介紹couchbase的CAS樂觀鎖問題是什么樣的，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

場景：同步播放記錄
OPS: 30w

cas問題
CAS:Compare and Swap, 翻譯成比較并交換。
java.util.concurrent包中借助CAS實現(xiàn)了區(qū)別于synchronized同步鎖的一種樂觀鎖。
其原理是CAS有3個操作數(shù)，內(nèi)存值V，舊的預(yù)期值A(chǔ)，要修改的新值B。
當且僅當預(yù)期值A(chǔ)和內(nèi)存值V相同時，將內(nèi)存值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);
    }

在高并發(fā)的場景下，寫入couchbase會引起cas問題。
即如果未使用cas，那么后寫入的數(shù)據(jù)，會覆蓋前面寫入的數(shù)據(jù)。
如果啟用的cas，那么因為同時讀到了一個數(shù)據(jù)，只有第一個會寫入成功，
其余的因為 compare and swap 失敗，未能寫入。

此處要注意，
雖然couchbase客戶端的upsert方法，雖然支持cas，
但是寫入的時候，如果cas錯誤，那么也不會拋出異常，要使用replace方法
如下面兩張圖所示

當我們使用正確的cas之后，需要處理cas帶來的數(shù)據(jù)一致性問題，這時候，我們可以采用各自的解決方案來解決。

本人采用的是redisson的getBlockingQueue的drainTo方法，配合定時任務(wù)，實現(xiàn)批處理。

延伸：cas問題在服務(wù)端，如果設(shè)計的不合理會引發(fā)aba問題，
簡言之
首先
X和Y同時處理數(shù)據(jù)
X先將A 改為 B
然后將B改為 A
此時Y將A改為其他值，也是成功的。
但是此時數(shù)據(jù)已經(jīng)經(jīng)過了A->B->A的變化

所以這時候會引用一個單獨的值，來唯一區(qū)分兩個值是不一樣的。比如uuid等。

關(guān)于couchbase的CAS樂觀鎖問題是什么樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。