2. 程式人生 > >一文看透 Redis 分布式鎖進化史（解讀 + 缺陷分析）（轉）

一文看透 Redis 分布式鎖進化史（解讀 + 缺陷分析）（轉）

阿新 • • 發佈：2019-03-13
turn 說明 方式 它的 思路 機制 ets 3.0 去掉

近兩年來微服務變得越來越熱門，越來越多的應用部署在分布式環境中，在分布式環境中，數據一致性是一直以來需要關註並且去解決的問題，分布式鎖也就成為了一種廣泛使用的技術，常用的分布式實現方式為Redis，Zookeeper，其中基於Redis的分布式鎖的使用更加廣泛。

但是在工作和網絡上看到過各個版本的Redis分布式鎖實現，每種實現都有一些不嚴謹的地方，甚至有可能是錯誤的實現，包括在代碼中，如果不能正確的使用分布式鎖，可能造成嚴重的生產環境故障，本文主要對目前遇到的各種分布式鎖以及其缺陷做了一個整理，並對如何選擇合適的Redis分布式鎖給出建議。

各個版本的Redis分布式鎖

V1.0

tryLock(){  
    SETNX Key 
 
1
    EXPIRE Key Seconds
}
release(){  
  DELETE Key
}

這個版本應該是最簡單的版本，也是出現頻率很高的一個版本，首先給鎖加一個過期時間操作是為了避免應用在服務重啟或者異常導致鎖無法釋放後，不會出現鎖一直無法被釋放的情況。

這個方案的一個問題在於每次提交一個Redis請求，如果執行完第一條命令後應用異常或者重啟，鎖將無法過期，一種改善方案就是使用Lua腳本（包含SETNX和EXPIRE兩條命令），但是如果Redis僅執行了一條命令後crash或者發生主從切換，依然會出現鎖沒有過期時間，最終導致無法釋放。

另外一個問題在於，很多同學在釋放分布式鎖的過程中，無論鎖是否獲取成功，都在finally

中釋放鎖，這樣是一個鎖的錯誤使用，這個問題將在後續的V3.0版本中解決。

針對鎖無法釋放問題的一個解決方案基於GETSET命令來實現

V1.1 基於GETSET

tryLock(){  
    NewExpireTime=CurrentTimestamp+ExpireSeconds
    if(SETNX Key NewExpireTime Seconds){
         oldExpireTime = GET(Key)
          if( oldExpireTime < CurrentTimestamp){
              NewExpireTime
 
=CurrentTimestamp+ExpireSeconds
              CurrentExpireTime=GETSET(Key,NewExpireTime)
              if(CurrentExpireTime == oldExpireTime){
                return 1;
              }else{
                return 0;
              }
          }
    }
}
release(){  
        DELETE key
    }

思路：

  1. SETNX(Key,ExpireTime)獲取鎖

  2. 如果獲取鎖失敗，通過GET(Key)返回的時間戳檢查鎖是否已經過期

  3. GETSET(Key,ExpireTime)修改Value為NewExpireTime

  4. 檢查GETSET返回的舊值，如果等於GET返回的值，則認為獲取鎖成功

註意：這個版本去掉了EXPIRE命令，改為通過Value時間戳值來判斷過期

問題：

  1. 在鎖競爭較高的情況下，會出現Value不斷被覆蓋，但是沒有一個Client獲取到鎖

  2. 在獲取鎖的過程中不斷的修改原有鎖的數據，設想一種場景C1，C2競爭鎖，C1獲取到了鎖，C2鎖執行了GETSET操作修改了C1鎖的過期時間，如果C1沒有正確釋放鎖，鎖的過期時間被延長，其它Client需要等待更久的時間

V2.0 基於SETNX

tryLock(){  
    SETNX Key 1 Seconds
}
release(){  
  DELETE Key
}

Redis 2.6.12版本後SETNX增加過期時間參數，這樣就解決了兩條命令無法保證原子性的問題。但是設想下面一個場景：

  1. C1成功獲取到了鎖，之後C1因為GC進入等待或者未知原因導致任務執行過長，最後在鎖失效前C1沒有主動釋放鎖

  2. C2在C1的鎖超時後獲取到鎖，並且開始執行，這個時候C1和C2都同時在執行，會因重復執行造成數據不一致等未知情況

  3. C1如果先執行完畢，則會釋放C2的鎖，此時可能導致另外一個C3進程獲取到了鎖

大致的流程圖

技術分享圖片

存在問題：

  1. 由於C1的停頓導致C1 和C2同都獲得了鎖並且同時在執行，在業務實現間接要求必須保證冪等性

  2. C1釋放了不屬於C1的鎖

V3.0

tryLock(){  
    SETNX Key UnixTimestamp Seconds
}
release(){  
    EVAL(
      //LuaScript
      if redis.call("get",KEYS[1]) == ARGV[1] then
          return redis.call("del",KEYS[1])
      else
          return 0
      end
    )
}

這個方案通過指定Value為時間戳，並在釋放鎖的時候檢查鎖的Value是否為獲取鎖的Value，避免了V2.0版本中提到的C1釋放了C2持有的鎖的問題；另外在釋放鎖的時候因為涉及到多個Redis操作，並且考慮到Check And Set 模型的並發問題，所以使用Lua腳本來避免並發問題。

存在問題：

如果在並發極高的場景下，比如搶紅包場景，可能存在UnixTimestamp重復問題，另外由於不能保證分布式環境下的物理時鐘一致性，也可能存在UnixTimestamp重復問題，只不過極少情況下會遇到。

tryLock(){  
    SET Key UniqId Seconds
}
release(){  
    EVAL(
      //LuaScript
      if redis.call("get",KEYS[1]) == ARGV[1] then
          return redis.call("del",KEYS[1])
      else
          return 0
      end
    )
}

Redis 2.6.12後SET同樣提供了一個NX參數，等同於SETNX命令，官方文檔上提醒後面的版本有可能去掉SETNX, SETEX, PSETEX,並用SET命令代替，另外一個優化是使用一個自增的唯一UniqId代替時間戳來規避V3.0提到的時鐘問題。

這個方案是目前最優的分布式鎖方案，但是如果在Redis集群環境下依然存在問題：

由於Redis集群數據同步為異步，假設在Master節點獲取到鎖後未完成數據同步情況下Master節點crash，此時在新的Master節點依然可以獲取鎖，所以多個Client同時獲取到了鎖

分布式Redis鎖：Redlock

V3.1的版本僅在單實例的場景下是安全的，針對如何實現分布式Redis的鎖，國外的分布式專家有過激烈的討論， antirez提出了分布式鎖算法Redlock，在distlock話題下可以看到對Redlock的詳細說明，下面是Redlock算法的一個中文說明（引用）

假設有N個獨立的Redis節點

  1. 獲取當前時間（毫秒數）。

  2. 按順序依次向N個Redis節點執行獲取鎖的操作。這個獲取操作跟前面基於單Redis節點的獲取鎖的過程相同，包含隨機字符串my_random_value，也包含過期時間(比如PX 30000，即鎖的有效時間)。為了保證在某個Redis節點不可用的時候算法能夠繼續運行，這個獲取鎖的操作還有一個超時時間(time out)，它要遠小於鎖的有效時間（幾十毫秒量級）。客戶端在向某個Redis節點獲取鎖失敗以後，應該立即嘗試下一個Redis節點。這裏的失敗，應該包含任何類型的失敗，比如該Redis節點不可用，或者該Redis節點上的鎖已經被其它客戶端持有（註：Redlock原文中這裏只提到了Redis節點不可用的情況，但也應該包含其它的失敗情況）。

  3. 計算整個獲取鎖的過程總共消耗了多長時間，計算方法是用當前時間減去第1步記錄的時間。如果客戶端從大多數Redis節點（>= N/2+1）成功獲取到了鎖，並且獲取鎖總共消耗的時間沒有超過鎖的有效時間(lock validity time)，那麽這時客戶端才認為最終獲取鎖成功；否則，認為最終獲取鎖失敗。

  4. 如果最終獲取鎖成功了，那麽這個鎖的有效時間應該重新計算，它等於最初的鎖的有效時間減去第3步計算出來的獲取鎖消耗的時間。

  5. 如果最終獲取鎖失敗了（可能由於獲取到鎖的Redis節點個數少於N/2+1，或者整個獲取鎖的過程消耗的時間超過了鎖的最初有效時間），那麽客戶端應該立即向所有Redis節點發起釋放鎖的操作（即前面介紹的Redis Lua腳本）。

  6. 釋放鎖：對所有的Redis節點發起釋放鎖操作

然而Martin Kleppmann針對這個算法提出了質疑，提出應該基於fencing token機制（每次對資源進行操作都需要進行token驗證）

  1. Redlock在系統模型上尤其是在分布式時鐘一致性問題上提出了假設，實際場景下存在時鐘不一致和時鐘跳躍問題，而Redlock恰恰是基於timing的分布式鎖

  2. 另外Redlock由於是基於自動過期機制，依然沒有解決長時間的gc pause等問題帶來的鎖自動失效，從而帶來的安全性問題。

接著antirez又回復了Martin Kleppmann的質疑，給出了過期機制的合理性，以及實際場景中如果出現停頓問題導致多個Client同時訪問資源的情況下如何處理。

針對Redlock的問題，基於Redis的分布式鎖到底安全嗎給出了詳細的中文說明，並對Redlock算法存在的問題提出了分析。

總結

V3.1的版本僅在單實例的場景下是安全的，針對如何實現分布式Redis的鎖，國外的分布式專家有過激烈的討論， antirez提出了分布式鎖算法Redlock，在distlock話題下可以看到對Redlock的詳細說明，下面是Redlock算法的一個中文說明（引用）

假設有N個獨立的Redis節點

  1. 獲取當前時間（毫秒數）。

  2. 按順序依次向N個Redis節點執行獲取鎖的操作。這個獲取操作跟前面基於單Redis節點的獲取鎖的過程相同，包含隨機字符串my_random_value，也包含過期時間(比如PX 30000，即鎖的有效時間)。為了保證在某個Redis節點不可用的時候算法能夠繼續運行，這個獲取鎖的操作還有一個超時時間(time out)，它要遠小於鎖的有效時間（幾十毫秒量級）。客戶端在向某個Redis節點獲取鎖失敗以後，應該立即嘗試下一個Redis節點。這裏的失敗，應該包含任何類型的失敗，比如該Redis節點不可用，或者該Redis節點上的鎖已經被其它客戶端持有（註：Redlock原文中這裏只提到了Redis節點不可用的情況，但也應該包含其它的失敗情況）。

  3. 計算整個獲取鎖的過程總共消耗了多長時間，計算方法是用當前時間減去第1步記錄的時間。如果客戶端從大多數Redis節點（>= N/2+1）成功獲取到了鎖，並且獲取鎖總共消耗的時間沒有超過鎖的有效時間(lock validity time)，那麽這時客戶端才認為最終獲取鎖成功；否則，認為最終獲取鎖失敗。

  4. 如果最終獲取鎖成功了，那麽這個鎖的有效時間應該重新計算，它等於最初的鎖的有效時間減去第3步計算出來的獲取鎖消耗的時間。

  5. 如果最終獲取鎖失敗了（可能由於獲取到鎖的Redis節點個數少於N/2+1，或者整個獲取鎖的過程消耗的時間超過了鎖的最初有效時間），那麽客戶端應該立即向所有Redis節點發起釋放鎖的操作（即前面介紹的Redis Lua腳本）。

  6. 釋放鎖：對所有的Redis節點發起釋放鎖操作

然而Martin Kleppmann針對這個算法提出了質疑，提出應該基於fencing token機制（每次對資源進行操作都需要進行token驗證）

  1. Redlock在系統模型上尤其是在分布式時鐘一致性問題上提出了假設，實際場景下存在時鐘不一致和時鐘跳躍問題，而Redlock恰恰是基於timing的分布式鎖

  2. 另外Redlock由於是基於自動過期機制，依然沒有解決長時間的gc pause等問題帶來的鎖自動失效，從而帶來的安全性問題。

接著antirez又回復了Martin Kleppmann的質疑，給出了過期機制的合理性，以及實際場景中如果出現停頓問題導致多個Client同時訪問資源的情況下如何處理。

針對Redlock的問題，基於Redis的分布式鎖到底安全嗎給出了詳細的中文說明，並對Redlock算法存在的問題提出了分析。

總結

不論是基於SETNX版本的Redis單實例分布式鎖，還是Redlock分布式鎖，都是為了保證下特性

  1. 安全性：在同一時間不允許多個Client同時持有鎖

  2. 活性
    死鎖：鎖最終應該能夠被釋放，即使Client端crash或者出現網絡分區（通常基於超時機制）
    容錯性：只要超過半數Redis節點可用，鎖都能被正確獲取和釋放

所以在開發或者使用分布式鎖的過程中要保證安全性和活性，避免出現不可預測的結果。

另外每個版本的分布式鎖都存在一些問題，在鎖的使用上要針對鎖的實用場景選擇合適的鎖，通常情況下鎖的使用場景包括：

Efficiency(效率)：只需要一個Client來完成操作，不需要重復執行，這是一個對寬松的分布式鎖，只需要保證鎖的活性即可；

Correctness(正確性)：多個Client保證嚴格的互斥性，不允許出現同時持有鎖或者對同時操作同一資源，這種場景下需要在鎖的選擇和使用上更加嚴格，同時在業務代碼上盡量做到冪等

在Redis分布式鎖的實現上還有很多問題等待解決，我們需要認識到這些問題並清楚如何正確實現一個Redis 分布式鎖，然後在工作中合理的選擇和正確的使用分布式鎖。

轉自：https://mp.weixin.qq.com/s/y2HPj2ji2KLS_eTR5nBnDA

一文看透 Redis 分布式鎖進化史（解讀 + 缺陷分析）（轉）

相關推薦

一文看透 Redis 分布式鎖進化史（解讀 + 缺陷分析）（轉）

turn 說明 方式 它的 思路 機制 ets 3.0 去掉 近兩年來微服務變得越來越熱門，越來越多的應用部署在分布式環境中，在分布式環境中，數據一致性是一直以來需要關註並且去解決的問題，分布式鎖也就成為了一種廣泛使用的技術，常用的分布式實現方式為Redis，Zookeep

三種分布式鎖 簡易說說(包含前一篇提到的redis分布式鎖)

出現 lan tro 簡易 sci aaa 數據 其它 無法 大多數互聯網系統都是分布式部署的，分布式部署確實能帶來性能和效率上的提升，但為此，我們就需要多解決一個分布式環境下，數據一致性的問題。 當某個資源在多系統之間，具有共享性的時候，為了保證大家訪問這個資源數據是

【原創】redis庫存操作，分布式鎖的四種實現方式[連載一]--基於zookeeper實現分布式鎖

zookeepe operation iat 並發 method logger 方案 nag 概念 一、背景 在電商系統中，庫存的概念一定是有的，例如配一些商品的庫存，做商品秒殺活動等，而由於庫存操作頻繁且要求原子性操作，所以絕大多數電商系統都用Redis來實現庫存的加減，

redisLock redis分布式鎖

服務器 java status redis setnx 命令redis setnx 命令特性當指定key不存在時才設置。也就是說，如果返回1說明你的命令被執行成功了，redis服務器中的key是你之前設置的值。如果返回0，說明你設置的key在redis服務器裏已經存在。 st

redis分布式鎖和消息隊列

chan 不能 包括 監聽 插入 目前 ren ret clas 最近博主在看redis的時候發現了兩種redis使用方式，與之前redis作為緩存不同，利用的是redis可設置key的有效時間和redis的BRPOP命令。 分布式鎖 由於目前一些編程語言，如PHP等，不能

C#操作Redis,C#實現Redis分布式鎖

ges mage c# png http 字符串 images red -s 功能描述 字符串常規操作 hashset操作 set操作 keys操作 分布式鎖操作 代碼截圖 購買詳詢：QQ 506023315，只要10元（屌絲籌房中） C#操作Red

關於redis分布式鎖的實現方式（轉載）

iss tree red org 實現 方式 分布式 uda master 這個是在網上找到的一個大神寫的（http://wudashan.cn/2017/10/23/Redis-Distributed-Lock-Implement/），對於分布式redis部署的，可以參考

spring boot redis分布式鎖

supported 分布式架構 tsig utils ali 成了 down eva -- 隨著現在分布式架構越來越盛行，在很多場景下需要使用到分布式鎖。分布式鎖的實現有很多種，比如基於數據庫、 zookeeper 等，本文主要介紹使用 Redis 做分布式鎖的方式，並封

Redis分布式鎖解決搶購問題

業務 ret target 執行 線程 top 進行 出了 數據庫 首先分享一個業務場景-搶購。一個典型的高並發問題，所需的最關鍵字段就是庫存，在高並發的情況下每次都去數據庫查詢顯然是不合適的，因此把庫存信息存入Redis中，利用redis的鎖機制來控制並發訪問，是一個不錯

redis分布式鎖原理

clas 並且 例子 允許 要去 否則 先後 個人 nbsp 舉例子：秒殺方式看醫生，一個人看5min 1.第一次只允許一個人直接進行來，X10:00:00進去了，setNX（roomid,now+5min），出來時間假如是10:05:00 2.時間到了10:05:00，3

Redis分布式鎖及分區

多個進程 clas 存儲 crc32 可用 處理 核心 數字 由於 以下內容是翻譯的官網文檔RedLock和分區部分，可以簡單了解分布式鎖在redis如何實現及其方式 redis分區的方法 redis實現的分布式鎖RedLock算法，分布式鎖，即在多個master上獲取同一

redis分布式鎖-SETNX實現

超時值 大於 cep sel 誤差 exists rap sim 理解 Redis有一系列的命令，特點是以NX結尾，NX是Not eXists的縮寫，如SETNX命令就應該理解為：SET if Not eXists。這系列的命令非常有用，這裏講使用SETNX來實現分布式

Redis分布式鎖的try-with-resources實現

故障 rgs 是不是 str .exe stat 等於 通過 except Redis分布式鎖的try-with-resources實現 一、簡介 在當今這個時代，單體應用（standalone）已經很少了，java提供的synchronized已經不能滿足需求，大家自然

Redis分布式鎖的正確實現方式

想要 argv 只有一個 AD redis單機 lease 兩條命令 bject 支持 前言 分布式鎖一般有三種實現方式：1. 數據庫樂觀鎖；2. 基於Redis的分布式鎖；3. 基於ZooKeeper的分布式鎖。本篇博客將介紹第二種方式，基於Redis實現分布式鎖。雖

redis分布式鎖實現

一點 src 如果 只有一個 util 會有 取值 刪除 自己的 一、使用分布式鎖要滿足的幾個條件： 系統是一個分布式系統（關鍵是分布式，單機的可以使用ReentrantLock或者synchronized代碼塊來實現） 共享資源（各個系統訪問同一個資源，資源的載體可能是

Redis分布式鎖

res 哪裏 pan not domu 而且 jedis 校驗 else 轉自：https://www.cnblogs.com/linjiqin/p/8003838.html 前言 分布式鎖一般有三種實現方式：1. 數據庫樂觀鎖；2. 基於Redis的分布式鎖；3. 基

Redis 分布式鎖的正確實現方式

單機 滿足 AR 執行 發現 命令 dom 為什麽 tdi 前言 分布式鎖一般有三種實現方式：1. 數據庫樂觀鎖；2. 基於Redis的分布式鎖；3. 基於ZooKeeper的分布式鎖。本篇博客將介紹第二種方式，基於Redis實現分布式鎖。 可靠性 首先，為了確保分布式

redis分布式鎖和lua腳本

out disco sha1 標準 sign OS .get 浮點數 ins 業務背景：存儲請求參數token ，token唯一 ，且新的生成舊的失效 思路：因為是多臺機器，獲取token存入redis，保持唯一，考慮使用redis來加鎖，其實就是在redis中存一個key

redis 分布式鎖

runnable dom @param set tostring 執行 時間 integer oid 在分布式系統中，之前單一的用synchronized或lock已經不適用了。分布式鎖一般有三種實現方式：1. 數據庫樂觀鎖；2. 基於Redis的分布式鎖；3. 基於Zoo

基於redis分布式鎖實現“秒殺”

購物車 串行 and 本質 希望 ide stack 失敗 業務場景 最近在項目中遇到了類似“秒殺”的業務場景，在本篇博客中，我將用一個非常簡單的demo，闡述實現所謂“秒殺”的基本思路。 業務場景 所謂秒殺，從業務角度看，是短時間內多個用戶“爭搶”資源，這裏的資源在大部分