redis — Redis分佈式鎖之Redlock（五）

1、引言

說到Redis分佈式鎖大部分人都會想到：setnx+lua，或者知道set key value px milliseconds nx。這種實現方式有3大要點（也是面試概率非常高的地方）：

set命令要用set key value px milliseconds nx；
value要具有唯一性；
釋放鎖時要驗證value值，不能誤解鎖；

事實上這類瑣最大的缺點就是它加鎖時只作用在一個Redis節點上，即使Redis通過sentinel保證高可用，如果這個master節點由於某些原因發生了主從切換，那麼就會出現鎖丟失的情況：

在Redis的master節點上拿到了鎖；
但是這個加鎖的key還沒有同步到slave節點；
master故障，發生故障轉移，slave節點升級爲master節點；
導致鎖丟失。

正因爲如此，Redis作者antirez基於分佈式環境下提出了一種更高級的分佈式鎖的實現方式：Redlock。

2、Redlock算法

在Redis的分佈式環境中，我們假設有N個Redis master。這些節點完全互相獨立，不存在主從複製或者其他集羣協調機制。我們確保將在N個實例上使用與在Redis單實例下相同方法獲取和釋放鎖。現在我們假設有5個Redis master節點，同時我們需要在5臺服務器上面運行這些Redis實例，這樣保證他們不會同時都宕掉。

爲了取到鎖，客戶端應該執行以下操作:

獲取當前Unix時間，以毫秒爲單位。
依次嘗試從5個實例，使用相同的key和具有唯一性的value（例如UUID）獲取鎖。當向Redis請求獲取鎖時，客戶端應該設置一個網絡連接和響應超時時間，這個超時時間應該小於鎖的失效時間。例如你的鎖自動失效時間爲10秒，則超時時間應該在5-50毫秒之間。這樣可以避免服務器端Redis已經掛掉的情況下，客戶端還在死死地等待響應結果。如果服務器端沒有在規定時間內響應，客戶端應該儘快嘗試去另外一個Redis實例請求獲取鎖。
客戶端使用當前時間減去開始獲取鎖時間（步驟1記錄的時間）就得到獲取鎖使用的時間。當且僅當從大多數（N/2+1，這裏是3個節點）的Redis節點都取到鎖，並且使用的時間小於鎖失效時間時，鎖纔算獲取成功。
如果取到了鎖，key的真正有效時間等於有效時間減去獲取鎖所使用的時間（步驟3計算的結果）。
如果因爲某些原因，獲取鎖失敗（沒有在至少N/2+1個Redis實例取到鎖或者取鎖時間已經超過了有效時間），客戶端應該在所有的Redis實例上進行解鎖（即便某些Redis實例根本就沒有加鎖成功，防止某些節點獲取到鎖但是客戶端沒有得到響應而導致接下來的一段時間不能被重新獲取鎖）。

3、Redisson

Redisson 是用於在 Java 程序中操作 Redis 的庫，它使得我們可以在程序中輕鬆地使用 Redis。Redisson 在 java.util 中常用接口的基礎上，爲我們提供了一系列具有分佈式特性的工具類。下文主要對其分佈式鎖進行介紹，其他特性暫時未涉及。

redisson已經有對redlock算法封裝，接下來對其用法進行簡單介紹
添加POM依賴：

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson</artifactId>
	<version>3.3.2</version>
</dependency>

首先，我們來看一下redission封裝的redlock算法實現的分佈式鎖用法，非常簡單，跟重入鎖（ReentrantLock）有點類似：

唯一ID
實現分佈式鎖的一個非常重要的點就是set的value要具有唯一性，redisson的value是怎樣保證value的唯一性呢？答案是UUID+threadId。入口在redissonClient.getLock(“REDLOCK_KEY”)，源碼在Redisson.java和RedissonLock.java中：
獲取鎖
獲取鎖的代碼爲redLock.tryLock()或者redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS)，兩者的最終核心源碼都是下面這段代碼，只不過前者獲取鎖的默認租約時間（leaseTime）是LOCK_EXPIRATION_INTERVAL_SECONDS，即30s：

<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
      internalLockLeaseTime = unit.toMillis(leaseTime);
      return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
                 "if (redis.call('exists', KEYS[1]) == 0) then " + //如果鎖名稱不存在
                     "redis.call('hset', KEYS[1], ARGV[2], 1); " +//則向redis中添加一個key爲test_lock的set，並且向set中添加一個field爲線程id，值=1的鍵值對，表示此線程的重入次數爲1
                     "redis.call('pexpire', KEYS[1], ARGV[1]); " +//設置set的過期時間，防止當前服務器出問題後導致死鎖，return nil; end;返回nil 結束
                     "return nil; " +
                 "end; " +
                 "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +//如果鎖是存在的，檢測是否是當前線程持有鎖，如果是當前線程持有鎖
                     "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +//則將該線程重入的次數++
                     "redis.call('pexpire', KEYS[1], ARGV[1]); " +//並且重新設置該鎖的有效時間
                     "return nil; " + //返回nil，結束
                 "end; " +
                 "return redis.call('pttl', KEYS[1]);", //鎖存在, 但不是當前線程加的鎖，則返回鎖的過期時間
         Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
    }

釋放鎖
釋放鎖的代碼爲redLock.unlock()，核心源碼如下：

@Override
public void unlock() {
    Boolean opStatus = commandExecutor.evalWrite(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
                    "if (redis.call('exists', KEYS[1]) == 0) then " +//如果鎖已經不存在(可能是因爲過期導致不存在，也可能是因爲已經解鎖)
                        "redis.call('publish', KEYS[2], ARGV[1]); " +//則發佈鎖解除的消息
                        "return 1; " + //返回1結束
                    "end;" +
                    "if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " + //如果鎖存在，但是若果當前線程不是加鎖的線
                        "return nil;" + //則直接返回nil 結束
                    "end; " +
                    "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " + //如果是鎖是當前線程所添加，定義變量counter，表示當前線程的重入次數-1,即直接將重入次數-1
                    "if (counter > 0) then " + //如果重入次數大於0，表示該線程還有其他任務需要執行
                        "redis.call('pexpire', KEYS[1], ARGV[2]); " + //則重新設置該鎖的有效時間
                        "return 0; " + //返回0結束
                    "else " +
                        "redis.call('del', KEYS[1]); " + //否則表示該線程執行結束，刪除該鎖
                        "redis.call('publish', KEYS[2], ARGV[1]); " + //並且發佈該鎖解除的消息
                        "return 1; "+ //返回1結束
                    "end; " +
                    "return nil;", //其他情況返回nil並結束
                    Arrays.<Object>asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(Thread.currentThread().getId()));
    if (opStatus == null) {
        throw new IllegalMonitorStateException("attempt to unlock lock, not locked by current thread by node id: "
                + id + " thread-id: " + Thread.currentThread().getId());
    }
    if (opStatus) {
        cancelExpirationRenewal();
    }
}

RedLock 這麼牛逼算法，還是不完善的，使用 DDIA 作者提出的問題分析下:

案例1

ClientA 獲取鎖，發生了 GC，超過超時時間，Redis 釋放鎖
ClientB 獲取到鎖，此時 ClientA 喚醒，兩個客戶端都獲取到鎖
ClientB 執行了 Read-Write-Update 模型之後 ClientA 再次覆蓋了 ClientB 的數據，造成了數據錯誤

案例2

clientA 獲取到 A，B，C 三個節點，由於網絡故障，無法訪問 D，E 節點
由於 C 節點時鐘向前偏移，導致鎖過期
clientB 獲取到 C，D，E，由於網絡故障，無法訪問 A，B 節點
在此時，clientA 和 clientB 都獲取到了鎖

保險起見，必須由數據庫進行兜底。

redis — Redis分佈式鎖之Redlock（五）

1、引言

2、Redlock算法

3、Redisson

【面試準備】又一次失敗的面試經歷，題目離譜～資深軟件測試工程師

dotnet 8 版本與銀河麒麟V10和UOS系統的 glibc 兼容性

JVM — JAVA堆中對象的創建（二）

redis — Redis分佈式鎖之Redlock（五）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結