Redis實現(xiàn)分布式鎖的幾種方案
1.前言
對于Redis實現(xiàn)分布式鎖的幾種方案這個話題,展開之前我想先簡單聊聊什么是分布式鎖,分布式鎖的使用場景,除了Redis外還有什么技術(shù)實現(xiàn)分布式鎖等一系列內(nèi)容。
1.1分布式鎖
說大一點,就是在現(xiàn)在發(fā)展越來越迅速的大背景下,去中心化分布式系統(tǒng)越來越普及,在我們實際的生產(chǎn)開發(fā)當中,有一種不可避免的場景就是多個進程互斥的對其資源的使用,為了保證數(shù)據(jù)不重復,要求在同一時刻,同一任務(wù)只在一個節(jié)點上運行,且保證在多進程下的數(shù)據(jù)安全,分布式鎖就十分重要了。
1.2分布式鎖的幾種方案
方式有很多種,根據(jù)技術(shù)角度的不同
有基于MySQL的方式,通過表的唯一索引,通過insert和delete就可以實現(xiàn)加鎖和解鎖的效果;
有基于zookeeper的方式,通過創(chuàng)建臨時有序節(jié)點,判斷創(chuàng)建的節(jié)點序號是否最小。若是,則表示獲取到鎖,不是,則watch /lock目錄下序號比自身小的前一個節(jié)點,解鎖只需要刪除節(jié)點;
有基于Redis的方式。通過執(zhí)行setnx,若成功再執(zhí)行expire添加過期時間的方式加鎖,解鎖執(zhí)行delete命令。
方式有很多,不一一列舉了。
1.3Redis分布式鎖需要滿足的條件
- 互斥性。在任意時刻,只有一個客戶端能持有鎖。
- 不發(fā)生死鎖。即使有一個客戶端在持有鎖的期間崩潰而沒有主動解鎖也能保證后續(xù)其他客戶端能加鎖。
- 同一性。加鎖和解鎖必須是同一個客戶端,客戶端自己不能把別人加的鎖給解了,即不能誤解鎖。
- 容錯性。只要大多數(shù)Redis節(jié)點正常運行,客戶端就能夠獲取和釋放鎖。
2.Redis實現(xiàn)分布式鎖的幾種方案
可以通過以下方式實現(xiàn)(包括但不限于):
- SETNX + EXPIRE
- SETNX + value(系統(tǒng)時間+過期時間)
- 通過開源框架-Redisson
簡單來說說,用Java代碼演示:
2.1 SETNX + EXPIRE
setnx(SET IF NOT EXISTS)+ expire命令。先用setnx來搶鎖,如果搶到鎖,再用expire給鎖設(shè)置一個過期時間,這樣持有鎖超時時釋放鎖,防止鎖忘記釋放。但此時setnx和expire兩個命令無法保證原子性,例如:
2.2 SETNX + value(系統(tǒng)時間+過期時間)
可以把過期時間放到setnx的value值里面。如果加鎖失敗,再拿出value值校驗一下即可。加鎖代碼如下:
2.3 通過開源框架-Redisson
那么此時就要去想了,如果已經(jīng)超過了加鎖的過期時間,可是業(yè)務(wù)還沒執(zhí)行完成,這個時候怎么做呢?是把過期時間延長嗎?顯然不合理,可以通過開源框架-Redisson優(yōu)化這個問題,簡單來說,Redisson就是當一個線程獲得鎖以后,給該線程開啟一個定時守護線程,每隔一段時間檢查鎖是否還存在,存在則對鎖的過期時間延長,防止鎖過期提前釋放。假設(shè)兩個線程爭奪統(tǒng)一公共資源:線程A獲取鎖,并通過哈希算法選擇節(jié)點,執(zhí)行Lua腳本加鎖,同時其看門狗機制會啟動一個watch dog(后臺線程),每隔10秒檢查線程,如果線程A還持有鎖,那么就會不斷的延長鎖key的生存時間。線程B獲得鎖失敗,就會訂閱解鎖消息,當獲取鎖到剩余過期時間后,調(diào)用信號量方法阻塞住,直到被喚醒或等待超時。一旦線程A釋放了鎖,就會廣播解鎖消息。于是,解鎖消息的監(jiān)聽器會釋放信號量,獲取鎖被阻塞的線程B就會被喚醒,并重新嘗試獲取鎖。
Redisson 支持單點模式、主從模式、哨兵模式、集群模式,假設(shè)現(xiàn)為單點模式:
3.小結(jié)
Redis的分布式鎖實現(xiàn)方式有很多,這里不一一列舉了,有機會再展開Lua腳本、分布式鎖Redlock等內(nèi)容。