1.併發問題

例如，一個操作是修改用戶的賬戶的狀態。修改前需要先讀取，在記憶體里修改，修改完了，再存進去。

如果這樣的操作同時進行，就會出現併發問題，因為“讀取”和“保持”（設置）這兩個操作不是原子操作。

原子操作是指不會被線程調度機制打斷的操作。這種操作一旦開始，就會一直運行到結束，中間不會有任何線程切換。

2.分散式鎖的奧義

分散式鎖要實現的最終目標就是在redis裡面占一個“坑”，當別的進程也要來占“坑”時，發現那裡已經有一個“大蘿蔔”了，就智能放棄或者稍後再試。

占坑一般使用setnx指令，指允許被一個客戶端占坑。先來先占，用完了，再調用del指令釋放“坑”。

3.占坑指令--SETNX

setnx key value

將key的值設為value，當且僅當key不存在。

若給定的key已經存在，則SETNX不做任何動作。

SETNX是【SET if NOT eXists】(如果不存在，則SET)的縮寫。

 4. 示例

//這裡的冒號“：”就是一個普通的字元，沒特殊含義，它可以是其它任意字元。
> setnx lock:codehole true
OK
... do something critical ...
> del lock:codehole
(integer) 1

5.優化1--添加過期時間

待優化的地方：如果邏輯執行到中間出現了問題，可能會導致del指令沒有被調用，這樣就會陷入死鎖，鎖永遠等不到釋放。

優化思路; 在拿到鎖之後，再給鎖加上一個過期時間，比如2s,這樣即使中間出現了異常，也可以保證2s之後，鎖會自動釋放。

> setnx lock:codehole true
OK
> expire lock:codehole 2
... do something critical ...
> del lock:codehole
(integer) 1

6. 繼續優化2--過期時間的設置

上面的code，邏輯上還有問題：如果在setnx 和 expire 之間伺服器進程突然掛掉了，可能是因為機器掉電或者是人為造成的，這就會導致expire得不到執行，也會造成死鎖。

這種問題的根源在於setnx和expire是兩條指令而不是原子指令。

如果這兩條指令可以一起執行就不會出現問題，也許你會想到用redis事務來解決，但在這裡不行，因為expire是依賴setnx的執行結果，如果setnx沒搶到鎖，expire是不應該執行的。事務里沒有if-else分支邏輯，事務的特點是一口氣執行，要麼全部執行，要麼一個都不執行。

Redis 2.8 版本之後，set指令進行了參數擴展，使setnx 和 expire指令可以一起執行。

> setnx lock:codehole true ex 5 nx
OK
... do something critical ...
> del lock:codehole

7. 繼續優化3--鎖名稱的設置

Redis的分散式鎖不能解決超時問題，如果在加鎖和釋放鎖之間的邏輯執行得太長，以至於超出了鎖的限時限制，就會出現問題。

因為這時候第一個線程持有的鎖過期了，但臨界區的邏輯（腳本）還沒執行完，而同時第二個線程就提前重新持有了這把鎖，導致臨界區代碼不能得到嚴格的串列執行。

出問題的關鍵點：在於釋放鎖/刪除鎖時，容易把別人添加的鎖釋放掉。優化的思路，就是在釋放鎖的時候，判斷下，是不是自己之前添加的鎖。

例如，針對每一個請求，生成一個基於clientid（或者UUID.randomUUID().toString()）的value。

即將set指令的value參數設置為一個隨機數，釋放時，先匹配隨機數釋放一致，然後再刪除。

這是為了確保當前線程占有的鎖不會被其它線程釋放，除非這個鎖是因為過期了而被伺服器自動釋放。

tag = random.nextint()   ##隨機數
if redis.set(key, tag, nx=True, ex=5):
   do_something()
   redis.delifequals(key,tag)  ##抽象的功能代碼

但是匹配value和刪除key不是一個原子操作，redis也沒有提供類似的delifequals這樣的指令，需要使用Lua腳本處理（Lua腳本可以保證連續多個指令的原子性執行）

# delifequals
if redis.call("get",KEYS[1]) == ARGV[1] then
   return redis.call("del",KEYS[1])
else
   return 0
end

但這也不是一個完美的方案，它只是相對安全一點，因為如果真的超時了，當前線程的邏輯沒有執行完，其它線程的邏輯也會乘虛而入。

8. 繼續優化4--鎖續期

redis鎖的過期時間能夠自動續期。

使用redis客戶端redisson。redisson在加鎖成功後，會註冊一個定時任務監聽這個鎖，每隔10秒就去查看這個鎖，如果還持有鎖，就對過期時間進行續期。預設過期時間30秒。

舉例子：假如加鎖的時間是30秒，過10秒檢查一次，一旦加鎖的業務沒有執行完，就會進行一次續期，把鎖的過期時間再次重置成30秒。

1. 加鎖成功後，啟動一個定時任務，每個一段時間檢測是否執行完成業務代碼，依據是鎖是否還存在。

2. 這個定時任務每隔三分之一時間檢查一次，比如鎖過期時間是30秒，就每隔10秒檢查一次。

3. 如果鎖還存在，就把鎖過期時間繼續設置成30秒。

Redisson框架已經實現了這個流程，名叫看門狗機制（Watch Dog），底層使用 Lua 腳本實現。

// 獲取 Redisson 鎖
RLock lock = redissonClient.getLock(lock_key);
try {
    // 加鎖，並設置3秒後過期
    lock.lock(3, TimeUnit.SECONDS);
    // 執行業務代碼
    doBusiness();
} catch (Exception e) {
    System.out.println("加鎖超時");
} finally {
    // 釋放鎖
    lock.unlock();
}

Redisson分散式鎖實現原理

學習參閱聲明

1.《Redis深度歷險--核心原理與應用實踐》

2. 《Redis分散式鎖如何實現續期》 https://www.jb51.net/article/233992.htm

3. 《高併發必備，使用Redis分散式鎖必須註意的10個細節》https://zhuanlan.zhihu.com/p/647085067

4. 【從原理到實戰（2023最新版）】 https://www.bilibili.com/video/BV1Gs4y1Q7Ls?p=6&vd_source=0e347fbc6c2b049143afaa5a15abfc1c