redisson是如何解決死鎖問題的

這篇文章主要講解了“redisson是如何解決死鎖問題的”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“redisson是如何解決死鎖問題的”吧！

有關Redisson作為實現分布式鎖，總的分3大模塊來講。

  1.  `1、Redisson實現分布式鎖原理`

  2.  `2、Redisson實現分布式鎖的源碼解析`
    
  3.  `3、Redisson實現分布式鎖的項目代碼（可以用于實際項目中）`

一、高效分布式鎖

當我們在設計分布式鎖的時候，我們應該考慮分布式鎖至少要滿足的一些條件，同時考慮如何高效的設計分布式鎖，這里我認為以下幾點是必須要考慮的。

1、互斥

在分布式高并發的條件下，我們最需要保證，同一時刻只能有一個線程獲得鎖，這是最基本的一點。

2、防止死鎖

在分布式高并發的條件下，比如有個線程獲得鎖的同時，還沒有來得及去釋放鎖，就因為系統故障或者其它原因使它無法執行釋放鎖的命令,導致其它線程都無法獲得鎖，造成死鎖。

所以分布式非常有必要設置鎖的 有效時間，確保系統出現故障后，在一定時間內能夠主動去釋放鎖，避免造成死鎖的情況。

3、性能

對于訪問量大的共享資源，需要考慮減少鎖等待的時間，避免導致大量線程阻塞。

所以在鎖的設計時，需要考慮兩點。

1、 鎖的顆粒度要盡量小。比如你要通過鎖來減庫存，那這個鎖的名稱你可以設置成是商品的ID,而不是任取名稱。這樣這個鎖只對當前商品有效,鎖的顆粒度小。

2、 鎖的范圍盡量要小。比如只要鎖2行代碼就可以解決問題的，那就不要去鎖10行代碼了。

4、重入

我們知道ReentrantLock是可重入鎖，那它的特點就是：同一個線程可以重復拿到同一個資源的鎖。重入鎖非常有利于資源的高效利用。關于這點之后會做演示。

針對以上Redisson都能很好的滿足，下面就來分析下它。

二、Redisson原理分析

為了更好的理解分布式鎖的原理，我這邊自己畫張圖通過這張圖來分析。

1、加鎖機制

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

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

2、watch dog自動延期機制

這個比較難理解，找了些許資料感覺也并沒有解釋的很清楚。這里我自己的理解就是:

在一個分布式環境下，假如一個線程獲得鎖后，突然服務器宕機了，那么這個時候在一定時間后這個鎖會自動釋放，你也可以設置鎖的有效時間(不設置默認30秒），這樣的目的主要是防止死鎖的發生。

但在實際開發中會有下面一種情況:

  1.   `//設置鎖1秒過去`
  2.   `redissonLock.lock("redisson",  1);`
  3.   `/** 
  4.   `* 業務邏輯需要咨詢2秒`
  5.   `*/`
  6.   `redissonLock.release("redisson");`
  7.   `/**` 
  8.   `* 線程1 進來獲得鎖后，線程一切正常并沒有宕機，但它的業務邏輯需要執行2秒，這就會有個問題，在 線程1 執行1秒后，這個鎖就自動過期了，` 
  9.   `* 那么這個時候 線程2 進來了。那么就存在 線程1和線程2 同時在這段業務邏輯里執行代碼，這當然是不合理的。`
  10.   `* 而且如果是這種情況，那么在解鎖時系統會拋異常，因為解鎖和加鎖已經不是同一線程了，具體后面代碼演示。`
  11.   `*/`

所以這個時候 看門狗就出現了，它的作用就是 線程1 業務還沒有執行完，時間就過了，線程1 還想持有鎖的話，就會啟動一個watch dog后臺線程，不斷的延長鎖key的生存時間。

注意 正常這個看門狗線程是不啟動的，還有就是這個看門狗啟動后對整體性能也會有一定影響，所以不建議開啟看門狗。

3、為啥要用lua腳本呢？

這個不用多說，主要是如果你的業務邏輯復雜的話，通過封裝在lua腳本中發送給redis，而且redis是單線程的，這樣就保證這段復雜業務邏輯執行的原子性。

4、可重入加鎖機制

Redisson可以實現可重入加鎖機制的原因，我覺得跟兩點有關：

  1.  `1、Redis存儲鎖的數據類型是  Hash類型`
  2.  `2、Hash數據類型的key值包含了當前線程信息。`

下面是redis存儲的數據

上面這圖的意思就是可重入鎖的機制，它最大的優點就是相同線程不需要在等待鎖，而是可以直接進行相應操作。

5、Redis分布式鎖的缺點

Redis分布式鎖會有個缺陷，就是在Redis哨兵模式下:

客戶端1 對某個 master節點寫入了redisson鎖，此時會異步復制給對應的 slave節點。但是這個過程中一旦發生 master節點宕機，主備切換，slave節點從變為了 master節點。

這時 客戶端2 來嘗試加鎖的時候，在新的master節點上也能加鎖，此時就會導致多個客戶端對同一個分布式鎖完成了加鎖。

這時系統在業務語義上一定會出現問題，導致各種臟數據的產生。

缺陷在哨兵模式或者主從模式下，如果 master實例宕機的時候，可能導致多個客戶端同時完成加鎖。

感謝各位的閱讀，以上就是“redisson是如何解決死鎖問題的”的內容了，經過本文的學習后，相信大家對redisson是如何解決死鎖問題的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！