大家好，如果您還對redis分布式鎖解決可重入不太了解，沒有關系，今天就由本站為大家分享redis分布式鎖解決可重入的知識，包括redis分布式鎖釋放問題的問題都會給大家分析到，還望可以解決大家的問題，下面我們就開始吧！

redissession分布式鎖原理

redission為redis官網發布的分布式解決方案，redission中包含了我們了解的常用鎖的類型，基本的可重入鎖，讀寫鎖，以及CountDownLatch的設置及使用，但是他們是分布式鎖，以往我們JUC提供的鎖都是在單線程的線程模型中使用的，當多個進程多個線程來操作一個無鎖的共享資源的時候，就會出現線程不安全的問題，就是我們多次執行后結果和單個線程執行時結果的不一致，為了讓線程一致我們是需要一些處理辦法的，那就是分布式鎖，通過鎖進行多線程的同步來進行資源隔離來實現對資源的訪問控制，從而達到線程安全

如何使用RedLock實現分布式鎖

紅鎖（RedLock）是用于分布式網絡系統中的一種操作控制機制，即分布式鎖。它解決的問題是在多個主機的系統里，保證用戶的寫操作的安全性，一致性和高效性。

在分布式網絡中，操作的一致性和高效性是矛盾的，為什么呢？“高效”是指在單位時間里完成的并發操作越多越好，越快越好；而“一致”是指在網絡中某個特定數據在各個主機中的值是相同的，當一個用戶訪問時不會出現在一個主機上是舊值，在另一主機上是新值的情況。為了數據“一致”，在一個用戶更新某個數據時，其他的用戶請求必須等待前面的用戶在全部主機上完成操作后才可以訪問，否則就可能出現訪問結果不一致的情況。這種等待的時間越長，自然系統的效率就越低。如果縮短等待時間，效率會提高，但是有可能上一個用戶還沒有完成全部操作，數據就出現不一致。所以，一致性和高效性就成為一對避不開的矛盾。

好的算法自然是把這兩項都能提高，就是在保證數據安全的前提下，盡量縮短一個用戶占用全部主機資源的時間。紅鎖就是一個比較好的解決方案。其原理如下：

假設系統中有7臺主機，設一個設鎖的有效時間作為最長允許用時。用戶發出更新請求。

開始計時從第1個到第7個主機挨個加鎖，其中：如果某個主機加鎖的時間超過預定時間（如：50毫秒），則認為此主機已經不可用，立即放棄并進入下一個主機加鎖。如果在嘗試7個主機后，只有3個或更少的主機加鎖成功（少于N/2+1），則認為本次加鎖失敗，將成功加鎖的主機立即去除鎖，返回用戶，報告加鎖失敗。如果全部加鎖完畢后所用的時間小于最初設定的有效時間，并且加鎖的主機數超過一半（4臺或更多），則認為加鎖成功。反之，則認為加鎖失敗。其他的用戶不定時的發出加鎖請求，一旦請求成功則進入新的加鎖程序。

“加鎖”，就是用戶給主機設一個特定的屬性值Key，同一個用戶的Key在所有的7臺主機是一樣的，其對應的屬性值是隨機產生的值。當Key在預定時間內過半數的主機成功設定，則鎖就加上了。如果想解鎖，就將這個Key值刪除。用戶想給主機加鎖，要先檢查Key是否已經存在。如果Key已經設了值，而這個值不是這個用戶自己設定的，就放棄加鎖，等待一段時間后再來嘗試，直到Key是空值了就可以設定新的Key值來加鎖。

紅鎖這樣設定，是保證系統里一臺或多臺主機宕機了，設鎖的程序仍然可以繼續而不至于導致整個程序夯停。另外每個用戶申請程序的等待時間也是隨機的，可以避免多個用戶在同一時刻申請加鎖導致程序死鎖。這樣系統鎖的排他性就可以保證了。同時，系統處理并發的效率也比較高。

好了，本文到此結束，如果可以幫助到大家，還望關注本站哦！