redis分布式鎖及會(huì)出現(xiàn)的問題解決
一、redis實(shí)現(xiàn)分布式鎖的主要原理:
1.加鎖
最簡單的方法是使用setnx命令。key是鎖的唯一標(biāo)識,按業(yè)務(wù)來決定命名。比如想要給一種商品的秒殺活動(dòng)加鎖,可以給key命名為 “l(fā)ock_sale_商品ID” 。而value設(shè)置成什么呢?我們可以姑且設(shè)置成1。加鎖的偽代碼如下:
setnx(key,1)
當(dāng)一個(gè)線程執(zhí)行setnx返回1,說明key原本不存在,該線程成功得到了鎖;當(dāng)一個(gè)線程執(zhí)行setnx返回0,說明key已經(jīng)存在,該線程搶鎖失敗。
2.解鎖
有加鎖就得有解鎖。當(dāng)?shù)玫芥i的線程執(zhí)行完任務(wù),需要釋放鎖,以便其他線程可以進(jìn)入。釋放鎖的最簡單方式是執(zhí)行del指令,偽代碼如下:
del(key)
釋放鎖之后,其他線程就可以繼續(xù)執(zhí)行setnx命令來獲得鎖。
3.鎖超時(shí)
鎖超時(shí)是什么意思呢?如果一個(gè)得到鎖的線程在執(zhí)行任務(wù)的過程中掛掉,來不及顯式地釋放鎖,這塊資源將會(huì)永遠(yuǎn)被鎖住,別的線程再也別想進(jìn)來。
所以,setnx的key必須設(shè)置一個(gè)超時(shí)時(shí)間,以保證即使沒有被顯式釋放,這把鎖也要在一定時(shí)間后自動(dòng)釋放。setnx不支持超時(shí)參數(shù),所以需要額外的指令,偽代碼如下:
expire(key, 30)
二、加鎖的代碼
/**
* 嘗試獲取分布式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標(biāo)識
* @param expireTime 超期時(shí)間
* @return 是否獲取成功
*/
public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
Long result = jedis.setnx(lockKey, requestId);
if (result == 1) {
// 若在這里程序突然崩潰,則無法設(shè)置過期時(shí)間,將發(fā)生死鎖
jedis.expire(lockKey, expireTime);
}
}
上面的代碼有一個(gè)致命的問題,就是加鎖和設(shè)置過期時(shí)間不是原子操作。
那么會(huì)有兩種極端情況:
一種是在并發(fā)情況下,兩個(gè)線程同時(shí)執(zhí)行setnx,那么得到的結(jié)果都是1,這樣兩個(gè)線程同時(shí)拿到了鎖。
別一種是如代碼注釋所示,即執(zhí)行完setnx,程序崩潰沒有執(zhí)行過期時(shí)間,那這把鎖就永遠(yuǎn)不會(huì)被釋放,造成了死鎖。
之所以有人這樣實(shí)現(xiàn),是因?yàn)榈桶姹镜膉edis并不支持多參數(shù)的set()方法。正確的代碼如下:
/**
* 嘗試獲取分布式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標(biāo)識
* @param expireTime 超期時(shí)間
* @return 是否獲取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis,String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
}
這個(gè)set()方法一共有五個(gè)形參:
第一個(gè)為key,我們使用key來當(dāng)鎖,因?yàn)閗ey是唯一的。
第二個(gè)為value,我們傳的是requestId,很多童鞋可能不明白,有key作為鎖不就夠了嗎,為什么還要用到value?原因就是,通過給value賦值為requestId,我們就知道這把鎖是哪個(gè)請求加的了,在解鎖的時(shí)候就可以有依據(jù)。requestId可以使用UUID.randomUUID().toString()方法生成。
第三個(gè)為nxxx,這個(gè)參數(shù)我們填的是NX,意思是SET IF NOT EXIST,即當(dāng)key不存在時(shí),我們進(jìn)行set操作;若key已經(jīng)存在,則不做任何操作;
第四個(gè)為expx,這個(gè)參數(shù)我們傳的是PX,意思是我們要給這個(gè)key加一個(gè)過期的設(shè)置,具體時(shí)間由第五個(gè)參數(shù)決定。
第五個(gè)為time,與第四個(gè)參數(shù)相呼應(yīng),代表key的過期時(shí)間。
總的來說,執(zhí)行上面的set()方法就只會(huì)導(dǎo)致兩種結(jié)果:1. 當(dāng)前沒有鎖(key不存在),那么就進(jìn)行加鎖操作,并對鎖設(shè)置個(gè)有效期,同時(shí)value表示加鎖的客戶端。2. 已有鎖存在,不做任何操作。
二、解鎖的代碼
public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
jedis.del(lockKey);
}
這段代碼的問題是容易導(dǎo)致誤刪,假如某線程成功得到了鎖,并且設(shè)置的超時(shí)時(shí)間是30秒。如果某些原因?qū)е戮€程A執(zhí)行的很慢很慢,過了30秒都沒執(zhí)行完,這時(shí)候鎖過期自動(dòng)釋放,線程B得到了鎖。
隨后,線程A執(zhí)行完了任務(wù),線程A接著執(zhí)行del指令來釋放鎖。但這時(shí)候線程B還沒執(zhí)行完,線程A實(shí)際上刪除的是線程B加的鎖。
怎么避免這種情況呢?可以在del釋放鎖之前做一個(gè)判斷,驗(yàn)證當(dāng)前的鎖是不是自己加的鎖。
至于具體的實(shí)現(xiàn),可以在加鎖的時(shí)候把當(dāng)前的線程ID當(dāng)做value,并在刪除之前驗(yàn)證key對應(yīng)的value是不是自己線程的ID。
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
// 判斷加鎖與解鎖是不是同一個(gè)客戶端
if (requestId.equals(jedis.get(lockKey))) {
// 若在此時(shí),這把鎖突然不是這個(gè)客戶端的,則會(huì)誤解鎖
jedis.del(lockKey);
}
}
但是,這樣做又隱含了一個(gè)新的問題,判斷和釋放鎖是兩個(gè)獨(dú)立操作,不是原子性。
解決方案就是使用lua腳本,把它變成原子操作,代碼如下:
public class RedisTool {
private static final Long RELEASE_SUCCESS = 1L;
/**
* 釋放分布式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標(biāo)識
* @return 是否釋放成功
*/
public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
}
三、續(xù)約問題
上面加鎖最后的代碼就完美了嗎?假想這樣一個(gè)場景,如果過期時(shí)間為30S,A線程超過30S還沒執(zhí)行完,但是自動(dòng)過期了。這時(shí)候B線程就會(huì)再拿到鎖,造成了同時(shí)有兩個(gè)線程持有鎖。這個(gè)問題可以歸結(jié)為”續(xù)約“問題,即A沒執(zhí)行完時(shí)應(yīng)該過期時(shí)間續(xù)約,執(zhí)行完成才能釋放鎖。怎么辦呢?我們可以讓獲得鎖的線程開啟一個(gè)守護(hù)線程,用來給快要過期的鎖“續(xù)約”。
其實(shí),后面解鎖出現(xiàn)的刪除非自己鎖,也屬于“續(xù)約”問題。
四、集群同步延遲問題
用于redis的服務(wù)肯定不能是單機(jī),因?yàn)閱螜C(jī)就不是高可用了,一量掛掉整個(gè)分布式鎖就沒用了。
在集群場景下,如果A在master拿到了鎖,在沒有把數(shù)據(jù)同步到slave時(shí),master掛掉了。B再拿鎖就會(huì)從slave拿鎖,而且會(huì)拿到。又出現(xiàn)了兩個(gè)線程同時(shí)拿到鎖。
基于以上的考慮,Redis 的作者也考慮到這個(gè)問題,他提出了一個(gè) RedLock 的算法。
這個(gè)算法的意思大概是這樣的:假設(shè) Redis 的部署模式是 Redis Cluster,總共有 5 個(gè) Master 節(jié)點(diǎn)。
通過以下步驟獲取一把鎖:
- 獲取當(dāng)前時(shí)間戳,單位是毫秒。
- 輪流嘗試在每個(gè) Master 節(jié)點(diǎn)上創(chuàng)建鎖,過期時(shí)間設(shè)置較短,一般就幾十毫秒。
- 嘗試在大多數(shù)節(jié)點(diǎn)上建立一個(gè)鎖,比如 5 個(gè)節(jié)點(diǎn)就要求是 3 個(gè)節(jié)點(diǎn)(n / 2 +1)。
- 客戶端計(jì)算建立好鎖的時(shí)間,如果建立鎖的時(shí)間小于超時(shí)時(shí)間,就算建立成功了。
- 要是鎖建立失敗了,那么就依次刪除這個(gè)鎖。
- 只要?jiǎng)e人建立了一把分布式鎖,你就得不斷輪詢?nèi)L試獲取鎖。
但是這樣的這種算法還是頗具爭議的,可能還會(huì)存在不少的問題,無法保證加鎖的過程一定正確。
這個(gè)問題的根本原因就是redis的集群屬于AP,分布式鎖屬于CP,用AP去實(shí)現(xiàn)CP是不可能的。
五、Redisson
Redisson是架設(shè)在Redis基礎(chǔ)上的一個(gè)Java駐內(nèi)存數(shù)據(jù)網(wǎng)格(In-Memory Data Grid)。充分的利用了Redis鍵值數(shù)據(jù)庫提供的一系列優(yōu)勢,基于Java實(shí)用工具包中常用接口,為使用者提供了一系列具有分布式特性的常用工具類。
Redisson通過lua腳本解決了上面的原子性問題,通過“看門狗”解決了續(xù)約問題,但是它應(yīng)該解決不了集群中的同步延遲問題。
總結(jié)
redis分布式鎖的方案,無論用何種方式實(shí)現(xiàn)都會(huì)有續(xù)約問題與集群同步延遲問題。總的來說,是一個(gè)不太靠譜的方案。如果追求高正確率,不能采用這種方案。
但是它也有優(yōu)點(diǎn),就是比較簡單,在某些非嚴(yán)格要求的場景是可以使用的,比如社交系統(tǒng)一類,交易系統(tǒng)一類不能出現(xiàn)重復(fù)交易則不建議用。
到此這篇關(guān)于redis分布式鎖及會(huì)出現(xiàn)的問題解決的文章就介紹到這了,更多相關(guān)redis分布式鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- SpringBoot集成redis與session實(shí)現(xiàn)分布式單點(diǎn)登錄
- redis中使用java腳本實(shí)現(xiàn)分布式鎖
- Redis實(shí)現(xiàn)分布式鎖的幾種方法總結(jié)
- 基于Redis實(shí)現(xiàn)分布式鎖以及任務(wù)隊(duì)列
- Redis分布式鎖的實(shí)現(xiàn)方式(redis面試題)
- Redis實(shí)現(xiàn)分布式鎖的五種方法詳解
- 淺談Redis分布式鎖的正確實(shí)現(xiàn)方式
- Redis分布式鎖實(shí)現(xiàn)方式及超時(shí)問題解決
- Redis基于Session實(shí)現(xiàn)分布式登錄的示例代碼
相關(guān)文章
Redis延遲隊(duì)列的實(shí)現(xiàn)示例
Redis 延遲隊(duì)列是一種使用 Redis 實(shí)現(xiàn)的消息隊(duì)列,本文主要介紹了Redis延遲隊(duì)列的實(shí)現(xiàn)示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2025-01-01
基于Redis實(shí)現(xiàn)API接口訪問次數(shù)限制
日常開發(fā)中會(huì)有一個(gè)常見的需求,需要限制接口在單位時(shí)間內(nèi)的訪問次數(shù),比如說某個(gè)免費(fèi)的接口限制單個(gè)IP一分鐘內(nèi)只能訪問5次,該怎么實(shí)現(xiàn)呢,本文小編給大家介紹了如何基于Redis實(shí)現(xiàn)API接口訪問次數(shù)限制,需要的朋友可以參考下2024-11-11
redis中hiredis-API函數(shù)的調(diào)用方法
這篇文章主要介紹了redis中hiredis-API函數(shù)的調(diào)用,本文通過示例代碼給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友參考下吧2023-09-09
如何基于Session實(shí)現(xiàn)短信登錄功能
對比起Cookie,Session是存儲(chǔ)在服務(wù)器端的會(huì)話,相對安全,并且不像Cookie那樣有存儲(chǔ)長度限制,下面這篇文章主要給大家介紹了關(guān)于如何基于Session實(shí)現(xiàn)短信登錄功能的相關(guān)資料,需要的朋友可以參考下2022-10-10
redis使用zset實(shí)現(xiàn)延時(shí)隊(duì)列的示例代碼
本文主要介紹了redis使用zset實(shí)現(xiàn)延時(shí)隊(duì)列的示例代碼,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06

