Redis分布式鎖正確的實(shí)現(xiàn)方法

2022-06-16 17:11 更新

分布式鎖一般有數(shù)據(jù)庫(kù)樂(lè)觀鎖、基于Redis的分布式鎖以及基于ZooKeeper的分布式鎖三種實(shí)現(xiàn)方式,而本文將為大家?guī)?lái)的就是第二種基于Redis的分布式鎖正確的實(shí)現(xiàn)方法,希望對(duì)大家會(huì)有所幫助。


可靠性

首先,想要保證分布式鎖可以使用,下面這四個(gè)條件是必須要滿足的:

1、互斥性。在任意時(shí)刻,只有一個(gè)客戶端能持有鎖。

2、不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒(méi)有主動(dòng)解鎖,也能保證后續(xù)其他客戶端能加鎖。

3、具有容錯(cuò)性。只要大部分的Redis節(jié)點(diǎn)正常運(yùn)行,客戶端就可以加鎖和解鎖。

4、解鈴還須系鈴人。加鎖和解鎖必須是同一個(gè)客戶端,客戶端自己不能把別人加的鎖給解了。


代碼實(shí)現(xiàn)

引入Jedis開(kāi)源組件

首先我們要通過(guò)Maven引入Jedis開(kāi)源組件,在pom.xml文件加入下面的代碼:

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>


加鎖代碼

正確代碼

Talk is cheap, show me the code。先展示代碼,再帶大家慢慢解釋為什么這樣實(shí)現(xiàn):

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 嘗試獲取分布式鎖
     * @param jedis Redis客戶端
     * @param lockKey 鎖
     * @param requestId 請(qǐng)求標(biāo)識(shí)
     * @param expireTime 超期時(shí)間
     * @return 是否獲取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

可以看到,我們加鎖就一行代碼:jedis.set(String key, String value, String nxxx, String expx, int time),這個(gè)set()方法一共有五個(gè)形參:

第一個(gè)為key,我們使用key來(lái)當(dāng)鎖,因?yàn)閗ey是唯一的。

第二個(gè)為value,我們傳的是requestId,很多童鞋可能不明白,有key作為鎖不就夠了嗎,為什么還要用到value?原因就是我們?cè)谏厦嬷v到可靠性時(shí),分布式鎖要滿足第四個(gè)條件解鈴還須系鈴人,通過(guò)給value賦值為requestId,我們就知道這把鎖是哪個(gè)請(qǐng)求加的了,在解鎖的時(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è)過(guò)期的設(shè)置,具體時(shí)間由第五個(gè)參數(shù)決定。

第五個(gè)為time,與第四個(gè)參數(shù)相呼應(yīng),代表key的過(guò)期時(shí)間。

總的來(lái)說(shuō),執(zhí)行上面的set()方法就只會(huì)導(dǎo)致兩種結(jié)果:

1. 當(dāng)前沒(méi)有鎖(key不存在),那么就進(jìn)行加鎖操作,并對(duì)鎖設(shè)置個(gè)有效期,同時(shí)value表示加鎖的客戶端。

2. 已有鎖存在,不做任何操作。


錯(cuò)誤示例1

比較常見(jiàn)的錯(cuò)誤示例就是使用jedis.setnx()和jedis.expire()組合實(shí)現(xiàn)加鎖,代碼如下:

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 若在這里程序突然崩潰,則無(wú)法設(shè)置過(guò)期時(shí)間,將發(fā)生死鎖
        jedis.expire(lockKey, expireTime);
    }
}

setnx()方法作用就是SET IF NOT EXIST,expire()方法就是給鎖加一個(gè)過(guò)期時(shí)間。乍一看好像和前面的set()方法結(jié)果一樣,然而由于這是兩條Redis命令,不具有原子性,如果程序在執(zhí)行完setnx()之后突然崩潰,導(dǎo)致鎖沒(méi)有設(shè)置過(guò)期時(shí)間。那么將會(huì)發(fā)生死鎖。網(wǎng)上之所以有人這樣實(shí)現(xiàn),是因?yàn)榈桶姹镜膉edis并不支持多參數(shù)的set()方法。


錯(cuò)誤示例2

這一種錯(cuò)誤示例就比較難以發(fā)現(xiàn)問(wèn)題,而且實(shí)現(xiàn)也比較復(fù)雜。實(shí)現(xiàn)思路:使用jedis.setnx()命令實(shí)現(xiàn)加鎖,其中key是鎖,value是鎖的過(guò)期時(shí)間。執(zhí)行過(guò)程:1. 通過(guò)setnx()方法嘗試加鎖,如果當(dāng)前鎖不存在,返回加鎖成功。2. 如果鎖已經(jīng)存在則獲取鎖的過(guò)期時(shí)間,和當(dāng)前時(shí)間比較,如果鎖已經(jīng)過(guò)期,則設(shè)置新的過(guò)期時(shí)間,返回加鎖成功。代碼如下:

public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {
    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);
    // 如果當(dāng)前鎖不存在,返回加鎖成功
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }
    // 如果鎖存在,獲取鎖的過(guò)期時(shí)間
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 鎖已過(guò)期,獲取上一個(gè)鎖的過(guò)期時(shí)間,并設(shè)置現(xiàn)在鎖的過(guò)期時(shí)間
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 考慮多線程并發(fā)的情況,只有一個(gè)線程的設(shè)置值和當(dāng)前值相同,它才有權(quán)利加鎖
            return true;
        }
    }
    // 其他情況,一律返回加鎖失敗
    return false;
}

這段代碼的錯(cuò)誤之處在于:

1. 由于是客戶端自己生成過(guò)期時(shí)間,所以需要強(qiáng)制要求分布式下每個(gè)客戶端的時(shí)間必須同步。

2. 當(dāng)鎖過(guò)期的時(shí)候,如果多個(gè)客戶端同時(shí)執(zhí)行jedis.getSet()方法,那么雖然最終只有一個(gè)客戶端可以加鎖,但是這個(gè)客戶端的鎖的過(guò)期時(shí)間可能被其他客戶端覆蓋。

3. 鎖不具備擁有者標(biāo)識(shí),即任何客戶端都可以解鎖。


解鎖代碼

正確代碼

public class RedisTool {
    private static final Long RELEASE_SUCCESS = 1L;
    /**
     * 釋放分布式鎖
     * @param jedis Redis客戶端
     * @param lockKey 鎖
     * @param requestId 請(qǐng)求標(biāo)識(shí)
     * @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;
    }
}

可以看到,我們解鎖只需要兩行代碼就搞定了!第一行代碼,我們寫了一個(gè)簡(jiǎn)單的Lua腳本代碼,上一次見(jiàn)到這個(gè)編程語(yǔ)言還是在《黑客與畫家》里,沒(méi)想到這次居然用上了。第二行代碼,我們將Lua代碼傳到j(luò)edis.eval()方法里,并使參數(shù)KEYS[1]賦值為lockKey,ARGV[1]賦值為requestId。eval()方法是將Lua代碼交給Redis服務(wù)端執(zhí)行。

那么這段Lua代碼的功能是什么呢?其實(shí)很簡(jiǎn)單,首先獲取鎖對(duì)應(yīng)的value值,檢查是否與requestId相等,如果相等則刪除鎖(解鎖)。那么為什么要使用Lua語(yǔ)言來(lái)實(shí)現(xiàn)呢?因?yàn)橐_保上述操作是原子性的。關(guān)于非原子性會(huì)帶來(lái)什么問(wèn)題,可以閱讀【解鎖代碼-錯(cuò)誤示例2】 。那么為什么執(zhí)行eval()方法可以確保原子性,源于Redis的特性,簡(jiǎn)單來(lái)說(shuō),就是在eval命令執(zhí)行Lua代碼的時(shí)候,Lua代碼將被當(dāng)成一個(gè)命令去執(zhí)行,并且直到eval命令執(zhí)行完成,Redis才會(huì)執(zhí)行其他命令。


錯(cuò)誤示例1

最常見(jiàn)的解鎖代碼就是直接使用jedis.del()方法刪除鎖,這種不先判斷鎖的擁有者而直接解鎖的方式,會(huì)導(dǎo)致任何客戶端都可以隨時(shí)進(jìn)行解鎖,即使這把鎖不是它的。

public static void wrongReleaseLock1(Jedis jedis, String lockKey) {
    jedis.del(lockKey);
}


錯(cuò)誤示例2

這種解鎖代碼乍一看也是沒(méi)問(wèn)題,甚至我之前也差點(diǎn)這樣實(shí)現(xiàn),與正確姿勢(shì)差不多,唯一區(qū)別的是分成兩條命令去執(zhí)行,代碼如下:

public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
    // 判斷加鎖與解鎖是不是同一個(gè)客戶端
    if (requestId.equals(jedis.get(lockKey))) {
        // 若在此時(shí),這把鎖突然不是這個(gè)客戶端的,則會(huì)誤解鎖
        jedis.del(lockKey);
    }
}

如代碼注釋,這個(gè)代碼的問(wèn)題在于如果調(diào)用jedis.del()方法的時(shí)候,這把鎖已經(jīng)不屬于當(dāng)前客戶端的時(shí)候會(huì)解除他人加的鎖。那么是否真的有這種場(chǎng)景?答案是肯定的,比如客戶端A加鎖,一段時(shí)間之后客戶端A解鎖,在執(zhí)行jedis.del()之前,鎖突然過(guò)期了,此時(shí)客戶端B嘗試加鎖成功,然后客戶端A再執(zhí)行del()方法,則將客戶端B的鎖給解除了。


總結(jié)

本文介紹的Redis分布式鎖都是用JAVA實(shí)現(xiàn),對(duì)于加鎖和解鎖的方法也分別給出了錯(cuò)誤示例供大家參考。其實(shí)想要通過(guò)Redis實(shí)現(xiàn)分布式鎖難度并不高,只要能滿足上面給出的十個(gè)可靠性條件即可。

以上內(nèi)容是否對(duì)您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號(hào)
微信公眾號(hào)

編程獅公眾號(hào)