Redis 分散式鎖進化史
按：系統架構經過多年演進，現在越來越多的系統採用微服務架構，而說到微服務架構必然牽涉到分散式，以前單體應用加鎖是很簡單的，但現在分散式系統下加鎖就比較難了，我之前曾簡單寫過一篇文章，關於分散式鎖的實現，但有一次發現實現的分散式鎖是有問題的，因為出問題的概率很低，所以當時也沒在意，前幾天和朋友聊這個問題，想起來看過一篇文章，寫的不錯，今天特轉載過來，希望能讓更多的人看到，同時也加深一下記憶。原文連結是：http://tech.dianwoda.com/2018/04/11/redisfen-bu-shi-suo-jin-hua-shi/
以下為原文：
近兩年來微服務變得越來越熱門，越來越多的應用部署在分散式環境中，在分散式環境中，資料一致性是一直以來需要關注並且去解決的問題，分散式鎖也就成為了一種廣泛使用的技術，常用的分散式實現方式為Redis，Zookeeper，其中基於Redis的分散式鎖的使用更加廣泛。
但是在工作和網路上看到過各個版本的Redis分散式鎖實現，每種實現都有一些不嚴謹的地方，甚至有可能是錯誤的實現，包括在程式碼中，如果不能正確的使用分散式鎖，可能造成嚴重的生產環境故障，本文主要對目前遇到的各種分散式鎖以及其缺陷做了一個整理，並對如何選擇合適的Redis分散式鎖給出建議。
一. 各個版本的Redis分散式鎖
1. V1.0
tryLock() {
SETNX Key 1
EXPIRE Key Seconds
}
release() {
DELETE Key
}
這個版本應該是最簡單的版本，也是出現頻率很高的一個版本，首先給鎖加一個過期時間操作是為了避免應用在服務重啟或者異常導致鎖無法釋放後，不會出現鎖一直無法被釋放的情況。
這個方案的一個問題在於每次提交一個Redis請求，如果執行完第一條命令後應用異常或者重啟，鎖將無法過期，一種改善方案就是使用Lua指令碼（包含SETNX和EXPIRE兩條命令），但是如果Redis僅執行了一條命令後crash或者發生主從切換，依然會出現鎖沒有過期時間，最終導致無法釋放。
另外一個問題在於，很多同學在釋放分散式鎖的過程中，無論鎖是否獲取成功，都在finally中釋放鎖，這樣是一個鎖的錯誤使用，這個問題將在後續的V3.0版本中解決。
針對鎖無法釋放問題的一個解決方案基於GETSET命令來實現
2. V1.1 基於GETSET
tryLock() {
NewExpireTime = CurrentTimestamp + ExpireSeconds
if (SETNX Key NewExpireTime Seconds) {
oldExpireTime = GET(Key)
if (oldExpireTime < CurrentTimestamp) {
NewExpireTime = CurrentTimestamp+ExpireSeconds
CurrentExpireTime = GETSET(Key,NewExpireTime)
if (CurrentExpireTime == oldExpireTime) {
return 1;
} else {
return 0;
}
}
}
}
release() {
DELETE key
}
思路：
1. SETNX(Key,ExpireTime)獲取鎖
2. 如果獲取鎖失敗，通過GET(Key)返回的時間戳檢查鎖是否已經過期
3. GETSET(Key,ExpireTime)修改Value為NewExpireTime
4. 檢查GETSET返回的舊值，如果等於GET返回的值，則認為獲取鎖成功
注意：這個版本去掉了EXPIRE命令，改為通過Value時間戳值來判斷過期
問題：
1. 在鎖競爭較高的情況下，會出現Value不斷被覆蓋，但是沒有一個Client獲取到鎖
2. 在獲取鎖的過程中不斷的修改原有鎖的資料，設想一種場景C1，C2競爭鎖，C1獲取到了鎖，C2鎖執行了GETSET操作修改了C1鎖的過期時間，如果C1沒有正確釋放鎖，鎖的過期時間被延長，其它Client需要等待更久的時間
3. V2.0 基於SETNX
tryLock() {
SETNX Key 1 Seconds
}
release() {
DELETE Key
}
Redis 2.6.12版本後SETNX增加過期時間引數，這樣就解決了兩條命令無法保證原子性的問題。但是設想下面一個場景：
C1成功獲取到了鎖，之後C1因為GC進入等待或者未知原因導致任務執行過長，最後在鎖失效前C1沒有主動釋放鎖 2. C2在C1的鎖超時後獲取到鎖，並且開始執行，這個時候C1和C2都同時在執行，會因重複執行造成資料不一致等未知情況 3. C1如果先執行完畢，則會釋放C2的鎖，此時可能導致另外一個C3程序獲取到了鎖
大致的流程圖
存在問題：
1. 由於C1的停頓導致C1 和C2同都獲得了鎖並且同時在執行，在業務實現間接要求必須保證冪等性
2. C1釋放了不屬於C1的鎖
4. V3.0
tryLock() {
SETNX Key UnixTimestamp Seconds
}
release() {
EVAL (
//LuaScript
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
)
}
這個方案通過指定Value為時間戳，並在釋放鎖的時候檢查鎖的Value是否為獲取鎖的Value，避免了V2.0版本中提到的C1釋放了C2持有的鎖的問題；另外在釋放鎖的時候因為涉及到多個Redis操作，並且考慮到Check And Set 模型的併發問題，所以使用Lua指令碼來避免併發問題。
存在問題：
如果在併發極高的場景下，比如搶紅包場景，可能存在UnixTimestamp重複問題，另外由於不能保證分散式環境下的物理時鐘一致性，也可能存在UnixTimestamp重複問題，只不過極少情況下會遇到。
5. V3.1
tryLock() {
SET Key UniqId Seconds
}
release() {
EVAL (
//LuaScript
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
)
}
Redis 2.6.12後SET同樣提供了一個NX引數，等同於SETNX命令，官方文件上提醒後面的版本有可能去掉SETNX, SETEX, PSETEX,並用SET命令代替，另外一個優化是使用一個自增的唯一UniqId代替時間戳來規避V3.0提到的時鐘問題。
這個方案是目前最優的分散式鎖方案，但是如果在Redis叢集環境下依然存在問題：
由於Redis叢集資料同步為非同步，假設在Master節點獲取到鎖後未完成資料同步情況下Master節點crash，此時在新的Master節點依然可以獲取鎖，所以多個Client同時獲取到了鎖
二. 分散式Redis鎖：Redlock
V3.1的版本僅在單例項的場景下是安全的，針對如何實現分散式Redis的鎖，國外的分散式專家有過激烈的討論， antirez提出了分散式鎖演算法Redlock，在distlock話題下可以看到對Redlock的詳細說明，下面是Redlock演算法的一箇中文說明（引用）
假設有N個獨立的Redis節點
1. 獲取當前時間（毫秒數）。
2. 按順序依次向N個Redis節點執行獲取鎖的操作。這個獲取操作跟前面基於單Redis節點的獲取鎖的過程相同，包含隨機字串my_random_value，也包含過期時間(比如PX 30000，即鎖的有效時間)。為了保證在某個Redis節點不可用的時候演算法能夠繼續執行，這個獲取鎖的操作還有一個超時時間(time out)，它要遠小於鎖的有效時間（幾十毫秒量級）。客戶端在向某個Redis節點獲取鎖失敗以後，應該立即嘗試下一個Redis節點。這裡的失敗，應該包含任何型別的失敗，比如該Redis節點不可用，或者該Redis節點上的鎖已經被其它客戶端持有（注：Redlock原文中這裡只提到了Redis節點不可用的情況，但也應該包含其它的失敗情況）。
3. 計算整個獲取鎖的過程總共消耗了多長時間，計算方法是用當前時間減去第1步記錄的時間。如果客戶端從大多數Redis節點（>= N/2+1）成功獲取到了鎖，並且獲取鎖總共消耗的時間沒有超過鎖的有效時間(lock validity time)，那麼這時客戶端才認為最終獲取鎖成功；否則，認為最終獲取鎖失敗。
4. 如果最終獲取鎖成功了，那麼這個鎖的有效時間應該重新計算，它等於最初的鎖的有效時間減去第3步計算出來的獲取鎖消耗的時間。
5. 如果最終獲取鎖失敗了（可能由於獲取到鎖的Redis節點個數少於N/2+1，或者整個獲取鎖的過程消耗的時間超過了鎖的最初有效時間），那麼客戶端應該立即向所有Redis節點發起釋放鎖的操作（即前面介紹的Redis Lua指令碼）。
6. 釋放鎖：對所有的Redis節點發起釋放鎖操作
然而Martin Kleppmann針對這個演算法提出了質疑，提出應該基於fencing token機制（每次對資源進行操作都需要進行token驗證）
1. Redlock在系統模型上尤其是在分散式時鐘一致性問題上提出了假設，實際場景下存在時鐘不一致和時鐘跳躍問題，而Redlock恰恰是基於timing的分散式鎖
2. 另外Redlock由於是基於自動過期機制，依然沒有解決長時間的gc pause等問題帶來的鎖自動失效，從而帶來的安全性問題。
接著antirez又回覆了Martin Kleppmann的質疑，給出了過期機制的合理性，以及實際場景中如果出現停頓問題導致多個Client同時訪問資源的情況下如何處理。
針對Redlock的問題，基於Redis的分散式鎖到底安全嗎給出了詳細的中文說明，並對Redlock演算法存在的問題提出了分析。
總結
不論是基於SETNX版本的Redis單例項分散式鎖，還是Redlock分散式鎖，都是為了保證下特性
1. 安全性：在同一時間不允許多個Client同時持有鎖
2. 活性
死鎖：鎖最終應該能夠被釋放，即使Client端crash或者出現網路分割槽（通常基於超時機制）
容錯性：只要超過半數Redis節點可用，鎖都能被正確獲取和釋放
所以在開發或者使用分散式鎖的過程中要保證安全性和活性，避免出現不可預測的結果。
另外每個版本的分散式鎖都存在一些問題，在鎖的使用上要針對鎖的實用場景選擇合適的鎖，通常情況下鎖的使用場景包括：
Efficiency(效率)：只需要一個Client來完成操作，不需要重複執行，這是一個對寬鬆的分散式鎖，只需要保證鎖的活性即可；
Correctness(正確性)：多個Client保證嚴格的互斥性，不允許出現同時持有鎖或者對同時操作同一資源，這種場景下需要在鎖的選擇和使用上更加嚴格，同時在業務程式碼上儘量做到冪等
在Redis分散式鎖的實現上還有很多問題等待解決，我們需要認識到這些問題並清楚如何正確實現一個Redis 分散式鎖，然後在工作中合理的選擇和正確的使用分散式鎖。