redis分布式鎖及會出現的問題解決

2020-10-28 21:27:00

字體：大中小

來源：轉載

供稿：網友

一、redis實現分布式鎖的主要原理：

1.加鎖

最簡單的方法是使用setnx命令。key是鎖的唯一標識，按業務來決定命名。比如想要給一種商品的秒殺活動加鎖，可以給key命名為 “lock_sale_商品ID” 。而value設置成什么呢？我們可以姑且設置成1。加鎖的偽代碼如下：
setnx（key，1）

當一個線程執行setnx返回1，說明key原本不存在，該線程成功得到了鎖；當一個線程執行setnx返回0，說明key已經存在，該線程搶鎖失敗。

2.解鎖

有加鎖就得有解鎖。當得到鎖的線程執行完任務，需要釋放鎖，以便其他線程可以進入。釋放鎖的最簡單方式是執行del指令，偽代碼如下：

del（key）

釋放鎖之后，其他線程就可以繼續執行setnx命令來獲得鎖。

3.鎖超時

鎖超時是什么意思呢？如果一個得到鎖的線程在執行任務的過程中掛掉，來不及顯式地釋放鎖，這塊資源將會永遠被鎖住，別的線程再也別想進來。

所以，setnx的key必須設置一個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間后自動釋放。setnx不支持超時參數，所以需要額外的指令，偽代碼如下：

expire（key， 30）

二、加鎖的代碼

/** * 嘗試獲取分布式鎖 * @param jedis Redis客戶端 * @param lockKey 鎖 * @param requestId 請求標識 * @param expireTime 超期時間 * @return 是否獲取成功 */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，那么得到的結果都是1，這樣兩個線程同時拿到了鎖。

別一種是如代碼注釋所示，即執行完setnx，程序崩潰沒有執行過期時間，那這把鎖就永遠不會被釋放，造成了死鎖。

之所以有人這樣實現，是因為低版本的jedis并不支持多參數的set()方法。正確的代碼如下：

/** * 嘗試獲取分布式鎖 * @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, "NX", "PX", expireTime);    if ("OK".equals(result)) {      return true;    }    return false;}

這個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. 已有鎖存在，不做任何操作。

二、解鎖的代碼

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

這段代碼的問題是容易導致誤刪，假如某線程成功得到了鎖，并且設置的超時時間是30秒。如果某些原因導致線程A執行的很慢很慢，過了30秒都沒執行完，這時候鎖過期自動釋放，線程B得到了鎖。

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

怎么避免這種情況呢？可以在del釋放鎖之前做一個判斷，驗證當前的鎖是不是自己加的鎖。

至于具體的實現，可以在加鎖的時候把當前的線程ID當做value，并在刪除之前驗證key對應的value是不是自己線程的ID。

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

但是，這樣做又隱含了一個新的問題，判斷和釋放鎖是兩個獨立操作，不是原子性。

解決方案就是使用lua腳本，把它變成原子操作，代碼如下：

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;  }}

三、續約問題

上面加鎖最后的代碼就完美了嗎？假想這樣一個場景，如果過期時間為30S，A線程超過30S還沒執行完，但是自動過期了。這時候B線程就會再拿到鎖，造成了同時有兩個線程持有鎖。這個問題可以歸結為”續約“問題，即A沒執行完時應該過期時間續約，執行完成才能釋放鎖。怎么辦呢？我們可以讓獲得鎖的線程開啟一個守護線程，用來給快要過期的鎖“續約”。

其實，后面解鎖出現的刪除非自己鎖，也屬于“續約”問題。

四、集群同步延遲問題

用于redis的服務肯定不能是單機，因為單機就不是高可用了，一量掛掉整個分布式鎖就沒用了。

在集群場景下，如果A在master拿到了鎖,在沒有把數據同步到slave時，master掛掉了。B再拿鎖就會從slave拿鎖，而且會拿到。又出現了兩個線程同時拿到鎖。

基于以上的考慮，Redis 的作者也考慮到這個問題，他提出了一個 RedLock 的算法。

這個算法的意思大概是這樣的：假設 Redis 的部署模式是 Redis Cluster，總共有 5 個 Master 節點。

通過以下步驟獲取一把鎖：