一、什么是分布式鎖：

1、什么是分布式鎖：

分布式鎖，即分布式系統中的鎖。在單體應用中我們通過鎖解決的是控制共享資源訪問的問題，而分布式鎖，就是解決了分布式系統中控制共享資源訪問的問題。與單體應用不同的是，分布式系統中競爭共享資源的最小粒度從線程升級成了進程。

2、分布式鎖應該具備哪些條件：

• 在分布式系統環境下，一個方法在同一時間只能被一個機器的一個線程執行
• 高可用的獲取鎖與釋放鎖
• 高性能的獲取鎖與釋放鎖
• 具備可重入特性（可理解為重新進入，由多于一個任務并發使用，而不必擔心數據錯誤）
• 具備鎖失效機制，即自動解鎖，防止死鎖
• 具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗

3、分布式鎖的實現方式：

• 基于數據庫實現分布式鎖
• 基于Zookeeper實現分布式鎖
• 基于reids實現分布式鎖

這篇文章就簡單介紹下這幾種分布式鎖的實現，重點講解的是基于redis的分布式鎖。

?

二、基于數據庫的分布式鎖：

基于數據庫的鎖實現也有兩種方式，一是基于數據庫表的增刪，另一種是基于數據庫排他鎖。

1、基于數據庫表的增刪：

基于數據庫表增刪是最簡單的方式，首先創建一張鎖的表主要包含下列字段：類的全路徑名+方法名，時間戳等字段。

具體的使用方式：當需要鎖住某個方法時，往該表中插入一條相關的記錄。類的全路徑名+方法名是有唯一性約束的，如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么我們就認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。執行完畢之后，需要delete該記錄。

（這里只是簡單介紹一下，對于上述方案可以進行優化，如：應用主從數據庫，數據之間雙向同步；一旦掛掉快速切換到備庫上；做一個定時任務，每隔一定時間把數據庫中的超時數據清理一遍；使用while循環，直到insert成功再返回成功；記錄當前獲得鎖的機器的主機信息和線程信息，下次再獲取鎖的時候先查詢數據庫，如果當前機器的主機信息和線程信息在數據庫可以查到的話，直接把鎖分配給他就可以了，實現可重入鎖）

2、基于數據庫排他鎖：

基于MySql的InnoDB引擎，可以使用以下方法來實現加鎖操作：

public void lock(){connection.setAutoCommit(false)int count = 0;while(count < 4){try{select * from lock where lock_name=xxx for update;if(結果不為空){//代表獲取到鎖return;}}catch(Exception e){}//為空或者拋異常的話都表示沒有獲取到鎖sleep(1000);count++;}throw new LockException(); }

在查詢語句后面增加for update，數據庫會在查詢過程中給數據庫表增加排他鎖。獲得排它鎖的線程即可獲得分布式鎖，當獲得鎖之后，可以執行方法的業務邏輯，執行完方法之后，釋放鎖connection.commit()。當某條記錄被加上排他鎖之后，其他線程無法獲取排他鎖并被阻塞。

3、基于數據庫鎖的優缺點：

上面兩種方式都是依賴數據庫表，一種是通過表中的記錄判斷當前是否有鎖存在，另外一種是通過數據庫的排他鎖來實現分布式鎖。

• 優點是直接借助數據庫，簡單容易理解。
• 缺點是操作數據庫需要一定的開銷，性能問題需要考慮。

?

三、基于Zookeeper的分布式鎖：

基于zookeeper臨時有序節點可以實現的分布式鎖。每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。 判斷是否獲取鎖的方式很簡單，只需要判斷有序節點中序號最小的一個。 當釋放鎖的時候，只需將這個瞬時節點刪除即可。同時，其可以避免服務宕機導致的鎖無法釋放，而產生的死鎖問題。 （第三方庫有?Curator，Curator提供的InterProcessMutex是分布式鎖的實現）

Zookeeper實現的分布式鎖存在兩個個缺點：

（1）性能上可能并沒有緩存服務那么高，因為每次在創建鎖和釋放鎖的過程中，都要動態創建、銷毀瞬時節點來實現鎖功能。ZK中創建和刪除節點只能通過Leader服務器來執行，然后將數據同步到所有的Follower機器上。

（2）zookeeper的并發安全問題：因為可能存在網絡抖動，客戶端和ZK集群的session連接斷了，zk集群以為客戶端掛了，就會刪除臨時節點，這時候其他客戶端就可以獲取到分布式鎖了。

?

四、基于redis的分布式鎖：

redis命令說明：

（1）setnx命令：set if not exists，當且僅當 key 不存在時，將?key 的值設為 value。若給定的 key 已經存在，則 SETNX 不做任何動作。

• 返回1，說明該進程獲得鎖，將?key 的值設為 value
• 返回0，說明其他進程已經獲得了鎖，進程不能進入臨界區。

命令格式：setnx lock.key lock.value

（2）get命令：獲取key的值，如果存在，則返回；如果不存在，則返回nil

命令格式：get lock.key

（3）getset命令：該方法是原子的，對key設置newValue這個值，并且返回key原來的舊值。

命令格式：getset lock.key newValue

（4）del命令：刪除redis中指定的key

命令格式：del lock.key

方案一：基于set命令的分布式鎖

1、加鎖：使用setnx進行加鎖，當該指令返回1時，說明成功獲得鎖

2、解鎖：當得到鎖的線程執行完任務之后，使用del命令釋放鎖，以便其他線程可以繼續執行setnx命令來獲得鎖

（1）存在的問題：假設線程獲取了鎖之后，在執行任務的過程中掛掉，來不及顯示地執行del命令釋放鎖，那么競爭該鎖的線程都會執行不了，產生死鎖的情況。

（2）解決方案：設置鎖超時時間

3、設置鎖超時時間：setnx 的 key 必須設置一個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間后自動釋放。可以使用expire命令設置鎖超時時間

（1）存在問題：

setnx 和 expire 不是原子性的操作，假設某個線程執行setnx 命令，成功獲得了鎖，但是還沒來得及執行expire 命令，服務器就掛掉了，這樣一來，這把鎖就沒有設置過期時間了，變成了死鎖，別的線程再也沒有辦法獲得鎖了。

（2）解決方案：redis的set命令支持在獲取鎖的同時設置key的過期時間

4、使用set命令加鎖并設置鎖過期時間：

命令格式：set <lock.key> <lock.value> nx ex <expireTime>

詳情參考redis使用文檔：http://doc.redisfans.com/string/set.html

（1）存在問題：

① 假如線程A成功得到了鎖，并且設置的超時時間是 30 秒。如果某些原因導致線程 A 執行的很慢，過了 30 秒都沒執行完，這時候鎖過期自動釋放，線程 B 得到了鎖。

② 隨后，線程A執行完任務，接著執行del指令來釋放鎖。但這時候線程 B 還沒執行完，線程A實際上刪除的是線程B加的鎖。

（2）解決方案：

可以在 del 釋放鎖之前做一個判斷，驗證當前的鎖是不是自己加的鎖。在加鎖的時候把當前的線程 ID 當做value，并在刪除之前驗證 key 對應的 value 是不是自己線程的 ID。但是，這樣做其實隱含了一個新的問題，get操作、判斷和釋放鎖是兩個獨立操作，不是原子性。對于非原子性的問題，我們可以使用Lua腳本來確保操作的原子性

5、鎖續期：（這種機制類似于redisson的看門狗機制，文章后面會詳細說明）

雖然步驟4避免了線程A誤刪掉key的情況，但是同一時間有 A，B 兩個線程在訪問代碼塊，仍然是不完美的。怎么辦呢？我們可以讓獲得鎖的線程開啟一個守護線程，用來給快要過期的鎖“續期”。

① 假設線程A執行了29 秒后還沒執行完，這時候守護線程會執行 expire 指令，為這把鎖續期 20 秒。守護線程從第 29 秒開始執行，每 20 秒執行一次。

② 情況一：當線程A執行完任務，會顯式關掉守護線程。

③ 情況二：如果服務器忽然斷電，由于線程 A 和守護線程在同一個進程，守護線程也會停下。這把鎖到了超時的時候，沒人給它續命，也就自動釋放了。

方案二：基于setnx、get、getset的分布式鎖

1、實現原理：

（1）setnx(lockkey, 當前時間+過期超時時間) ，如果返回1，則獲取鎖成功；如果返回0則沒有獲取到鎖，轉向步驟(2)

（2）get(lockkey)獲取值oldExpireTime ，并將這個value值與當前的系統時間進行比較，如果小于當前系統時間，則認為這個鎖已經超時，可以允許別的請求重新獲取，轉向步驟(3)

（3）計算新的過期時間 newExpireTime=當前時間+鎖超時時間，然后getset(lockkey, newExpireTime) 會返回當前lockkey的值currentExpireTime

（4）判斷 currentExpireTime 與 oldExpireTime 是否相等，如果相等，說明當前getset設置成功，獲取到了鎖。如果不相等，說明這個鎖又被別的請求獲取走了，那么當前請求可以直接返回失敗，或者繼續重試。

（5）在獲取到鎖之后，當前線程可以開始自己的業務處理，當處理完畢后，比較自己的處理時間和對于鎖設置的超時時間，如果小于鎖設置的超時時間，則直接執行del命令釋放鎖（釋放鎖之前需要判斷持有鎖的線程是不是當前線程）；如果大于鎖設置的超時時間，則不需要再鎖進行處理。

2、代碼實現：

（1）獲取鎖的實現方式：

public boolean lock(long acquireTimeout, TimeUnit timeUnit) throws InterruptedException {acquireTimeout = timeUnit.toMillis(acquireTimeout);long acquireTime = acquireTimeout + System.currentTimeMillis();//使用J.U.C的ReentrantLockthreadLock.tryLock(acquireTimeout, timeUnit);try {//循環嘗試while (true) {//調用tryLockboolean hasLock = tryLock();if (hasLock) {//獲取鎖成功return true;} else if (acquireTime < System.currentTimeMillis()) {break;}Thread.sleep(sleepTime);}} finally {if (threadLock.isHeldByCurrentThread()) {threadLock.unlock();}}return false; }public boolean tryLock() {long currentTime = System.currentTimeMillis();String expires = String.valueOf(timeout + currentTime);//設置互斥量if (redisHelper.setNx(mutex, expires) > 0) {//獲取鎖，設置超時時間setLockStatus(expires);return true;} else {String currentLockTime = redisUtil.get(mutex);//檢查鎖是否超時if (Objects.nonNull(currentLockTime) && Long.parseLong(currentLockTime) < currentTime) {//獲取舊的鎖時間并設置互斥量String oldLockTime = redisHelper.getSet(mutex, expires);//舊值與當前時間比較if (Objects.nonNull(oldLockTime) && Objects.equals(oldLockTime, currentLockTime)) {//獲取鎖，設置超時時間setLockStatus(expires);return true;}}return false;} }

tryLock方法中，主要邏輯如下：lock調用tryLock方法，參數為獲取的超時時間與單位，線程在超時時間內，獲取鎖操作將自旋在那里，直到該自旋鎖的保持者釋放了鎖。

（2）釋放鎖的實現方式：

public boolean unlock() {//只有鎖的持有線程才能解鎖if (lockHolder == Thread.currentThread()) {//判斷鎖是否超時，沒有超時才將互斥量刪除if (lockExpiresTime > System.currentTimeMillis()) {redisHelper.del(mutex);logger.info("刪除互斥量[{}]", mutex);}lockHolder = null;logger.info("釋放[{}]鎖成功", mutex);return true;} else {throw new IllegalMonitorStateException("沒有獲取到鎖的線程無法執行解鎖操作");} }

存在問題：

（1）這個鎖的核心是基于System.currentTimeMillis()，如果多臺服務器時間不一致，那么問題就出現了，但是這個bug完全可以從服務器運維層面規避的，而且如果服務器時間不一樣的話，只要和時間相關的邏輯都是會出問題的

（2）如果前一個鎖超時的時候，剛好有多臺服務器去請求獲取鎖，那么就會出現同時執行redis.getset()而導致出現過期時間覆蓋問題，不過這種情況并不會對正確結果造成影響

（3）存在多個線程同時持有鎖的情況：如果線程A執行任務的時間超過鎖的過期時間，這時另一個線程就可以獲得這個鎖了，造成多個線程同時持有鎖的情況。類似于方案一，可以使用“鎖續期”的方式來解決。

前兩種redis分布式鎖的存在的問題

前面兩種redis分布式鎖的實現方式，如果從“高可用”的層面來看，仍然是有所欠缺，也就是說當?redis?是單點的情況下，當發生故障時，則整個業務的分布式鎖都將無法使用。

為了提高可用性，我們可以使用主從模式或者哨兵模式，但在這種情況下仍然存在問題，在主從模式或者哨兵模式下，正常情況下，如果加鎖成功了，那么master節點會異步復制給對應的slave節點。但是如果在這個過程中發生master節點宕機，主備切換，slave節點從變為了 master節點，而鎖還沒從舊master節點同步過來，這就發生了鎖丟失，會導致多個客戶端可以同時持有同一把鎖的問題。來看個圖來想下這個過程：

那么，如何避免這種情況呢？redis?官方給出了基于多個?redis?集群部署的高可用分布式鎖解決方案：RedLock，在方案三我們就來詳細介紹一下。（備注：如果master節點宕機期間，可以容忍多個客戶端同時持有鎖，那么就不需要redLock）

方案三：基于RedLock的分布式鎖

redLock的官方文檔地址：https://redis.io/topics/distlock（文章末尾附上對應的翻譯截圖）

Redlock算法是Redis的作者 Antirez 在單Redis節點基礎上引入的高可用模式。Redlock的加鎖要結合單節點分布式鎖算法共同實現，因為??????它是RedLock的基礎

1、加鎖實現原理：

現在假設有5個Redis主節點(大于3的奇數個)，這樣基本保證他們不會同時都宕掉，獲取鎖和釋放鎖的過程中，客戶端會執行以下操作：

（1）獲取當前Unix時間，以毫秒為單位，并設置超時時間TTL

TTL 要大于?正常業務執行的時間 + 獲取所有redis服務消耗時間 + 時鐘漂移

（2）依次嘗試從5個實例，使用相同的key和具有唯一性的value獲取鎖，當向Redis請求獲取鎖時，客戶端應該設置一個網絡連接和響應超時時間，這個超時時間應該小于鎖的失效時間TTL，這樣可以避免客戶端死等。比如：TTL為5s，設置獲取鎖最多用1s，所以如果一秒內無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖

（3）客戶端 獲取所有能獲取的鎖后的時間 減去 第(1)步的時間，就得到鎖的獲取時間。鎖的獲取時間要小于鎖失效時間TTL，并且至少從半數以上的Redis節點取到鎖，才算獲取成功鎖

（4）如果成功獲得鎖，key的真正有效時間 = TTL - 鎖的獲取時間 - 時鐘漂移。比如：TTL 是5s,獲取所有鎖用了2s，則真正鎖有效時間為3s

（5）如果因為某些原因，獲取鎖失敗（沒有在半數以上實例取到鎖或者取鎖時間已經超過了有效時間），客戶端應該在所有的Redis實例上進行解鎖，無論Redis實例是否加鎖成功，因為可能服務端響應消息丟失了但是實際成功了。

設想這樣一種情況：客戶端發給某個Redis節點的獲取鎖的請求成功到達了該Redis節點，這個節點也成功執行了SET操作，但是它返回給客戶端的響應包卻丟失了。這在客戶端看來，獲取鎖的請求由于超時而失敗了，但在Redis這邊看來，加鎖已經成功了。因此，釋放鎖的時候，客戶端也應該對當時獲取鎖失敗的那些Redis節點同樣發起請求。實際上，這種情況在異步通信模型中是有可能發生的：客戶端向服務器通信是正常的，但反方向卻是有問題的。

（6）失敗重試：當client不能獲取鎖時，應該在隨機時間后重試獲取鎖；同時重試獲取鎖要有一定次數限制；

在隨機時間后進行重試，主要是防止過多的客戶端同時嘗試去獲取鎖，導致彼此都獲取鎖失敗的問題。

算法示意圖如下：

2、RedLock性能及崩潰恢復的相關解決方法：

由于N個Redis節點中的大多數能正常工作就能保證Redlock正常工作，因此理論上它的可用性更高。前面我們說的主從架構下存在的安全性問題，在RedLock中已經不存在了，但如果有節點發生崩潰重啟，還是會對鎖的安全性有影響的，具體的影響程度跟Redis持久化配置有關：

（1）如果redis沒有持久化功能，在clientA獲取鎖成功后，所有redis重啟，clientB能夠再次獲取到鎖，這樣違法了鎖的排他互斥性；

（2）如果啟動AOF永久化存儲，事情會好些， 舉例：當我們重啟redis后，由于redis過期機制是按照unix時間戳走的，所以在重啟后，然后會按照規定的時間過期，不影響業務；但是由于AOF同步到磁盤的方式默認是每秒一次，如果在一秒內斷電，會導致數據丟失，立即重啟會造成鎖互斥性失效；但如果同步磁盤方式使用Always(每一個寫命令都同步到硬盤)造成性能急劇下降；所以在鎖完全有效性和性能方面要有所取舍；

（3）為了有效解決既保證鎖完全有效性 和 性能高效問題：antirez又提出了“延遲重啟”的概念，redis同步到磁盤方式保持默認的每秒1次，在redis崩潰單機后（無論是一個還是所有），先不立即重啟它，而是等待TTL時間后再重啟，這樣的話，這個節點在重啟前所參與的鎖都會過期，它在重啟后就不會對現有的鎖造成影響，缺點是在TTL時間內服務相當于暫停狀態；

3、Redisson中RedLock的實現：

在JAVA的redisson包已經實現了對RedLock的封裝，主要是通過?redisClient?與?lua?腳本實現的，之所以使用?lua?腳本，是為了實現加解鎖校驗與執行的事務性。

（1）唯一ID的生成：

分布式事務鎖中，為了能夠讓作為中心節點的存儲節點獲取鎖的持有者，從而避免鎖被非持有者誤解鎖，每個發起請求的?client?節點都必須具有全局唯一的?id。通常我們是使用?UUID?來作為這個唯一?id，redisson?也是這樣實現的，在此基礎上，redisson?還加入了?threadid?避免了多個線程反復獲取?UUID?的性能損耗

protected final UUID id = UUID.randomUUID(); String getLockName(long threadId) {return id + ":" + threadId; }

（2）加鎖邏輯：

redisson?加鎖的核心代碼非常容易理解，通過傳入?TTL?與唯一?id，實現一段時間的加鎖請求。下面是可重入鎖的實現邏輯：

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {internalLockLeaseTime = unit.toMillis(leaseTime);// 獲取鎖時向5個redis實例發送的命令return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,// 校驗分布式鎖的KEY是否已存在，如果不存在，那么執行hset命令（hset REDLOCK_KEY uuid+threadId 1），并通過pexpire設置失效時間（也是鎖的租約時間）"if (redis.call('exists', KEYS[1]) == 0) then " +"redis.call('hset', KEYS[1], ARGV[2], 1); " +"redis.call('pexpire', KEYS[1], ARGV[1]); " +"return nil; " +"end; " +// 如果分布式鎖的KEY已存在，則校驗唯一 id，如果唯一 id 匹配，表示是當前線程持有的鎖，那么重入次數加1，并且設置失效時間"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +"redis.call('pexpire', KEYS[1], ARGV[1]); " +"return nil; " +"end; " +// 獲取分布式鎖的KEY的失效時間毫秒數"return redis.call('pttl', KEYS[1]);",// KEYS[1] 對應分布式鎖的 key；ARGV[1] 對應 TTL；ARGV[2] 對應唯一 idCollections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId)); }

（3）釋放鎖邏輯：

protected RFuture<Boolean> unlockInnerAsync(long threadId) {// 向5個redis實例都執行如下命令return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,// 如果分布式鎖 KEY 不存在，那么向 channel 發布一條消息"if (redis.call('exists', KEYS[1]) == 0) then " +"redis.call('publish', KEYS[2], ARGV[1]); " +"return 1; " +"end;" +// 如果分布式鎖存在，但是唯一 id 不匹配，表示鎖已經被占用"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +"return nil;" +"end; " +// 如果就是當前線程占有分布式鎖，那么將重入次數減 1"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +// 重入次數減1后的值如果大于0，表示分布式鎖有重入過，那么只設置失效時間，不刪除"if (counter > 0) then " +"redis.call('pexpire', KEYS[1], ARGV[2]); " +"return 0; " +"else " +// 重入次數減1后的值如果為0，則刪除鎖，并發布解鎖消息"redis.call('del', KEYS[1]); " +"redis.call('publish', KEYS[2], ARGV[1]); " +"return 1; "+"end; " +"return nil;",// KEYS[1] 表示鎖的 key，KEYS[2] 表示 channel name，ARGV[1] 表示解鎖消息，ARGV[2] 表示 TTL，ARGV[3] 表示唯一 idArrays.<Object>asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(threadId)); }

（4）redisson中RedLock的使用：

Config config = new Config(); config.useSentinelServers().addSentinelAddress("127.0.0.1:6369","127.0.0.1:6379", "127.0.0.1:6389").setMasterName("masterName").setPassword("password").setDatabase(0);RedissonClient redissonClient = Redisson.create(config); RLock redLock = redissonClient.getLock("REDLOCK_KEY");try {// 嘗試加鎖，最多等待500ms，上鎖以后10s自動解鎖boolean isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS);if (isLock) {//獲取鎖成功，執行對應的業務邏輯} } catch (Exception e) {e.printStackTrace(); } finally {redLock.unlock(); }

可以看到，redisson?包的實現中，通過?lua?腳本校驗了解鎖時的?client?身份，所以我們無需再在?finally?中去判斷是否加鎖成功，也無需做額外的身份校驗，可以說已經達到開箱即用的程度了。

同樣，基于RedLock實現的分布式鎖也存在?client 獲取鎖之后，在?TTL?時間內沒有完成業務邏輯的處理，而此時鎖會被自動釋放，造成多個線程同時持有鎖的問題。而Redisson?在實現的過程中，自然也考慮到了這一問題，redisson?提供了一個“看門狗”的特性，當鎖即將過期還沒有釋放時，不斷的延長鎖key的生存時間。（具體實現原理會在方案四進行介紹）

4、RedLock算法的安全性爭論：

對于這塊感興趣的朋友可以閱讀這四篇文章，站在巨人的肩膀上看問題，真的是一種享受，受益匪淺，強烈建議閱讀

How to do distributed locking

Is Redlock safe?

基于Redis的分布式鎖到底安全嗎？（上）

基于Redis的分布式鎖到底安全嗎？（下）

方案四：基于Redisson看門狗的分布式鎖

前面說了，如果某些原因導致持有鎖的線程在鎖過期時間內，還沒執行完任務，而鎖因為還沒超時被自動釋放了，那么就會導致多個線程同時持有鎖的現象出現，而為了解決這個問題，可以進行“鎖續期”。其實，在JAVA的Redisson包中有一個"看門狗"機制，已經幫我們實現了這個功能。

1、redisson原理：

redisson在獲取鎖之后，會維護一個看門狗線程，當鎖即將過期還沒有釋放時，不斷的延長鎖key的生存時間

2、加鎖機制：

線程去獲取鎖，獲取成功：執行lua腳本，保存數據到redis數據庫。

線程去獲取鎖，獲取失敗：一直通過while循環嘗試獲取鎖，獲取成功后，執行lua腳本，保存數據到redis數據庫。

3、watch dog自動延期機制：

看門狗啟動后，對整體性能也會有一定影響，默認情況下看門狗線程是不啟動的。如果使用redisson進行加鎖的同時設置了鎖的過期時間，也會導致看門狗機制失效。

redisson在獲取鎖之后，會維護一個看門狗線程，在每一個鎖設置的過期時間的1/3處，如果線程還沒執行完任務，則不斷延長鎖的有效期。看門狗的檢查鎖超時時間默認是30秒，可以通過 lockWactchdogTimeout 參數來改變。

加鎖的時間默認是30秒，如果加鎖的業務沒有執行完，那么每隔?30 ÷ 3 = 10秒，就會進行一次續期，把鎖重置成30秒，保證解鎖前鎖不會自動失效。

那萬一業務的機器宕機了呢？如果宕機了，那看門狗線程就執行不了了，就續不了期，那自然30秒之后鎖就解開了唄。

4、redisson分布式鎖的關鍵點：

a.?對key不設置過期時間，由Redisson在加鎖成功后給維護一個watchdog看門狗，watchdog負責定時監聽并處理，在鎖沒有被釋放且快要過期的時候自動對鎖進行續期，保證解鎖前鎖不會自動失效

b.?通過Lua腳本實現了加鎖和解鎖的原子操作

c.?通過記錄獲取鎖的客戶端id，每次加鎖時判斷是否是當前客戶端已經獲得鎖，實現了可重入鎖。

5、Redisson的使用：

在方案三中，我們已經演示了基于Redisson的RedLock的使用案例，其實 Redisson 也封裝 可重入鎖（Reentrant Lock）、公平鎖（Fair Lock）、聯鎖（MultiLock）、紅鎖（RedLock）、讀寫鎖（ReadWriteLock）、?信號量（Semaphore）、可過期性信號量（PermitExpirableSemaphore）、?閉鎖（CountDownLatch）等，具體使用說明可以參考官方文檔：Redisson的分布式鎖和同步器

?

附：redLock的官方文檔翻譯

?

參考文章：https://www.cnblogs.com/rgcloveyaya/p/rgc_love_yaya_1003days.html

總結

以上是生活随笔為你收集整理的Redis的分布式锁详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。