這篇文章跟大家介紹一下Redis中的分散式鎖，介紹一下為什麼需要分散式鎖，Redis是如何實現分散式鎖的，希望對大家有幫助！
#為什麼需要分散式鎖定
使用分散式鎖的目的，無外乎就是保證同一時間只有一個客戶端可以對共享資源進行操作。
我們在分散式應用程式進行邏輯處理時經常會遇到並發問題。 【相關推薦：Redis影片教學】
例如一個操作要修改使用者的狀態，修改狀態需要先讀出使用者的狀態，在記憶體裡進行修改，改完了再存回去。如果這樣的操作同時進行了，就會出現並發問題，因為讀取和保存狀態這兩個操作不是原子的。
這個時候就要使用到分散式鎖定來限製程式的並發執行。 redis作為快取中間件系統，就能提供這個分散式鎖定機制，
其本質就是在redis裡面佔一個坑，當別的進程也要來佔坑時，發現已經被佔領了，就只要等待稍後再嘗試
#一般來說，生產環境可用的分散式鎖定需要滿足以下幾點：
innodb_lock_wait_timeout配置，透過逾時釋放，防止不必要的執行緒等待和資源浪費；##使用SETNX實作
SETNX的使用方式為：SETNX key value，只在鍵key不存在的情況下，將鍵key的值設為value，若鍵key存在，則SETNX不做任何動作。
boolean result = jedis.setnx("lock-key",true)== 1L;
if (result) {
try {
// do something
} finally {
jedis.del("lock-key");
}
}SET key value EX seconds 的效果等同於執行SETEX key seconds value
SET key value PX milliseconds 的效果等於執行PSETEX key milliseconds value##<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">String result = jedis.set("lock-key",true, 5);
if ("OK".equals(result)) {
try {
// do something
} finally {
jedis.del("lock-key");
}
}</pre><div class="contentsignin">登入後複製</div></div>
試想一下，某線程A獲取了鎖並且設定了過期時間為10s，然後在執行業務邏輯的時候耗費了15s，此時線程A獲取的鎖早已被Redis的過期機制自動釋放了
在線程A獲取鎖並經過10s之後，改鎖可能已經被其它線程獲取到了。當執行緒A執行完業務邏輯準備解鎖（
DEL key）的時候，有可能刪除掉的是其它執行緒已經取得到的鎖定。 所以最好的方式是在解鎖時判斷鎖是否是自己的，我們可以在設定
#的時候將value設定為一個唯一值uniqueValue（可以是隨機值、UUID、或機器號線程號的組合、簽名等）。 當解鎖時，也就是刪除key的時候先判斷一下key對應的value是否等於先前設定的值，如果相等才能刪除key
String velue= String.valueOf(System.currentTimeMillis())
String result = jedis.set("lock-key",velue, 5);
if ("OK".equals(result)) {
try {
// do something
} finally {
//非原子操作
if(jedis.get("lock-key")==value){
jedis.del("lock-key");
}
}
}這裡我們一眼就可以看出問題來：
GET和DEL是兩個分開的操作，在GET執行之後且在DEL執行之前的間隙是可能會發生異常的。 如果我們只要保證解鎖的程式碼是原子性的就能解決問題了
這裡我們引入了一種新的方式，就是
Lua腳本，範例如下：if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
表示設定key時指定的唯一值。 由於Lua腳本的原子性，在Redis執行該腳本的過程中，其他客戶端的命令都需要等待該Lua腳本執行完才能執行。
為了防止多個執行緒同時執行業務程式碼，需要確保過期時間大於業務執行時間
#增加一個boolean類型的屬性
isOpenExpirationRenewal，用來標識是否開啟定時刷新過期時間在增加一個
#方法用於開啟刷新過期時間的執行緒 加鎖代碼在取得鎖定成功後將isOpenExpirationRenewal置為true，並且呼叫
方法，開啟刷新過期時間的執行緒解鎖碼增加一行程式碼，將isOpenExpirationRenewal屬性置為false，停止刷新過期時間的線程輪詢
獲取鎖定成功就會開啟一個定時任務,定時任務會定期檢查去續期
此定時調度每次呼叫的時間差是internalLockLeaseTime / 3,也就10秒
預設情況下,加鎖的時間是30秒.如果加鎖的業務沒有執行完,那麼到30-10 = 20秒的時候,就會進行一次續期,把鎖定重置成30秒
Redlock演算法就是為了解決這個問題
使用Redlock，需要提供多個Redis 實例，這些實例之前相互獨立沒有主從關係。同許多分散式演算法一樣，redlock 也使用大多數機制
set 成功，那就認為加鎖成功。釋放鎖定時，需要向所有節點發送 del 指令。不過Redlock 演算法還需要考慮出錯重試、時脈漂移等許多細節問題，同時因為Redlock 需要向多個節點進行讀寫，這意味著相較於單一實例Redis 效能會下降一些
假設目前叢集有5 個節點，執行Redlock 演算法的客戶端依序執行下面各個步驟，來完成取得鎖定的操作
Redisson 中，內建了對RedLock 的實作
#https://redis.io/topics/distlockhttps:// github.com/redisson/redisson/wiki
RedLock問題：
RedLock 只是保證了鎖的高可用性，並沒有保證鎖的正確性RedLock 是一個嚴重依賴系統時脈的分散式系統
Martin 對RedLock 的批評：本文轉載自：https://juejin.cn/post/7018968452136173576作者：心懷遠方更多程式相關知識，請訪問：
編程視頻！ ！
以上是Redis中為什麼需要分散式鎖？如何實現？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
