2. 程式人生 > >Redis(3)——分散式鎖深入探究

Redis(3)——分散式鎖深入探究

阿新 • • 發佈：2020-03-01

一、分散式鎖簡介

鎖 是一種用來解決多個執行執行緒 訪問共享資源 錯誤或資料不一致問題的工具。

如果 把一臺伺服器比作一個房子，那麼 執行緒就好比裡面的住戶，當他們想要共同訪問一個共享資源，例如廁所的時候，如果廁所門上沒有鎖...更甚者廁所沒裝門...這是會出原則性的問題的..

裝上了鎖，大家用起來就安心多了，本質也就是 同一時間只允許一個住戶使用。

而隨著網際網路世界的發展，單體應用已經越來越無法滿足複雜網際網路的高併發需求，轉而慢慢朝著分散式方向發展，慢慢進化成了 更大一些的住戶。所以同樣，我們需要引入分散式鎖來解決分散式應用之間訪問共享資源的併發問題。

為何需要分散式鎖

一般情況下，我們使用分散式鎖主要有兩個場景：

  1. 避免不同節點重複相同的工作：比如使用者執行了某個操作有可能不同節點會發送多封郵件；
  2. 避免破壞資料的正確性：如果兩個節點在同一條資料上同時進行操作，可能會造成資料錯誤或不一致的情況出現；

Java 中實現的常見方式

上面我們用簡單的比喻說明了鎖的本質：同一時間只允許一個使用者操作。所以理論上，能夠滿足這個需求的工具我們都能夠使用 (就是其他應用能幫我們加鎖的)：

  1. 基於 MySQL 中的鎖：MySQL 本身有自帶的悲觀鎖 for update 關鍵字，也可以自己實現悲觀/樂觀鎖來達到目的；
  2. 基於 Zookeeper 有序節點：Zookeeper 允許臨時建立有序的子節點，這樣客戶端獲取節點列表時，就能夠當前子節點列表中的序號判斷是否能夠獲得鎖；
  3. 基於 Redis 的單執行緒：由於 Redis 是單執行緒，所以命令會以序列的方式執行，並且本身提供了像 SETNX(set if not exists) 這樣的指令，本身具有互斥性；

每個方案都有各自的優缺點，例如 MySQL 雖然直觀理解容易，但是實現起來卻需要額外考慮 鎖超時、加事務 等，並且效能侷限於資料庫，諸如此類我們在此不作討論，重點關注 Redis。

Redis 分散式鎖的問題

1）鎖超時

假設現在我們有兩臺平行的服務 A B，其中 A 服務在 獲取鎖之後 由於未知神祕力量突然 掛了，那麼 B 服務就永遠無法獲取到鎖了：

所以我們需要額外設定一個超時時間，來保證服務的可用性。

但是另一個問題隨即而來：如果在加鎖和釋放鎖之間的邏輯執行得太長，以至於超出了鎖的超時限制，也會出現問題。因為這時候第一個執行緒持有鎖過期了，而臨界區的邏輯還沒有執行完，與此同時第二個執行緒就提前擁有了這把鎖，導致臨界區的程式碼不能得到嚴格的序列執行。

為了避免這個問題，Redis 分散式鎖不要用於較長時間的任務。如果真的偶爾出現了問題，造成的資料小錯亂可能就需要人工的干預。

有一個稍微安全一點的方案是 將鎖的 value 值設定為一個隨機數，釋放鎖時先匹配隨機數是否一致，然後再刪除 key，這是為了 確保當前執行緒佔有的鎖不會被其他執行緒釋放，除非這個鎖是因為過期了而被伺服器自動釋放的。

但是匹配 value 和刪除 key 在 Redis 中並不是一個原子性的操作，也沒有類似保證原子性的指令，所以可能需要使用像 Lua 這樣的指令碼來處理了，因為 Lua 指令碼可以 保證多個指令的原子性執行。

延伸的討論：GC 可能引發的安全問題

Martin Kleppmann 曾與 Redis 之父 Antirez 就 Redis 實現分散式鎖的安全性問題進行過深入的討論，其中有一個問題就涉及到 GC。

熟悉 Java 的同學肯定對 GC 不陌生，在 GC 的時候會發生 STW(Stop-The-World)，這本身是為了保障垃圾回收器的正常執行，但可能會引發如下的問題：

服務 A 獲取了鎖並設定了超時時間，但是服務 A 出現了 STW 且時間較長，導致了分散式鎖進行了超時釋放，在這個期間服務 B 獲取到了鎖，待服務 A STW 結束之後又恢復了鎖，這就導致了 服務 A 和服務 B 同時獲取到了鎖，這個時候分散式鎖就不安全了。

不僅僅侷限於 Redis，Zookeeper 和 MySQL 有同樣的問題。

想吃更多瓜的童鞋，可以訪問下列網站看看 Redis 之父 Antirez 怎麼說：http://antirez.com/news/101

2）單點/多點問題

如果 Redis 採用單機部署模式，那就意味著當 Redis 故障了，就會導致整個服務不可用。

而如果採用主從模式部署，我們想象一個這樣的場景：服務 A 申請到一把鎖之後，如果作為主機的 Redis 宕機了，那麼 服務 B 在申請鎖的時候就會從從機那裡獲取到這把鎖，為了解決這個問題，Redis 作者提出了一種 RedLock 紅鎖 的演算法 (Redission 同 Jedis)：

// 三個 Redis 叢集
RLock lock1 = redissionInstance1.getLock("lock1");
RLock lock2 = redissionInstance2.getLock("lock2");
RLock lock3 = redissionInstance3.getLock("lock3");

RedissionRedLock lock = new RedissionLock(lock1, lock2, lock2);
lock.lock();
// do something....
lock.unlock();

二、Redis 分散式鎖的實現

分散式鎖類似於 "佔坑"，而 SETNX(SET if Not eXists) 指令就是這樣的一個操作，只允許被一個客戶端佔有，我們來看看 原始碼(t_string.c/setGenericCommand) 吧：

// SET/ SETEX/ SETTEX/ SETNX 最底層實現
void setGenericCommand(client *c, int flags, robj *key, robj *val, robj *expire, int unit, robj *ok_reply, robj *abort_reply) {
    long long milliseconds = 0; /* initialized to avoid any harmness warning */

    // 如果定義了 key 的過期時間則儲存到上面定義的變數中
    // 如果過期時間設定錯誤則返回錯誤資訊
    if (expire) {
        if (getLongLongFromObjectOrReply(c, expire, &milliseconds, NULL) != C_OK)
            return;
        if (milliseconds <= 0) {
            addReplyErrorFormat(c,"invalid expire time in %s",c->cmd->name);
            return;
        }
        if (unit == UNIT_SECONDS) milliseconds *= 1000;
    }

    // lookupKeyWrite 函式是為執行寫操作而取出 key 的值物件
    // 這裡的判斷條件是：
    // 1.如果設定了 NX(不存在)，並且在資料庫中找到了 key 值
    // 2.或者設定了 XX(存在)，並且在資料庫中沒有找到該 key
    // => 那麼回覆 abort_reply 給客戶端
    if ((flags & OBJ_SET_NX && lookupKeyWrite(c->db,key) != NULL) ||
        (flags & OBJ_SET_XX && lookupKeyWrite(c->db,key) == NULL))
    {
        addReply(c, abort_reply ? abort_reply : shared.null[c->resp]);
        return;
    }
    
    // 在當前的資料庫中設定鍵為 key 值為 value 的資料
    genericSetKey(c->db,key,val,flags & OBJ_SET_KEEPTTL);
    // 伺服器每修改一個 key 後都會修改 dirty 值
    server.dirty++;
    if (expire) setExpire(c,c->db,key,mstime()+milliseconds);
    notifyKeyspaceEvent(NOTIFY_STRING,"set",key,c->db->id);
    if (expire) notifyKeyspaceEvent(NOTIFY_GENERIC,
        "expire",key,c->db->id);
    addReply(c, ok_reply ? ok_reply : shared.ok);
}

就像上面介紹的那樣，其實在之前版本的 Redis 中，由於 SETNX 和 EXPIRE 並不是 原子指令，所以在一起執行會出現問題。

也許你會想到使用 Redis 事務來解決，但在這裡不行，因為 EXPIRE 命令依賴於 SETNX 的執行結果，而事務中沒有 if-else 的分支邏輯，如果 SETNX 沒有搶到鎖，EXPIRE 就不應該執行。

為了解決這個疑難問題，Redis 開源社群湧現了許多分散式鎖的 library，為了治理這個亂象，後來在 Redis 2.8 的版本中，加入了 SET 指令的擴充套件引數，使得 SETNX 可以和 EXPIRE 指令一起執行了：

> SET lock:test true ex 5 nx
OK
... do something critical ...
> del lock:test

你只需要符合 SET key value [EX seconds | PX milliseconds] [NX | XX] [KEEPTTL] 這樣的格式就好了，你也在下方右拐參照官方的文件：

  • 官方文件：https://redis.io/commands/set

另外，官方文件也在 SETNX 文件中提到了這樣一種思路：把 SETNX 對應 key 的 value 設定為 <current Unix time + lock timeout + 1>，這樣在其他客戶端訪問時就能夠自己判斷是否能夠獲取下一個 value 為上述格式的鎖了。

程式碼實現

下面用 Jedis 來模擬實現以下，關鍵程式碼如下：

private static final String LOCK_SUCCESS = "OK";
private static final Long RELEASE_SUCCESS = 1L;
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";

@Override
public String acquire() {
    try {
        // 獲取鎖的超時時間，超過這個時間則放棄獲取鎖
        long end = System.currentTimeMillis() + acquireTimeout;
        // 隨機生成一個 value
        String requireToken = UUID.randomUUID().toString();
        while (System.currentTimeMillis() < end) {
            String result = jedis
                .set(lockKey, requireToken, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
            if (LOCK_SUCCESS.equals(result)) {
                return requireToken;
            }
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    } catch (Exception e) {
        log.error("acquire lock due to error", e);
    }

    return null;
}

@Override
public boolean release(String identify) {
    if (identify == null) {
        return false;
    }

    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    Object result = new Object();
    try {
        result = jedis.eval(script, Collections.singletonList(lockKey),
            Collections.singletonList(identify));
        if (RELEASE_SUCCESS.equals(result)) {
            log.info("release lock success, requestToken:{}", identify);
            return true;
        }
    } catch (Exception e) {
        log.error("release lock due to error", e);
    } finally {
        if (jedis != null) {
            jedis.close();
        }
    }

    log.info("release lock failed, requestToken:{}, result:{}", identify, result);
    return false;
}
  • 引用自下方 參考資料 3，其中還有 RedLock 的實現和測試，有興趣的童鞋可以戳一下

推薦閱讀

  1. 【官方文件】Distributed locks with Redis - https://redis.io/topics/distlock
  2. Redis【入門】就這一篇! - https://www.wmyskxz.com/2018/05/31/redis-ru-men-jiu-zhe-yi-pian/
  3. Redission - Redis Java Client 原始碼 - https://github.com/redisson/redisson
  4. 手寫一個 Jedis 以及 JedisPool - https://juejin.im/post/5e5101c46fb9a07cab3a953a

參考資料

  1. 再有人問你分散式鎖，這篇文章扔給他 - https://juejin.im/post/5bbb0d8df265da0abd3533a5#heading-0
  2. 【官方文件】Distributed locks with Redis - https://redis.io/topics/distlock
  3. 【分散式快取系列】Redis實現分散式鎖的正確姿勢 - https://www.cnblogs.com/zhili/p/redisdistributelock.html
  4. Redis原始碼剖析和註釋（九）--- 字串命令的實現(t_string) - https://blog.csdn.net/men_wen/article/details/70325566
  5. 《Redis 深度歷險》 - 錢文品/ 著
  • 本文已收錄至我的 Github 程式設計師成長系列 【More Than Java】，學習，不止 Code，歡迎 star：https://github.com/wmyskxz/MoreThanJava
  • 個人公眾號 ：wmyskxz，個人獨立域名部落格：wmyskxz.com，堅持原創輸出，下方掃碼關注，2020，與您共同成長！

非常感謝各位人才能 看到這裡，如果覺得本篇文章寫得不錯，覺得 「我沒有三顆心臟」有點東西 的話，求點贊，求關注，求分享，求留言！

創作不易，各位的支援和認可，就是我創作的最大動力，我們下篇文章見

相關推薦

Redis(3)——分散式鎖深入探究

一、分散式鎖簡介 鎖 是一種用來解決多個執行執行緒 訪問共享資源 錯誤或資料不一致問題的工具。 如果 把一臺伺服器比作一個房子，那麼 執行緒就好比裡面的住戶，當他們想要共同訪問一個共享資源，例如廁所的時候，如果廁所門上沒有鎖...更甚者廁所沒裝門...這是會出原則性的問題的.. 裝上了鎖，大家用起來就

實現基於redis的分散式鎖並整合spring-boot-starter

文章目錄 概述 使用 1.導包 2.寫一個實現鎖功能的service 3.檢查redis的key 4.呼叫（鎖成功） 5.呼叫（鎖失敗） 實現

Redis之分散式鎖的原理

一、使用分散式鎖要滿足的幾個條件： 系統是一個分散式系統（關鍵是分散式，單機的可以使用ReentrantLock或者synchronized程式碼塊來實現，即單程序多個執行緒訪問的話） 共享資源（各個系統訪問同一個資源，資源的載體可能是傳統關係型資料庫或者NoSQL） 同步訪問

【redis】使用redisTemplate優雅地操作redis及使用redis實現分散式鎖

前言: 上篇已經介紹了redis及如何安裝和叢集redis,這篇介紹如何通過工具優雅地操作redis. Long Long ago,程式猿們還在通過jedis來操作著redis,那時候的猿類,一個個累的沒日沒夜,重複的造著輪子,忙得沒時間陪家人,終於有一天猿類的春天來了,spring家族的r

【轉】【Redis】分散式鎖的幾種使用方式（redis、zookeeper、資料庫）

https://blog.csdn.net/u010963948/article/details/79006572?utm_source=blogxgwz9 https://blog.csdn.net/qq_37606901/article/details/79569250?utm_source

基於redis的分散式鎖(轉)

基於redis的分散式鎖 1 介紹 這篇博文講介紹如何一步步構建一個基於Redis的分散式鎖。會從最原始的版本開始，然後根據問題進行調整，最後完成一個較為合理的分散式鎖。 本篇文章會將分散式鎖的實現分為兩部分，一個是單機環境，另一個是叢集環境下的Redis鎖實現。在介紹分散式鎖的實

基於Redis實現分散式鎖

背景 在很多網際網路產品應用中，有些場景需要加鎖處理，比如：秒殺，全域性遞增ID，樓層生成等等。大部分的解決方案是基於DB實現的，Redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶端對Redis的連線並不存在競爭關係。其次Redis提供一些命令SETNX，GETSET，可以方便

利用Redis實現分散式鎖 使用mysql樂觀鎖解決併發問題

寫在最前面 我在之前總結冪等性的時候，寫過一種分散式鎖的實現，可惜當時沒有真正應用過，著實的心虛啊。正好這段時間對這部分實踐了一下，也算是對之前填坑了。 分散式鎖按照網上的結論，大致分為三種：1、資料庫樂觀鎖； 2、基於Redis的分散式鎖；3.、基於ZooKeeper的分散式鎖； 關於樂觀鎖的實現其實

利用Redis實現分散式鎖

為什麼需要分散式鎖？ 在傳統單體應用單機部署的情況下，可以使用Java併發相關的鎖，如ReentrantLcok或synchronized進行互斥控制。但是，隨著業務發展的需要，原單體單機部署的系統，漸漸的被部署在多機器多JVM上同時提供服務，這使得原單機部署情況下的併發控制鎖策略失效了，為了解決這個問

如何用 Redis 實現分散式鎖和超時情況處理

目前各種分散式的架構和微服務架構無處不在，在這種類似架構中處理併發和分散式併發問題，本場 Chat 就主要以 Redis 為例，使用分散式鎖的方式如何處理併發問題和避免超時情況的出現，主要從以下幾個方面講述： Redis 的 Setnx 命令是如何實現分散式鎖的； Setnx 的實現鎖的

dubbo 常用的基於redis的分散式鎖實現

  小弟本著先會用在學習原理的原則 先用了dubbo 現在在實際業務中 因為分散式專案做了叢集，需要用的分散式鎖，就用到了基於redis的分散式鎖，廢話不多說，先來程式碼： package com.tiancaibao.utils; import org.slf4j.Logger

[翻譯]基於redis的分散式鎖

本篇翻譯自【redis.io/topics/dist… 在很多不同程序必須以相互排斥的方式競爭分片資源的情況下，分散式鎖是非常有用的原始功能。 有很多的實現和部落格都描述瞭如何基於Redis來實現分散式鎖管理器（DLM，Distributed Lock Manager）。有的使用了不同的途徑，但是大多都是

使用redis做分散式鎖

1、使用setnx命令。先看下官方文件http://redis.cn/commands/setnx.html 2、使用getset命令。先獲取，再set   實現案例： 　　 * create 2018-12-03 16:22 * <p> * desc **/ @Compo

ZooKeeper分散式鎖簡單實踐 利用Redis實現分散式鎖

寫在最前面 前幾周寫了篇 利用Redis實現分散式鎖 ，今天簡單總結下ZooKeeper實現分散式鎖的過程。其實生產上我只用過Redis或者資料庫的方式，之前還真沒了解過ZooKeeper怎麼實現分散式鎖。這周簡單寫了個小Demo，更堅定了我繼續使用Redis的信心了。 ZooKeep

Redis之分散式鎖

　　一、加鎖原因 　　 　　二、原子操作 　　 　　三、分散式鎖 　　 　　四、分散式鎖常見問題 　　 　　一、加鎖原因 　　 　　在一些比較高併發的業務場景，經常聽到通過加鎖的方法實現執行緒安全。 　　 　　下面簡單介紹一下 　　 　　1.1 加鎖方式 　　 　　資料庫鎖 　　 　　資料庫本身提供了鎖機制，

分散式鎖-使用Redis實現分散式鎖

使用Redis實現分散式鎖 關於分散式鎖的實現，我的前一篇文章講解了如何使用Zookeeper實現分散式鎖。關於分散式鎖的背景此處不再做贅述，我們直接討論下如何使用Redis實現分散式鎖。 關於Redis，筆主不打算做長篇大論的介紹，只介紹下Redis優秀的特性

REDIS 學習（10）流程圖解使用redis實現分散式鎖

redis作為集中式快取，可以通過它來實現分散式鎖。 首先用到的redis操作有： setnx key value:      當key不存在的時候生效並返回1，當已經有此key的時候返回0 getset key value:    

RedLock演算法-使用redis實現分散式鎖服務

譯自Redis官方文件 在多執行緒共享臨界資源的場景下，分散式鎖是一種非常重要的元件。 許多庫使用不同的方式使用redis實現一個分散式鎖管理。 其中有一部分簡單的實現方式可靠性不足，可以通過一些簡單的修改提高其可靠性。 這篇文章介紹了一種指導性的redis分散式鎖演算法RedLock，RedL

基於redis的分散式鎖 | 併發程式設計網

1 介紹 這篇博文講介紹如何一步步構建一個基於Redis的分散式鎖。會從最原始的版本開始，然後根據問題進行調整，最後完成一個較為合理的分散式鎖。 本篇文章會將分散式鎖的實現分為兩部分，一個是單機環境，另一個是叢集環境下的Redis鎖實現。在介紹分散式鎖的實現之前，先來了解下分散式鎖的一些資訊。 2 分散式

Redis實現分散式鎖（spring定時任務叢集應用Redis分散式鎖）

         之前2片文章介紹了 描述：              不管用不用動態執行，單機服務都是沒有問題的，但是如果服務是叢集模式下，那麼一個任務在每臺機器都會執行一次，這肯定不是我們需要的，我們要實現的是整個叢集每次只有一個任務執行成功，但是spring