Redis分布式鎖存在的問題(推薦)

更新時(shí)間：2022年12月12日 08:44:43 作者：小黑說Java

有很多基于Redis實(shí)現(xiàn)的分布式鎖方案或者庫，但是有些庫并沒有解決分布式環(huán)境下的一些問題陷阱，這篇文章主要介紹了Redis分布式鎖存在的問題,需要的朋友可以參考下

分布式鎖的特點(diǎn)

分布式鎖應(yīng)該具備以下屬性：

互斥在同一時(shí)刻只有一個(gè)客戶端可以持有鎖；這是分布式鎖的基本屬性。
無死鎖 每個(gè)鎖請(qǐng)求都可以最終獲得鎖；即使是持有鎖的客戶端也會(huì)崩潰或遇到異常。不同的實(shí)現(xiàn)

不同的實(shí)現(xiàn)

許多分布式鎖實(shí)現(xiàn)都是基于分布式共識(shí)算法(Paxos、Raft、ZAB、Pacifica)的，比如基于Paxos的Chubby、基于ZAB的Zookeeper等，以及基于Raft的Consul。Redis的作者還提出了一種分布式鎖，名為RedLock。

在接下來的章節(jié)中，我將展示如何基于Redis一步步實(shí)現(xiàn)分布式鎖，并且在每一步中，我都試圖解決分布式環(huán)境中可能發(fā)生的一個(gè)問題。

場(chǎng)景一：?jiǎn)螌?shí)例Redis

為了簡(jiǎn)單起見，假設(shè)我們有兩個(gè)客戶端和一個(gè)Redis實(shí)例。一個(gè)簡(jiǎn)單的實(shí)現(xiàn)應(yīng)該是：

boolean tryAcquire(String lockName, long leaseTime, OperationCallBack operationCallBack) {
   // 加鎖
  boolean getLockSuccessfully = getLock(lockName, leaseTime);
  if (getLockSuccessfully) {
      try {
          operationCallBack.doOperation();
      } finally {
          releaseLock(lockName);
      }
      return true;
  } else {
      return false;
  }
}

boolean getLock(String lockName, long expirationTimeMillis) {
	// 給當(dāng)前線程創(chuàng)建一個(gè)唯一的lockValue
  String lockValue = createUniqueLockValue();
  try {
	  // 如果lockName沒有加鎖，則將lockName作為key保存到redis中，并指定過期時(shí)間
      String response = storeLockInRedis(lockName, lockValue, expirationTimeMillis);
      return response.equalsIgnoreCase("OK");
  } catch (Exception exception) {
      releaseLock(lockName);
      throw exception;
  }
}

void releaseLock(String lockName) {
  String lockValue = createUniqueLockValue();
  // 移除鎖lockName，如果鎖的值是lockValue
  removeLockFromRedis(lockName, lockValue);
}

這種方式有什么問題呢？

**假如客戶端1請(qǐng)求服務(wù)端獲取一個(gè)鎖，并指定了鎖超時(shí)時(shí)間，如果服務(wù)器響應(yīng)的時(shí)間大于鎖的超時(shí)時(shí)間，客戶端1拿到的則是一個(gè)過期的鎖，這時(shí)客戶端2同時(shí)可以獲取該鎖進(jìn)行業(yè)務(wù)操作。**這打破了分布式鎖應(yīng)該具備的相互排斥原則。

為了解決這個(gè)問題，我們應(yīng)該給redis客戶端設(shè)置一個(gè)請(qǐng)求超時(shí)時(shí)間timeout，這個(gè)時(shí)間應(yīng)該小于鎖的超時(shí)時(shí)間。

當(dāng)時(shí)這還不能完全解決這個(gè)問題，假設(shè)Redis服務(wù)器因?yàn)榈綦娭貑?，則會(huì)有其他的問題，我們接下來看第二個(gè)場(chǎng)景。

場(chǎng)景二：?jiǎn)螌?shí)例Redis的單點(diǎn)故障

如果你對(duì)Redis的數(shù)據(jù)持久化方案有所了解，那一定知道Redis有兩種方式做數(shù)據(jù)持久化。

RDB(Redis Database)：按指定的時(shí)間間隔將Redis的數(shù)據(jù)快照保存到磁盤。

AOF(Append-Only File)：將服務(wù)器接收到的寫操作指令記錄下來，這些操作指令在服務(wù)重啟時(shí)可以重新執(zhí)行來恢復(fù)原始數(shù)據(jù)。

默認(rèn)情況下，只會(huì)開啟RDB模式，會(huì)按照如下方式配置：

save 900 1 

save 300 10 

save 60 10000

例如，第一行表示在900秒（15min）內(nèi)如果有一次寫操作，就將數(shù)據(jù)同步到數(shù)據(jù)文件。

所以在最壞的情況下，將一個(gè)加鎖數(shù)據(jù)保存需要15分鐘，如果在加鎖成功時(shí)Redis服務(wù)掉電重啟，則無法恢復(fù)內(nèi)存中的加鎖數(shù)據(jù)，其它客戶端同樣可以獲取到相同的鎖：

為了解決這個(gè)問題，我們必須使用fsync=always選項(xiàng)來啟用AOF，然后在Redis中設(shè)置鍵。

注意，啟用這個(gè)選項(xiàng)對(duì)Redis的性能有一定的影響，但我們需要這個(gè)選項(xiàng)以保持強(qiáng)一致性。

場(chǎng)景三：主從復(fù)制

在這個(gè)配置中，我們有一個(gè)或多個(gè)實(shí)例(通常稱為從實(shí)例或副本)，它們是主實(shí)例的精確副本。

默認(rèn)情況下，Redis中的復(fù)制是異步的；這意味著主服務(wù)器不會(huì)等待命令被副本處理完畢再返回給客戶端。

問題是在復(fù)制發(fā)生之前，主服務(wù)器可能出現(xiàn)故障，并發(fā)生故障轉(zhuǎn)移；在此之后，如果另一個(gè)客戶端請(qǐng)求獲得鎖，它將成功！或者假設(shè)存在一個(gè)臨時(shí)的網(wǎng)絡(luò)問題，因此其中一個(gè)副本沒有接收到命令，網(wǎng)絡(luò)變得穩(wěn)定，故障轉(zhuǎn)移很快發(fā)生；沒有接收到命令的節(jié)點(diǎn)成為主節(jié)點(diǎn)。

最終，該鎖將從所有實(shí)例中刪除！下圖說明了這種情況:

作為解決方案，有一個(gè)等待命令，等待指定數(shù)量的確認(rèn)副本并返回副本的數(shù)量，承認(rèn)之前的寫命令發(fā)送等待命令，兩個(gè)的情況下達(dá)到指定數(shù)量的副本或者超時(shí)。

例如，如果我們有兩個(gè)副本，下面的命令最多等待1秒(1000毫秒)來從兩個(gè)副本獲得確認(rèn)并返回：

WAIT  2  1000

到目前為止，一切順利，但還有另一個(gè)問題；副本可能會(huì)丟失寫入(由于錯(cuò)誤的環(huán)境)。例如，一個(gè)副本在保存操作完成之前失敗，同時(shí)主節(jié)點(diǎn)也失敗，故障轉(zhuǎn)移操作選擇重新啟動(dòng)的副本作為新的主節(jié)點(diǎn)。在與新主服務(wù)器同步后，所有副本和新主服務(wù)器都沒有舊主服務(wù)器中的密鑰！

為了使所有的從服務(wù)器和主服務(wù)器完全一致，我們應(yīng)該在獲得鎖之前為所有Redis實(shí)例啟用fsync=always的AOF。

注意：在這種方法中，我們?yōu)榱藦?qiáng)一致性而破壞了可用性，AOF會(huì)有一定的性能損耗。