redisson的WatchDog是如何看家護院的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

成都創(chuàng)新互聯是一家專業(yè)提供杏花嶺企業(yè)網站建設,專注與成都網站建設、網站建設、HTML5、小程序制作等業(yè)務。10年已為杏花嶺眾多企業(yè)、政府機構等服務。創(chuàng)新互聯專業(yè)網站建設公司優(yōu)惠進行中。

 上一文，我們分析了redisson加鎖的過程，總結來說，流程不復雜，代碼也很直觀，主要是異步通過lua腳本執(zhí)行了加鎖的邏輯。其中，我們注意到了一些細節(jié)，比如 RedissonLock中的變量internalLockLeaseTime,默認值是30000毫秒，還有調用tryLockInnerAsync()傳入的一個從連接管理器獲取的getLockWatchdogTimeout(),他的默認值也是30000毫秒，這些都和redisson官方文檔所說的watchdog機制有關，看門狗，還是很形象的描述這一機制，那么看門狗到底做了什么，為什么怎么做呢？下面我們就來分析和探討一下。

      我們先思考一個問題，假設在一個分布式環(huán)境下，多個服務實例請求獲取鎖，其中服務實例1成功獲取到了鎖，在執(zhí)行業(yè)務邏輯的過程中，服務實例突然掛掉了或者hang住了，那么這個鎖會不會釋放，什么時候釋放？回答這個問題，自然想起來之前我們分析的lua腳本，其中第一次加鎖的時候使用pexpire給鎖key設置了過期時間，默認30000毫秒，由此來看如果服務實例宕機了，鎖最終也會釋放，其他服務實例也是可以繼續(xù)獲取到鎖執(zhí)行業(yè)務。但是要是30000毫秒之后呢，要是服務實例1沒有宕機但是業(yè)務執(zhí)行還沒有結束，所釋放掉了就會導致線程問題，這個redisson是怎么解決的呢？這個就一定要實現自動延長鎖有效期的機制。

      之前，我們分析到異步執(zhí)行完lua腳本執(zhí)行完成之后，設置了一個監(jiān)聽器，來處理異步執(zhí)行結束之后的一些工作。如圖所示，在操作完成之后會

去執(zhí)行operationComplete方法，先判斷這個異步操作有沒有執(zhí)行成功，如果沒有成功，直接返回，如果執(zhí)行成功了，就會同步獲取結果，如果ttlRemaining為null，則會執(zhí)行一個定時調度的方法scheduleExpirationRenewal,回想一下之前的lua腳本，當加鎖邏輯

處理結束，返回了一個nil;如此說來 就一定會走定時任務了。我們接下去看看定時任務的邏輯是什么樣子的。

首先，會先判斷在expirationRenewalMap中是否存在了entryName，這是個map結構，主要還是判斷在這個服務實例中的加鎖客戶端的鎖key是否存在，如果已經存在了，就直接返回；第一次加鎖，肯定是不存在的，接下來就是搞了一個TimeTask，延遲internalLockLeaseTime/3之后執(zhí)行，這里就用到了文章一開始就提到奇妙的變量，算下來就是大約10秒鐘執(zhí)行一次，調用了一個異步執(zhí)行的方法

renewExpirationAsync方法,也是調用異步執(zhí)行了一段lua腳本，首先判

斷這個鎖key的map結構中是否存在對應的key8a9649f5-f5b5-48b4-beaa-d0c24855f9ab:anyLock:1,如果存在，就直接調用pexpire命令設置鎖key的過期時間,默認30000毫秒。

OK，現在思路就清晰了，在上面任務調度的方法中，也是異步執(zhí)行并且設置了一個監(jiān)聽器，在操作執(zhí)行成功之后，會回調這個方法，如果調用失敗會打一個錯誤日志并返回，更新鎖過期時間失?。蝗缓螳@取異步執(zhí)行的結果，如果為true，就會調用本身，如此說來又會延遲10秒鐘去執(zhí)行這段邏輯，所以，這段邏輯在你成功獲取到鎖之后，會每隔十秒鐘去執(zhí)行一次，并且，在鎖key還沒有失效的情況下，會把鎖的過期時間繼續(xù)延長到30000毫秒，也就是說只要這臺服務實例沒有掛掉，并且沒有主動釋放鎖，看門狗都會每隔十秒給你續(xù)約一下，保證鎖一直在你手中。完美的操作。

到現在來說，加鎖，鎖自動延長過期時間，都OK了，然后就是說在你執(zhí)行業(yè)務，持有鎖的這段時間，別的服務實例來嘗試加鎖又會發(fā)生什么情況呢？或者當前客戶端的別的線程來獲取鎖呢？很顯然，肯定會阻塞住，我們來通過代碼看看是怎么做到的。還是把眼光放到之前分析的那段加鎖lua代碼上，當加鎖的鎖key存在的時候并

且鎖key對應的map結構中當前客戶端的唯一key也存在時，會去調用hincrby命令，將唯一key的值自增一，并且會pexpire設置key的過期時間為30000毫秒，然后返回nil,可以想象這里也是加鎖成功的，也會繼續(xù)去執(zhí)行定時調度任務，完成鎖key過期時間的續(xù)約，這里呢，就實現了鎖的可重入性。

那么當以上這種情況也沒有發(fā)生呢，這里就會直接返回當前鎖的剩余有效期，相應的也不會去執(zhí)行續(xù)約邏輯。此時一直返回到上面的方法，如下圖，如果加鎖成功就直接返回

否則就會進入一個死循環(huán)，去嘗試加鎖，并且也會在等待一段時間之后一直循環(huán)嘗試加鎖，阻塞住，知道第一個服務實例釋放鎖。對于不同的服務實例嘗試會獲取一把鎖，也和上面的邏輯類似，都是這樣實現了鎖的互斥。

緊接著，我們來看看鎖釋放的邏輯，其實也很簡單，調用了lock.unlock()方法，跟著代碼走流程發(fā)現，也是異步調用了一段lua腳本，

現在再看lua腳本，應該就比較清晰，也就是通過判斷鎖key是否存在，如果不存在直接返回；否則就會判斷當前客戶端對應的唯一key的值是否存在，如果不存在就會返回nil;否則，值自增-1，判斷唯一key的值是否大于零，如果大于零，則返回0；否則刪除當前鎖key，并返回1；返回到上一層方法，也是針對返回值進行了操作，如果返回值是1，則會去取消之前的

定時續(xù)約任務，如果失敗了，則會做一些類似設置狀態(tài)的操作，這一些和解鎖邏輯也沒有什么關系，可以不去看他。

總結一下，redisson的加鎖和解鎖流程我們也跟完了，現在來說，redis分布式鎖，redisson去加鎖，也就是去redis集群中選擇一臺master實例去實現鎖機制，并且能因為一臺master可能會掛載多臺slave實例，這樣也就實現了高可用性。但是呢，不得不去思考，如果master和salve同步的過程中，master宕機了，偏偏在這之前某個服務實例剛剛寫入了一把鎖，這時候就尷尬了，salve還沒有同步到這把鎖，就被切換成了master，那么這時候可以說就有問題了，另一個服務實例在新的master上獲取到一把新鎖，這時候就會出現倆臺服務實例都持有鎖，執(zhí)行業(yè)務邏輯的場景，這個是有問題的。也是在生產環(huán)境中我們需要去考慮的一個問題。

關于redisson的WatchDog是如何看家護院的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯行業(yè)資訊頻道了解更多相關知識。