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

redissession分布式鎖原理

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

如何使用RedLock實現(xiàn)分布式鎖

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

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

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

假設(shè)系統(tǒng)中有7臺主機，設(shè)一個設(shè)鎖的有效時間作為最長允許用時。用戶發(fā)出更新請求。

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

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

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

好了，本文到此結(jié)束，如果可以幫助到大家，還望關(guān)注本站哦！