一、redis實(shí)現(xiàn)分布式鎖的主要原理：

1.加鎖

最簡(jiǎn)單的方法是使用setnx命令。key是鎖的唯一標(biāo)識(shí)，按業(yè)務(wù)來(lái)決定命名。比如想要給一種商品的秒殺活動(dòng)加鎖，可以給key命名為 “l(fā)ock_sale_商品ID” 。而value設(shè)置成什么呢？我們可以姑且設(shè)置成1。加鎖的偽代碼如下：
setnx（key，1）

當(dāng)一個(gè)線程執(zhí)行setnx返回1，說(shuō)明key原本不存在，該線程成功得到了鎖；當(dāng)一個(gè)線程執(zhí)行setnx返回0，說(shuō)明key已經(jīng)存在，該線程搶鎖失敗。

2.解鎖

有加鎖就得有解鎖。當(dāng)?shù)玫芥i的線程執(zhí)行完任務(wù)，需要釋放鎖，以便其他線程可以進(jìn)入。釋放鎖的最簡(jiǎn)單方式是執(zhí)行del指令，偽代碼如下：

del（key）

釋放鎖之后，其他線程就可以繼續(xù)執(zhí)行setnx命令來(lái)獲得鎖。

3.鎖超時(shí)

鎖超時(shí)是什么意思呢？如果一個(gè)得到鎖的線程在執(zhí)行任務(wù)的過(guò)程中掛掉，來(lái)不及顯式地釋放鎖，這塊資源將會(huì)永遠(yuǎn)被鎖住，別的線程再也別想進(jìn)來(lái)。

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

expire（key， 30）

二、加鎖的代碼

/**
 * 嘗試獲取分布式鎖
 * @param jedis Redis客戶端
 * @param lockKey 鎖
 * @param requestId 請(qǐng)求標(biāo)識(shí)
 * @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) {
  // 若在這里程序突然崩潰，則無(wú)法設(shè)置過(guò)期時(shí)間，將發(fā)生死鎖
  jedis.expire(lockKey, expireTime);
 }

}

上面的代碼有一個(gè)致命的問(wèn)題，就是加鎖和設(shè)置過(guò)期時(shí)間不是原子操作。

那么會(huì)有兩種極端情況：

一種是在并發(fā)情況下，兩個(gè)線程同時(shí)執(zhí)行setnx，那么得到的結(jié)果都是1，這樣兩個(gè)線程同時(shí)拿到了鎖。

別一種是如代碼注釋所示，即執(zhí)行完setnx，程序崩潰沒有執(zhí)行過(guò)期時(shí)間，那這把鎖就永遠(yuǎn)不會(huì)被釋放，造成了死鎖。

之所以有人這樣實(shí)現(xiàn)，是因?yàn)榈桶姹镜膉edis并不支持多參數(shù)的set()方法。正確的代碼如下：

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

}

這個(gè)set()方法一共有五個(gè)形參：

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

第二個(gè)為value，我們傳的是requestId，很多童鞋可能不明白，有key作為鎖不就夠了嗎，為什么還要用到value？原因就是，通過(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)前沒有鎖（key不存在），那么就進(jìn)行加鎖操作，并對(duì)鎖設(shè)置個(gè)有效期，同時(shí)value表示加鎖的客戶端。2. 已有鎖存在，不做任何操作。

二、解鎖的代碼

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

這段代碼的問(wèn)題是容易導(dǎo)致誤刪，假如某線程成功得到了鎖，并且設(shè)置的超時(shí)時(shí)間是30秒。如果某些原因?qū)е戮€程A執(zhí)行的很慢很慢，過(guò)了30秒都沒執(zhí)行完，這時(shí)候鎖過(guò)期自動(dòng)釋放，線程B得到了鎖。

隨后，線程A執(zhí)行完了任務(wù)，線程A接著執(zhí)行del指令來(lái)釋放鎖。但這時(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對(duì)應(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è)新的問(wèn)題，判斷和釋放鎖是兩個(gè)獨(dú)立操作，不是原子性。

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

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;

  }

}

三、續(xù)約問(wèn)題

上面加鎖最后的代碼就完美了嗎？假想這樣一個(gè)場(chǎng)景，如果過(guò)期時(shí)間為30S，A線程超過(guò)30S還沒執(zhí)行完，但是自動(dòng)過(guò)期了。這時(shí)候B線程就會(huì)再拿到鎖，造成了同時(shí)有兩個(gè)線程持有鎖。這個(gè)問(wèn)題可以歸結(jié)為”續(xù)約“問(wèn)題，即A沒執(zhí)行完時(shí)應(yīng)該過(guò)期時(shí)間續(xù)約，執(zhí)行完成才能釋放鎖。怎么辦呢？我們可以讓獲得鎖的線程開啟一個(gè)守護(hù)線程，用來(lái)給快要過(guò)期的鎖“續(xù)約”。

其實(shí)，后面解鎖出現(xiàn)的刪除非自己鎖，也屬于“續(xù)約”問(wèn)題。

四、集群同步延遲問(wèn)題

用于redis的服務(wù)肯定不能是單機(jī)，因?yàn)閱螜C(jī)就不是高可用了，一量掛掉整個(gè)分布式鎖就沒用了。

在集群場(chǎng)景下，如果A在master拿到了鎖,在沒有把數(shù)據(jù)同步到slave時(shí)，master掛掉了。B再拿鎖就會(huì)從slave拿鎖，而且會(huì)拿到。又出現(xiàn)了兩個(gè)線程同時(shí)拿到鎖。

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

這個(gè)算法的意思大概是這樣的：假設(shè) Redis 的部署模式是 Redis Cluster，總共有 5 個(gè) Master 節(jié)點(diǎn)。

通過(guò)以下步驟獲取一把鎖：

• 獲取當(dāng)前時(shí)間戳，單位是毫秒。
• 輪流嘗試在每個(gè) Master 節(jié)點(diǎn)上創(chuàng)建鎖，過(guò)期時(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試獲取鎖。
  

但是這樣的這種算法還是頗具爭(zhēng)議的，可能還會(huì)存在不少的問(wèn)題，無(wú)法保證加鎖的過(guò)程一定正確。

這個(gè)問(wèn)題的根本原因就是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ù)庫(kù)提供的一系列優(yōu)勢(shì)，基于Java實(shí)用工具包中常用接口，為使用者提供了一系列具有分布式特性的常用工具類。

Redisson通過(guò)lua腳本解決了上面的原子性問(wèn)題，通過(guò)“看門狗”解決了續(xù)約問(wèn)題，但是它應(yīng)該解決不了集群中的同步延遲問(wèn)題。

總結(jié)

redis分布式鎖的方案，無(wú)論用何種方式實(shí)現(xiàn)都會(huì)有續(xù)約問(wèn)題與集群同步延遲問(wèn)題。總的來(lái)說(shuō)，是一個(gè)不太靠譜的方案。如果追求高正確率，不能采用這種方案。

但是它也有優(yōu)點(diǎn)，就是比較簡(jiǎn)單，在某些非嚴(yán)格要求的場(chǎng)景是可以使用的，比如社交系統(tǒng)一類，交易系統(tǒng)一類不能出現(xiàn)重復(fù)交易則不建議用。

到此這篇關(guān)于redis分布式鎖及會(huì)出現(xiàn)的問(wèn)題解決的文章就介紹到這了,更多相關(guān)redis分布式鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！