香蕉aa三级久久毛片,国产99久久精品一区二区,久久久久亚洲AV成人片

本篇文章給大家介紹一下redis中的分布式鎖，介紹一下為什么需要分布式鎖，redis是如何實現(xiàn)分布式鎖的，希望對大家有所幫助！

Redis中為什么需要分布式鎖？如何實現(xiàn)？

為什么需要分布式鎖

為什么需要分布式鎖

使用分布式鎖的目的，無外乎就是保證同一時間只有一個客戶端可以對共享資源進行操作。

我們在分布式應用進行邏輯處理時經(jīng)常會遇到并發(fā)問題。【相關(guān)推薦：Redis視頻教程】

比如一個操作要修改用戶的狀態(tài)，修改狀態(tài)需要先讀出用戶的狀態(tài)，在內(nèi)存里進行修改，改完了再存回去。如果這樣的操作同時進行了，就會出現(xiàn)并發(fā)問題，因為讀取和保存狀態(tài)這兩個操作不是原子的。

這個時候就要使用到分布式鎖來限制程序的并發(fā)執(zhí)行。redis作為一個緩存中間件系統(tǒng)，就能提供這種分布式鎖機制，

其本質(zhì)就是在redis里面占一個坑，當別的進程也要來占坑時，發(fā)現(xiàn)已經(jīng)被占領(lǐng)了，就只要等待稍后再嘗試

一般來說，生產(chǎn)環(huán)境可用的分布式鎖需要滿足以下幾點：

互斥性，互斥是鎖的基本特征，同一時刻只能有一個線程持有鎖，執(zhí)行臨界操作；
超時釋放，超時釋放是鎖的另一個必備特性，可以對比 MySQL InnoDB 引擎中的 innodb_lock_wait_timeout配置，通過超時釋放，防止不必要的線程等待和資源浪費；
可重入性，在分布式環(huán)境下，同一個節(jié)點上的同一個線程如果獲取了鎖之后，再次請求還是可以成功；

實現(xiàn)方式

使用SETNX實現(xiàn)

SETNX的使用方式為：SETNX key value，只在鍵key不存在的情況下，將鍵key的值設(shè)置為value，若鍵key存在，則SETNX不做任何動作。

boolean?result?=?jedis.setnx("lock-key",true)==?1L; if??(result)?{ ????try?{ ????????//?do?something ????}?finally?{ ????????jedis.del("lock-key"); ????} ?}

這種方案有一個致命問題，就是某個線程在獲取鎖之后由于某些異常因素（比如宕機）而不能正常的執(zhí)行解鎖操作，那么這個鎖就永遠釋放不掉了。

為此，我們可以為這個鎖加上一個超時時間

執(zhí)行 SET key value EX seconds 的效果等同于執(zhí)行 SETEX key seconds value

執(zhí)行 SET key value PX milliseconds 的效果等同于執(zhí)行 PSETEX key milliseconds value

String?result?=?jedis.set("lock-key",true,?5); if?("OK".equals(result))?{ ????try?{ ????????//?do?something ????}?finally?{ ????????jedis.del("lock-key"); ????} }

方案看上去很完美，但實際上還是會有問題

試想一下，某線程A獲取了鎖并且設(shè)置了過期時間為10s，然后在執(zhí)行業(yè)務邏輯的時候耗費了15s，此時線程A獲取的鎖早已被Redis的過期機制自動釋放了

在線程A獲取鎖并經(jīng)過10s之后，改鎖可能已經(jīng)被其它線程獲取到了。當線程A執(zhí)行完業(yè)務邏輯準備解鎖（DEL key）的時候，有可能刪除掉的是其它線程已經(jīng)獲取到的鎖。

所以最好的方式是在解鎖時判斷鎖是否是自己的，我們可以在設(shè)置key的時候?qū)alue設(shè)置為一個唯一值uniqueValue（可以是隨機值、UUID、或者機器號+線程號的組合、簽名等）。

當解鎖時，也就是刪除key的時候先判斷一下key對應的value是否等于先前設(shè)置的值，如果相等才能刪除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執(zhí)行之后且在DEL執(zhí)行之前的間隙是可能會發(fā)生異常的。

如果我們只要保證解鎖的代碼是原子性的就能解決問題了

這里我們引入了一種新的方式，就是Lua腳本，示例如下：

if?redis.call("get",KEYS[1])?==?ARGV[1]?then ????return?redis.call("del",KEYS[1]) else ????return?0 end

其中ARGV[1]表示設(shè)置key時指定的唯一值。

由于Lua腳本的原子性，在Redis執(zhí)行該腳本的過程中，其他客戶端的命令都需要等待該Lua腳本執(zhí)行完才能執(zhí)行。

確保過期時間大于業(yè)務執(zhí)行時間

為了防止多個線程同時執(zhí)行業(yè)務代碼，需要確保過期時間大于業(yè)務執(zhí)行時間

增加一個boolean類型的屬性isOpenExpirationRenewal，用來標識是否開啟定時刷新過期時間

在增加一個scheduleExpirationRenewal方法用于開啟刷新過期時間的線程

加鎖代碼在獲取鎖成功后將isOpenExpirationRenewal置為true，并且調(diào)用scheduleExpirationRenewal方法，開啟刷新過期時間的線程

解鎖代碼增加一行代碼，將isOpenExpirationRenewal屬性置為false，停止刷新過期時間的線程輪詢

Redisson實現(xiàn)

獲取鎖成功就會開啟一個定時任務,定時任務會定期檢查去續(xù)期

該定時調(diào)度每次調(diào)用的時間差是internalLockLeaseTime / 3,也就10秒

默認情況下,加鎖的時間是30秒.如果加鎖的業(yè)務沒有執(zhí)行完,那么到 30-10 = 20秒的時候,就會進行一次續(xù)期,把鎖重置成30秒

RedLock

在集群中，主節(jié)點掛掉時，從節(jié)點會取而代之，客戶端上卻并沒有明顯感知。原先第一個客戶端在主節(jié)點中申請成功了一把鎖，但是這把鎖還沒有來得及同步到從節(jié)點，主節(jié)點突然掛掉了。然后從節(jié)點變成了主節(jié)點，這個新的節(jié)點內(nèi)部沒有這個鎖，所以當另一個客戶端過來請求加鎖時，立即就批準了。這樣就會導致系統(tǒng)中同樣一把鎖被兩個客戶端同時持有，不安全性由此產(chǎn)生

Redlock算法就是為了解決這個問題

使用 Redlock，需要提供多個 Redis 實例，這些實例之前相互獨立沒有主從關(guān)系。同很多分布式算法一樣，redlock 也使用大多數(shù)機制

加鎖時，它會向過半節(jié)點發(fā)送 set指令，只要過半節(jié)點 set 成功，那就認為加鎖成功。釋放鎖時，需要向所有節(jié)點發(fā)送 del 指令。不過 Redlock 算法還需要考慮出錯重試、時鐘漂移等很多細節(jié)問題，同時因為 Redlock 需要向多個節(jié)點進行讀寫，意味著相比單實例 Redis 性能會下降一些

Redlock 算法是在單 Redis 節(jié)點基礎(chǔ)上引入的高可用模式，Redlock 基于 N 個完全獨立的 Redis 節(jié)點，一般是大于 3 的奇數(shù)個（通常情況下 N 可以設(shè)置為 5），可以基本保證集群內(nèi)各個節(jié)點不會同時宕機。

假設(shè)當前集群有 5 個節(jié)點，運行 Redlock 算法的客戶端依次執(zhí)行下面各個步驟，來完成獲取鎖的操作

客戶端記錄當前系統(tǒng)時間，以毫秒為單位；
依次嘗試從 5 個 Redis 實例中，使用相同的 key 獲取鎖，當向 Redis 請求獲取鎖時，客戶端應該設(shè)置一個網(wǎng)絡連接和響應超時時間，超時時間應該小于鎖的失效時間，避免因為網(wǎng)絡故障出現(xiàn)的問題；
客戶端使用當前時間減去開始獲取鎖時間就得到了獲取鎖使用的時間，當且僅當從半數(shù)以上的 Redis 節(jié)點獲取到鎖，并且當使用的時間小于鎖失效時間時，鎖才算獲取成功；
如果獲取到了鎖，key 的真正有效時間等于有效時間減去獲取鎖所使用的時間，減少超時的幾率；
如果獲取鎖失敗，客戶端應該在所有的 Redis 實例上進行解鎖，即使是上一步操作請求失敗的節(jié)點，防止因為服務端響應消息丟失，但是實際數(shù)據(jù)添加成功導致的不一致。

也就是說，假設(shè)鎖30秒過期，三個節(jié)點加鎖花了31秒，自然是加鎖失敗了

在 Redis 官方推薦的 Java 客戶端 Redisson 中，內(nèi)置了對 RedLock 的實現(xiàn)