Redis分佈式鎖

時間 2020-02-04

原文原文鏈接

1.概述

分佈式鎖通常有三種實現方式：1.基於數據庫實現分佈式鎖；2. 基於緩存（Redis，memcached，tair）實現分佈式鎖； 3.基於Zookeeper實現分佈式鎖。本片博客將介紹基於緩存實現分佈式鎖，這裏主講分別針對Redis 2.6.12 以前版本和Redis 2.6.12 及以後版本分佈式鎖的實現。html

2.基於Redis（Redis 2.6.12版本以前）分佈式鎖的實現方式

（1）命令介紹

　　1）SETX

　　SETNX key value: setnx是『set if not exists』（即當key不存在時，則set）的簡寫。setnx具備原子性，當且僅當key不存在時，set一個key爲val的字符串，返回1；若key存在，則什麼都不作，返回0.java

　　2)GETSET

　　GETSET key value：將給定 key 的值設爲 value ，並返回 key 的舊值(old value)。當 key 存在但不是字符串類型時，返回一個錯誤。當 key 沒有舊值時，也便是， key 不存在時，返回 nil 。redis

　　3)GET

　　GET key：返回 key 所關聯的字符串值；若是 key 不存在那麼返回特殊值 nil 。假如 key 儲存的值不是字符串類型，返回一個錯誤，由於GET只能用於處理字符串值。sql

　　4)EXPIRE

　　EXPIRE key timeout：爲key設置一個超時時間，單位爲second，超過這個時間鎖會自動釋放，避免死鎖。數據庫

　　5)DELETE

　　DELETE key:刪除key緩存

（2）Redis實現分佈式鎖的原理

* 1.經過setnx(lock_timeout)實現，若是設置了鎖返回1，已經有值沒有設置成功返回0服務器

* 2.死鎖問題：經過實踐來判斷是否過時，若是已通過期，獲取到過時時間get(lockKey)，而後getset(lock_timeout)判斷是否和get相同，多線程

* 相同則證實已經加鎖成功，由於可能致使多線程同時執行getset(lock_timeout)方法，這可能致使多線程都只需getset後，對於判斷加鎖成功的線程，併發

* 再加expire(lockKey, LOCK_TIMEOUT, TimeUnit.MILLISECONDS)過時時間，防止多個線程同時疊加時間，致使鎖時效時間翻倍dom

* 3.針對集羣服務器時間不一致問題，能夠調用redis的time()獲取當前時間

（3）圖解Redis分佈式鎖原理

1. setnx(lockkey, 當前時間+過時超時時間) ，若是返回1，則獲取鎖成功；若是返回0則沒有獲取到鎖，轉向2。
2. get(lockkey)獲取鎖的過時時間lockValueA ，並將這個lockValueA 值與當前的系統時間currentTime進行比較，若是小於當前系統時間，則認爲這個鎖已經超時，能夠容許別的請求從新獲取，轉向3。
3. 計算新的過時時間 newExpireTime=當前時間+過時超時時間，而後getset(lockkey, newExpireTime) 會返回當前lockkey的值lockValueB。
4. 判斷lockValueA與lockValueB 是否相等，若是相等，說明當前getset設置成功，獲取到了鎖。若是不相等，說明這個鎖又被別的請求獲取走了，那麼當前請求能夠直接返回失敗，或者繼續重試。
5. 在獲取到鎖以後，當前線程能夠開始本身的業務處理，當處理完畢後，比較本身的處理時間和對於鎖設置的超時時間，若是小於鎖設置的超時時間，則直接執行delete釋放鎖；若是大於鎖設置的超時時間，則不須要再鎖進行處理。

（4）缺點

Redis 2.6.12以前版本，使用SETNX命令實現Redis分佈式鎖，可是會出現各類各樣的問題。具體羅列出如下幾種：

1）setnx和expire的非原子性

設想一個極端場景，當某線程執行setnx，成功獲得了鎖：

setnx剛執行成功，還將來得及執行expire指令，節點1 Duang的一聲掛掉了。

這樣一來，這把鎖就沒有設置過時時間，變得「長生不老」，別的線程再也沒法得到鎖了。如示例代碼所示

示例代碼

public static void wrongGetLock1(Jedis jedis, String lockKey, String requestId, int expireTime) {
 
    Long result = jedis.setnx(lockKey, requestId);
    if (result == 1) {
        // 若在這裏程序忽然崩潰，則沒法設置過時時間，將發生死鎖
        jedis.expire(lockKey, expireTime);
    }
 
}

setnx()方法做用就是SET IF NOT EXIST，expire()方法就是給鎖加一個過時時間。乍一看好像和前面的set()方法結果同樣，然而因爲這是兩條Redis命令，不具備原子性，若是程序在執行完setnx()以後忽然崩潰，致使鎖沒有設置過時時間。那麼將會發生死鎖。網上之因此有人這樣實現，是由於低版本的jedis並不支持多參數的set()方法。

2）出現併發的可能性

這裏使用示例代碼來描述

示例代碼

這一種錯誤示例就比較難以發現問題，並且實現也比較複雜。實現思路：使用jedis.setnx()命令實現加鎖，其中key是鎖，value是鎖的過時時間。執行過程：1. 經過setnx()方法嘗試加鎖，若是當前鎖不存在，返回加鎖成功。2. 若是鎖已經存在則獲取鎖的過時時間，和當前時間比較，若是鎖已通過期，則設置新的過時時間，返回加鎖成功。代碼以下：

public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {
 
    long expires = System.currentTimeMillis() + expireTime;
    String expiresStr = String.valueOf(expires);
 
    // 若是當前鎖不存在，返回加鎖成功
    if (jedis.setnx(lockKey, expiresStr) == 1) {
        return true;
    }
 
    // 若是鎖存在，獲取鎖的過時時間
    String currentValueStr = jedis.get(lockKey);
    if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
        // 鎖已過時，獲取上一個鎖的過時時間，並設置如今鎖的過時時間
        String oldValueStr = jedis.getSet(lockKey, expiresStr);
        if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
            // 考慮多線程併發的狀況，只有一個線程的設置值和當前值相同，它纔有權利加鎖
            return true;
        }
    }
 
    // 其餘狀況，一概返回加鎖失敗
    return false;
 
}

那麼這段代碼問題在哪裏？1. 因爲是客戶端本身生成過時時間，因此須要強制要求分佈式下每一個客戶端的時間必須同步。 2. 當鎖過時的時候，若是多個客戶端同時執行jedis.getSet()方法，那麼雖然最終只有一個客戶端能夠加鎖，可是這個客戶端的鎖的過時時間可能被其餘客戶端覆蓋。3. 鎖不具有擁有者標識，即任何客戶端均可以解鎖。

3）del 致使誤刪

又是一個極端場景，假如某線程成功獲得了鎖，而且設置的超時時間是30秒。

若是某些緣由致使線程A執行的很慢很慢，過了30秒都沒執行完，這時候鎖過時自動釋放，線程B獲得了鎖。

隨後，線程A執行完了任務，線程A接着執行del指令來釋放鎖。但這時候線程B還沒執行完，線程A實際上刪除的是線程B加的鎖。

怎麼避免這種狀況呢？能夠在del釋放鎖以前作一個判斷，驗證當前的鎖是否是本身加的鎖。

至於具體的實現，能夠在加鎖的時候把當前的線程ID當作value，並在刪除以前驗證key對應的value是否是本身線程的ID。

加鎖：

String threadId = Thread.currentThread().getId()
set（key，threadId ，30，NX）

解鎖：

if（threadId .equals(redisClient.get(key))）{
    del(key)
}

也能夠在釋放鎖的時候，經過鎖的默認value值UUID判斷是否是該鎖，如果該鎖，則執行delete進行鎖釋放。可是，這樣作又隱含了一個新的問題，判斷和釋放鎖是兩個獨立操做，不是原子性的。具體如代碼所示：

示例代碼1

最多見的解鎖代碼就是直接使用jedis.del()方法刪除鎖，這種不先判斷鎖的擁有者而直接解鎖的方式，會致使任何客戶端均可以隨時進行解鎖，即便這把鎖不是它的。

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

示例代碼2

這種解鎖代碼乍一看也是沒問題，甚至我以前也差點這樣實現，與正確姿式差很少，惟一區別的是分紅兩條命令去執行，代碼以下：

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

如代碼註釋，問題在於若是調用jedis.del()方法的時候，這把鎖已經不屬於當前客戶端的時候會解除他人加的鎖。那麼是否真的有這種場景？答案是確定的，好比客戶端A加鎖，一段時間以後客戶端A解鎖，在執行jedis.del()以前，鎖忽然過時了，此時客戶端B嘗試加鎖成功，而後客戶端A再執行del()方法，則將客戶端B的鎖給解除了。

從Redis 2.6.12版本開始很好的解決了上述的問題，下面是採用Redis2.6.12版本對以上問題的解決

3.基於Redis（Redis 2.6.12版本起）分佈式鎖的實現方式

（1）命令介紹

從Redis2.6.12版本開始，redis爲SET命令增長了一系列選項：

EX second ：設置鍵的過時時間爲 second 秒。 SET key value EX second 效果等同於 SETEX key second value 。
PX millisecond ：設置鍵的過時時間爲 millisecond 毫秒。 SET key value PX millisecond 效果等同於 PSETEX key millisecond value。
NX ：只在鍵不存在時，纔對鍵進行設置操做。 SET key value NX 效果等同於 SETNX key value 。
XX ：只在鍵已經存在時，纔對鍵進行設置操做。

注意: 因爲SET命令加上選項已經能夠徹底取代SETNX, SETEX, PSETEX的功能，因此在未來的版本中，redis可能會不推薦使用而且最終拋棄這幾個命令。使用SET代替SETNX，至關於SETNX+EXPIRE實現了原子性，沒必要擔憂SETNX成功，EXPIRE失敗的問題！有效的避免死鎖，解決了Redis2.6.12以前版本存在的問題。

（2）分佈式鎖的實現

1）解決非原子性和併發的出現

示例代碼

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 請求標識
     * @param expireTime 超期時間
     * @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)，這個set()方法一共有五個形參：

第一個爲key，咱們使用key來當鎖，由於key是惟一的。
第二個爲value，咱們傳的是requestId，不少童鞋可能不明白，有key做爲鎖不就夠了嗎，爲何還要用到value？緣由就是咱們在上面講到可靠性時，分佈式鎖要知足第四個條件解鈴還須繫鈴人，經過給value賦值爲requestId，咱們就知道這把鎖是哪一個請求加的了，在解鎖的時候就能夠有依據。requestId可使用UUID.randomUUID().toString()方法生成。
第三個爲nxxx，這個參數咱們填的是NX，意思是SET IF NOT EXIST，即當key不存在時，咱們進行set操做；若key已經存在，則不作任何操做；
第四個爲expx，這個參數咱們傳的是PX，意思是咱們要給這個key加一個過時的設置，具體時間由第五個參數決定。
第五個爲time，與第四個參數相呼應，表明key的過時時間。

總的來講，執行上面的set()方法就只會致使兩種結果：1. 當前沒有鎖（key不存在），那麼就進行加鎖操做，並對鎖設置個有效期，同時value表示加鎖的客戶端。2. 已有鎖存在，不作任何操做。

心細的童鞋就會發現了，咱們的加鎖代碼知足咱們可靠性裏描述的三個條件。首先，set()加入了NX參數，能夠保證若是已有key存在，則函數不會調用成功，也就是隻有一個客戶端能持有鎖，知足互斥性。其次，因爲咱們對鎖設置了過時時間，即便鎖的持有者後續發生崩潰而沒有解鎖，鎖也會由於到了過時時間而自動解鎖（即key被刪除），不會發生死鎖。最後，由於咱們將value賦值爲requestId，表明加鎖的客戶端請求標識，那麼在客戶端在解鎖的時候就能夠進行校驗是不是同一個客戶端。因爲咱們只考慮Redis單機部署的場景，因此容錯性咱們暫不考慮。

2）解決鎖誤刪

示例代碼

public class RedisTool {
 
    private static final Long RELEASE_SUCCESS = 1L;
 
    /**
     * 釋放分佈式鎖
     * @param jedis Redis客戶端
     * @param lockKey 鎖
     * @param requestId 請求標識
     * @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;
 
    }
 
}

能夠看到，咱們解鎖只須要兩行代碼就搞定了！第一行代碼，咱們寫了一個簡單的Lua腳本代碼，第二行代碼，咱們將Lua代碼傳到jedis.eval()方法裏，並使參數KEYS[1]賦值爲lockKey，ARGV[1]賦值爲requestId。eval()方法是將Lua代碼交給Redis服務端執行。

那麼這段Lua代碼的功能是什麼呢？其實很簡單，首先獲取鎖對應的value值，檢查是否與requestId相等，若是相等則刪除鎖（解鎖）。那麼爲何要使用Lua語言來實現呢？由於要確保上述操做是原子性的。那麼爲何執行eval()方法能夠確保原子性，源於Redis的特性，簡單來講，就是在eval命令執行Lua代碼的時候，Lua代碼將被當成一個命令去執行，而且直到eval命令執行完成，Redis纔會執行其餘命令。