欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Redis分布式鎖Redlock的實(shí)現(xiàn)

 更新時(shí)間:2021年08月05日 10:42:22   作者:阿飛的博客  
本文主要介紹了Redis分布式鎖Redlock的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下

普通實(shí)現(xiàn)

說(shuō)道Redis分布式鎖大部分人都會(huì)想到:setnx+lua,或者知道set key value px milliseconds nx。后一種方式的核心實(shí)現(xiàn)命令如下:

- 獲取鎖(unique_value可以是UUID等)
SET resource_name unique_value NX PX 30000

- 釋放鎖(lua腳本中,一定要比較value,防止誤解鎖)
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

這種實(shí)現(xiàn)方式有3大要點(diǎn)(也是面試概率非常高的地方):

  • set命令要用set key value px milliseconds nx;
  • value要具有唯一性;
  • 釋放鎖時(shí)要驗(yàn)證value值,不能誤解鎖;

事實(shí)上這類(lèi)瑣最大的缺點(diǎn)就是它加鎖時(shí)只作用在一個(gè)Redis節(jié)點(diǎn)上,即使Redis通過(guò)sentinel保證高可用,如果這個(gè)master節(jié)點(diǎn)由于某些原因發(fā)生了主從切換,那么就會(huì)出現(xiàn)鎖丟失的情況:

  1. 在Redis的master節(jié)點(diǎn)上拿到了鎖;
  2. 但是這個(gè)加鎖的key還沒(méi)有同步到slave節(jié)點(diǎn);
  3. master故障,發(fā)生故障轉(zhuǎn)移,slave節(jié)點(diǎn)升級(jí)為master節(jié)點(diǎn);
  4. 導(dǎo)致鎖丟失。

正因?yàn)槿绱耍琑edis作者antirez基于分布式環(huán)境下提出了一種更高級(jí)的分布式鎖的實(shí)現(xiàn)方式:Redlock。筆者認(rèn)為,Redlock也是Redis所有分布式鎖實(shí)現(xiàn)方式中唯一能讓面試官高潮的方式。

Redlock實(shí)現(xiàn)

antirez提出的redlock算法大概是這樣的:

在Redis的分布式環(huán)境中,我們假設(shè)有N個(gè)Redis master。這些節(jié)點(diǎn)完全互相獨(dú)立,不存在主從復(fù)制或者其他集群協(xié)調(diào)機(jī)制。我們確保將在N個(gè)實(shí)例上使用與在Redis單實(shí)例下相同方法獲取和釋放鎖?,F(xiàn)在我們假設(shè)有5個(gè)Redis master節(jié)點(diǎn),同時(shí)我們需要在5臺(tái)服務(wù)器上面運(yùn)行這些Redis實(shí)例,這樣保證他們不會(huì)同時(shí)都宕掉。

為了取到鎖,客戶(hù)端應(yīng)該執(zhí)行以下操作:

  • 獲取當(dāng)前Unix時(shí)間,以毫秒為單位。
  • 依次嘗試從5個(gè)實(shí)例,使用相同的key和具有唯一性的value(例如UUID)獲取鎖。當(dāng)向Redis請(qǐng)求獲取鎖時(shí),客戶(hù)端應(yīng)該設(shè)置一個(gè)網(wǎng)絡(luò)連接和響應(yīng)超時(shí)時(shí)間,這個(gè)超時(shí)時(shí)間應(yīng)該小于鎖的失效時(shí)間。例如你的鎖自動(dòng)失效時(shí)間為10秒,則超時(shí)時(shí)間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下,客戶(hù)端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒(méi)有在規(guī)定時(shí)間內(nèi)響應(yīng),客戶(hù)端應(yīng)該盡快嘗試去另外一個(gè)Redis實(shí)例請(qǐng)求獲取鎖。
  • 客戶(hù)端使用當(dāng)前時(shí)間減去開(kāi)始獲取鎖時(shí)間(步驟1記錄的時(shí)間)就得到獲取鎖使用的時(shí)間。當(dāng)且僅當(dāng)從大多數(shù)(N/2+1,這里是3個(gè)節(jié)點(diǎn))的Redis節(jié)點(diǎn)都取到鎖,并且使用的時(shí)間小于鎖失效時(shí)間時(shí),鎖才算獲取成功。
  • 如果取到了鎖,key的真正有效時(shí)間等于有效時(shí)間減去獲取鎖所使用的時(shí)間(步驟3計(jì)算的結(jié)果)。
  • 如果因?yàn)槟承┰颍@取鎖失?。](méi)有在至少N/2+1個(gè)Redis實(shí)例取到鎖或者取鎖時(shí)間已經(jīng)超過(guò)了有效時(shí)間),客戶(hù)端應(yīng)該在所有的Redis實(shí)例上進(jìn)行解鎖(即便某些Redis實(shí)例根本就沒(méi)有加鎖成功,防止某些節(jié)點(diǎn)獲取到鎖但是客戶(hù)端沒(méi)有得到響應(yīng)而導(dǎo)致接下來(lái)的一段時(shí)間不能被重新獲取鎖)。

Redlock源碼

redisson已經(jīng)有對(duì)redlock算法封裝,接下來(lái)對(duì)其用法進(jìn)行簡(jiǎn)單介紹,并對(duì)核心源碼進(jìn)行分析(假設(shè)5個(gè)redis實(shí)例)。

POM依賴(lài)

<!-- https://mvnrepository.com/artifact/org.redisson/redisson -->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.3.2</version>
</dependency>

用法

首先,我們來(lái)看一下redission封裝的redlock算法實(shí)現(xiàn)的分布式鎖用法,非常簡(jiǎn)單,跟重入鎖(ReentrantLock)有點(diǎn)類(lèi)似:

Config config = new Config();
config.useSentinelServers().addSentinelAddress("127.0.0.1:6369","127.0.0.1:6379", "127.0.0.1:6389")
        .setMasterName("masterName")
        .setPassword("password").setDatabase(0);
RedissonClient redissonClient = Redisson.create(config);
// 還可以getFairLock(), getReadWriteLock()
RLock redLock = redissonClient.getLock("REDLOCK_KEY");
boolean isLock;
try {
    isLock = redLock.tryLock();
    // 500ms拿不到鎖, 就認(rèn)為獲取鎖失敗。10000ms即10s是鎖失效時(shí)間。
    isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS);
    if (isLock) {
        //TODO if get lock success, do something;
    }
} catch (Exception e) {
} finally {
    // 無(wú)論如何, 最后都要解鎖
    redLock.unlock();
}

唯一ID

實(shí)現(xiàn)分布式鎖的一個(gè)非常重要的點(diǎn)就是set的value要具有唯一性,redisson的value是怎樣保證value的唯一性呢?答案是UUID+threadId。入口在redissonClient.getLock("REDLOCK_KEY"),源碼在Redisson.java和RedissonLock.java中:

protected final UUID id = UUID.randomUUID();
String getLockName(long threadId) {
    return id + ":" + threadId;
}

獲取鎖

獲取鎖的代碼為redLock.tryLock()或者redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS),兩者的最終核心源碼都是下面這段代碼,只不過(guò)前者獲取鎖的默認(rèn)租約時(shí)間(leaseTime)是LOCK_EXPIRATION_INTERVAL_SECONDS,即30s:

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    internalLockLeaseTime = unit.toMillis(leaseTime);
    // 獲取鎖時(shí)向5個(gè)redis實(shí)例發(fā)送的命令
    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
              // 首先分布式鎖的KEY不能存在,如果確實(shí)不存在,那么執(zhí)行hset命令(hset REDLOCK_KEY uuid+threadId 1),并通過(guò)pexpire設(shè)置失效時(shí)間(也是鎖的租約時(shí)間)
              "if (redis.call('exists', KEYS[1]) == 0) then " +
                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              // 如果分布式鎖的KEY已經(jīng)存在,并且value也匹配,表示是當(dāng)前線(xiàn)程持有的鎖,那么重入次數(shù)加1,并且設(shè)置失效時(shí)間
              "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                  "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              // 獲取分布式鎖的KEY的失效時(shí)間毫秒數(shù)
              "return redis.call('pttl', KEYS[1]);",
              // 這三個(gè)參數(shù)分別對(duì)應(yīng)KEYS[1],ARGV[1]和ARGV[2]
                Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
}

獲取鎖的命令中,

  • KEYS[1]就是Collections.singletonList(getName()),表示分布式鎖的key,即REDLOCK_KEY;
  • ARGV[1]就是internalLockLeaseTime,即鎖的租約時(shí)間,默認(rèn)30s;
  • ARGV[2]就是getLockName(threadId),是獲取鎖時(shí)set的唯一值,即UUID+threadId:

釋放鎖

釋放鎖的代碼為redLock.unlock(),核心源碼如下:

protected RFuture<Boolean> unlockInnerAsync(long threadId) {
    // 向5個(gè)redis實(shí)例都執(zhí)行如下命令
    return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
            // 如果分布式鎖KEY不存在,那么向channel發(fā)布一條消息
            "if (redis.call('exists', KEYS[1]) == 0) then " +
                "redis.call('publish', KEYS[2], ARGV[1]); " +
                "return 1; " +
            "end;" +
            // 如果分布式鎖存在,但是value不匹配,表示鎖已經(jīng)被占用,那么直接返回
            "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
                "return nil;" +
            "end; " +
            // 如果就是當(dāng)前線(xiàn)程占有分布式鎖,那么將重入次數(shù)減1
            "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
            // 重入次數(shù)減1后的值如果大于0,表示分布式鎖有重入過(guò),那么只設(shè)置失效時(shí)間,還不能刪除
            "if (counter > 0) then " +
                "redis.call('pexpire', KEYS[1], ARGV[2]); " +
                "return 0; " +
            "else " +
                // 重入次數(shù)減1后的值如果為0,表示分布式鎖只獲取過(guò)1次,那么刪除這個(gè)KEY,并發(fā)布解鎖消息
                "redis.call('del', KEYS[1]); " +
                "redis.call('publish', KEYS[2], ARGV[1]); " +
                "return 1; "+
            "end; " +
            "return nil;",
            // 這5個(gè)參數(shù)分別對(duì)應(yīng)KEYS[1],KEYS[2],ARGV[1],ARGV[2]和ARGV[3]
            Arrays.<Object>asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(threadId));

}

參考:https://redis.io/topics/distlock

到此這篇關(guān)于Redis分布式鎖Redlock的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)Redis分布式鎖Redlock內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • 詳解Redis 緩存刪除機(jī)制(源碼解析)

    詳解Redis 緩存刪除機(jī)制(源碼解析)

    這篇文章主要介紹了Redis 緩存刪除機(jī)制(源碼解析),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2021-03-03
  • Redis key鍵的具體使用

    Redis key鍵的具體使用

    Redis 是一種鍵值(key-value)型的緩存型數(shù)據(jù)庫(kù),它將數(shù)據(jù)全部以鍵值對(duì)的形式存儲(chǔ)在內(nèi)存中,本文就來(lái)介紹一下key鍵的具體使用,感興趣的可以了解一下
    2024-02-02
  • Redis數(shù)據(jù)庫(kù)安裝部署及基本操作詳解

    Redis數(shù)據(jù)庫(kù)安裝部署及基本操作詳解

    這篇文章主要介紹了Redis數(shù)據(jù)庫(kù)安裝部署及基本操作,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2021-08-08
  • Redis中的連接命令與鍵命令操作詳解

    Redis中的連接命令與鍵命令操作詳解

    Redis連接命令主要是用于客戶(hù)端與服務(wù)器建立連接的,Redis是一種流行的內(nèi)存數(shù)據(jù)庫(kù),支持多種數(shù)據(jù)結(jié)構(gòu),其中鍵命令是核心操作之一,在Redis中,鍵(Key)是用來(lái)存儲(chǔ)數(shù)據(jù)的主要元素,每個(gè)鍵都有一個(gè)唯一的名稱(chēng),本文給大家介紹了Redis中的連接命令與鍵命令操作
    2024-09-09
  • Redis實(shí)現(xiàn)附近商鋪的項(xiàng)目實(shí)戰(zhàn)

    Redis實(shí)現(xiàn)附近商鋪的項(xiàng)目實(shí)戰(zhàn)

    本文主要介紹了Redis實(shí)現(xiàn)附近商鋪的項(xiàng)目實(shí)戰(zhàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2023-01-01
  • 詳解Redis中的List是如何實(shí)現(xiàn)的

    詳解Redis中的List是如何實(shí)現(xiàn)的

    List 的 Redis 中的 5 種主要數(shù)據(jù)結(jié)構(gòu)之一,它是一種序列集合,可以存儲(chǔ)一個(gè)有序的字符串列表,順序是插入的順序,本文將給大家介紹了一下Redis中的List是如何實(shí)現(xiàn)的,需要的朋友可以參考下
    2024-05-05
  • Redis?的內(nèi)存淘汰策略和過(guò)期刪除策略的區(qū)別

    Redis?的內(nèi)存淘汰策略和過(guò)期刪除策略的區(qū)別

    這篇文章主要介紹了Redis?的內(nèi)存淘汰策略和過(guò)期刪除策略的區(qū)別,Redis?是可以對(duì)?key?設(shè)置過(guò)期時(shí)間的,因此需要有相應(yīng)的機(jī)制將已過(guò)期的鍵值對(duì)刪除,而做這個(gè)工作的就是過(guò)期鍵值刪除策略
    2022-07-07
  • 解決redis修改requirepass后不生效的問(wèn)題

    解決redis修改requirepass后不生效的問(wèn)題

    今天小編就為大家分享一篇解決redis修改requirepass后不生效的問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧
    2018-05-05
  • 詳解利用redis + lua解決搶紅包高并發(fā)的問(wèn)題

    詳解利用redis + lua解決搶紅包高并發(fā)的問(wèn)題

    本篇文章主要介紹了利用redis + lua解決搶紅包高并發(fā)的問(wèn)題 ,詳細(xì)的講訴了需求分析和方案,有興趣的可以了解一下。
    2016-11-11
  • 淺談Redis緩存擊穿、緩存穿透、緩存雪崩的解決方案

    淺談Redis緩存擊穿、緩存穿透、緩存雪崩的解決方案

    這篇文章主要介紹了淺談Redis緩存擊穿、緩存穿透、緩存雪崩的解決方案,緩存是分布式系統(tǒng)中的重要組件,主要解決在高并發(fā)、大數(shù)據(jù)場(chǎng)景下,熱點(diǎn)數(shù)據(jù)訪(fǎng)問(wèn)的性能問(wèn)題,需要的朋友可以參考下
    2023-03-03

最新評(píng)論