這篇文章主要是對 Redis 官方網站刊登的 Distributed locks with Redis 部分內容的總結和翻譯。

什么是 RedLock

Redis 官方站這篇文章提出了一種權威的基于 Redis 實現分布式鎖的方式名叫 Redlock，此種方式比原先的單節點的方法更安全。它可以保證以下特性：

安全特性：互斥訪問，即永遠只有一個 client 能拿到鎖

避免死鎖：最終 client 都可能拿到鎖，不會出現死鎖的情況，即使原本鎖住某資源的 client crash 了或者出現了網絡分區

容錯性：只要大部分 Redis 節點存活就可以正常提供服務

怎么在單節點上實現分布式鎖

SET resourcename myrandom_value NX PX 30000

主要依靠上述命令，該命令僅當 Key 不存在時(NX保證)set 值，并且設置過期時間 3000ms (PX保證)，值 myrandomvalue 必須是所有 client 和所有鎖請求發生期間唯一的，釋放鎖的邏輯是：

ifredis.call("get",KEYS[1])==ARGV[1]then

returnredis.call("del",KEYS[1])

else

return0

end

上述實現可以避免釋放另一個client創建的鎖，如果只有 del 命令的話，那么如果 client1 拿到 lock1 之后因為某些操作阻塞了很長時間，此時 Redis 端 lock1 已經過期了并且已經被重新分配給了 client2，那么 client1 此時再去釋放這把鎖就會造成 client2 原本獲取到的鎖被 client1 無故釋放了，但現在為每個 client 分配一個 unique 的 string 值可以避免這個問題。至于如何去生成這個 unique string，方法很多隨意選擇一種就行了。

Redlock 算法

算法很易懂，起 5 個 master 節點，分布在不同的機房盡量保證可用性。為了獲得鎖，client 會進行如下操作：

得到當前的時間，微妙單位

嘗試順序地在 5 個實例上申請鎖，當然需要使用相同的 key 和 random value，這里一個 client 需要合理設置與 master 節點溝通的 timeout 大小，避免長時間和一個 fail 了的節點浪費時間

當 client 在大于等于 3 個 master 上成功申請到鎖的時候，且它會計算申請鎖消耗了多少時間，這部分消耗的時間采用獲得鎖的當下時間減去第一步獲得的時間戳得到，如果鎖的持續時長(lock validity time)比流逝的時間多的話，那么鎖就真正獲取到了。

如果鎖申請到了，那么鎖真正的 lock validity time 應該是 origin(lock validity time) - 申請鎖期間流逝的時間

如果 client 申請鎖失敗了，那么它就會在少部分申請成功鎖的 master 節點上執行釋放鎖的操作，重置狀態

失敗重試

如果一個 client 申請鎖失敗了，那么它需要稍等一會在重試避免多個 client 同時申請鎖的情況，最好的情況是一個 client 需要幾乎同時向 5 個 master 發起鎖申請。另外就是如果 client 申請鎖失敗了它需要盡快在它曾經申請到鎖的 master 上執行 unlock 操作，便于其他 client 獲得這把鎖，避免這些鎖過期造成的時間浪費，當然如果這時候網絡分區使得 client 無法聯系上這些 master，那么這種浪費就是不得不付出的代價了。

放鎖

放鎖操作很簡單，就是依次釋放所有節點上的鎖就行了

性能、崩潰恢復和 fsync

如果我們的節點沒有持久化機制，client 從 5 個 master 中的 3 個處獲得了鎖，然后其中一個重啟了，這是注意 整個環境中又出現了 3 個 master 可供另一個 client 申請同一把鎖！ 違反了互斥性。如果我們開啟了 AOF 持久化那么情況會稍微好轉一些，因為 Redis 的過期機制是語義層面實現的，所以在 server 掛了的時候時間依舊在流逝，重啟之后鎖狀態不會受到污染。但是考慮斷電之后呢，AOF部分命令沒來得及刷回磁盤直接丟失了，除非我們配置刷回策略為 fsnyc = always，但這會損傷性能。解決這個問題的方法是，當一個節點重啟之后，我們規定在 max TTL 期間它是不可用的，這樣它就不會干擾原本已經申請到的鎖，等到它 crash 前的那部分鎖都過期了，環境不存在歷史鎖了，那么再把這個節點加進來正常工作。