基於Redis實現分佈式鎖以前，這些坑你必定得知道

時間 2020-03-20

標籤基於 redis 實現分佈式以前這些必定知道欄目 Redis 简体版

原文原文鏈接

做者簡介java

陳寒立，一個不誤正業的程序員。前後在物流金融組、物流末端業務組和壓力平衡組打過雜，技術棧從Python玩到了Java，依然沒學會好好寫業務代碼，夢想着用抽象的模型拯救業務於水火之中。linux

開頭

基於Redis的分佈式鎖對你們來講並不陌生，但是你的分佈式鎖有失敗的時候嗎？在失敗的時候可曾懷疑過你在用的分佈式鎖真的靠譜嗎？如下是結合本身的踩坑經驗總結的一些經驗之談。git

你真的須要分佈式鎖嗎?

用到分佈式鎖說明遇到了多個進程共同訪問同一個資源的問題，通常是在兩個場景下會防止對同一個資源的重複訪問：程序員

提升效率。好比多個節點計算同一批任務，若是某個任務已經有節點在計算了，那其餘節點就不用重複計算了，以避免浪費計算資源。不太重複計算也沒事，不會形成其餘更大的損失。也就是容許偶爾的失敗。
保證正確性。這種狀況對鎖的要求就很高了，若是重複計算，會對正確性形成影響。這種不容許失敗。

引入分佈式鎖勢必要引入一個第三方的基礎設施，好比MySQL，Redis，Zookeeper等，這些實現分佈式鎖的基礎設施出問題了，也會影響業務，因此在使用分佈式鎖前能夠考慮下是否能夠不用加鎖的方式實現？不過這個不在本文的討論範圍內，本文假設加鎖的需求是合理的，而且偏向於上面的第二種狀況，爲何是偏向？由於不存在100%靠譜的分佈式鎖，看完下面的內容就明白了。github

從一個簡單的分佈式鎖實現提及

分佈式鎖的Redis實現很常見，本身實現和使用第三方庫都很簡單，至少看上去是這樣的，這裏就介紹一個最簡單靠譜的Redis實現。redis

最簡單的實現

實現很經典了，這裏只提兩個要點？算法

加鎖和解鎖的鎖必須是同一個，常見的解決方案是給每一個鎖一個鑰匙（惟一ID），加鎖時生成，解鎖時判斷。
不能讓一個資源永久加鎖。常見的解決方案是給一個鎖的過時時間。固然了還有其餘方案，後面再說。

一個可複製粘貼的實現方式以下：c#

加鎖api

public static boolean tryLock(String key, String uniqueId, int seconds) {
    return "OK".equals(jedis.set(key, uniqueId, "NX", "EX", seconds));
}
複製代碼

這裏實際上是調用了 SET key value PX milliseoncds NX，不明白這個命令的參考下SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]服務器

解鎖

public static boolean releaseLock(String key, String uniqueId) {
    String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "return redis.call('del', KEYS[1]) else return 0 end";
    return jedis.eval(
        luaScript, 
        Collections.singletonList(key), 
        Collections.singletonList(uniqueId)
    ).equals(1L);
}
複製代碼

這段實現的精髓在那個簡單的lua腳本上，先判斷惟一ID是否相等再操做。

靠譜嗎?

這樣的實現有什麼問題呢？

單點問題。上面的實現只要一個master節點就能搞定，這裏的單點指的是單master，就算是個集羣，若是加鎖成功後，鎖從master複製到slave的時候掛了，也是會出現同一資源被多個client加鎖的。
執行時間超過了鎖的過時時間。上面寫到爲了避免出現一直上鎖的狀況，加了一個兜底的過時時間，時間到了鎖自動釋放，可是，若是在這期間任務並無作完怎麼辦？因爲GC或者網絡延遲致使的任務時間變長，很難保證任務必定能在鎖的過時時間內完成。

如何解決這兩個問題呢？試試看更復雜的實現吧。

Redlock算法

對於第一個單點問題，順着redis的思路，接下來想到的確定是Redlock了。Redlock爲了解決單機的問題，須要多個（大於2）redis的master節點，多個master節點互相獨立，沒有數據同步。

Redlock的實現以下：

獲取當前時間。
依次獲取N個節點的鎖。 每一個節點加鎖的實現方式同上。這裏有個細節，就是每次獲取鎖的時候的過時時間都不一樣，須要減去以前獲取鎖的操做的耗時，

好比傳入的鎖的過時時間爲500ms，
獲取第一個節點的鎖花了1ms，那麼第一個節點的鎖的過時時間就是499ms，
獲取第二個節點的鎖花了2ms，那麼第二個節點的鎖的過時時間就是497ms
若是鎖的過時時間小於等於0了，說明整個獲取鎖的操做超時了，整個操做失敗

判斷是否獲取鎖成功。 若是client在上述步驟中獲取到了(N/2 + 1)個節點鎖，而且每一個鎖的過時時間都是大於0的，則獲取鎖成功，不然失敗。失敗時釋放鎖。
釋放鎖。 對全部節點發送釋放鎖的指令，每一個節點的實現邏輯和上面的簡單實現同樣。爲何要對全部節點操做？由於分佈式場景下從一個節點獲取鎖失敗不表明在那個節點上加速失敗，可能實際上加鎖已經成功了，可是返回時由於網絡抖動超時了。

以上就是你們常見的redlock實現的描述了，一眼看上去就是簡單版本的多master版本，若是真是這樣就太簡單了，接下來分析下這個算法在各個場景下是怎樣被玩壞的。

分佈式鎖的坑

高併發場景下的問題

如下問題不是說在併發不高的場景下不容易出現，只是在高併發場景下出現的機率更高些而已。 性能問題。 性能問題來自於兩個方面。

獲取鎖的時間上。若是redlock運用在高併發的場景下，存在N個master節點，一個一個去請求，耗時會比較長，從而影響性能。這個好解決。經過上面描述不難發現，從多個節點獲取鎖的操做並非一個同步操做，能夠是異步操做，這樣能夠多個節點同時獲取。即便是並行處理的，仍是得預估好獲取鎖的時間，保證鎖的TTL > 獲取鎖的時間+任務處理時間。
被加鎖的資源太大。加鎖的方案自己就是會爲了正確性而犧牲併發的，犧牲和資源大小成正比。這個時候能夠考慮對資源作拆分，拆分的方式有兩種：
從業務上將鎖住的資源拆分紅多段，每段分開加鎖。好比，我要對一個商戶作若干個操做，操做前要鎖住這個商戶，這時我能夠將若干個操做拆成多個獨立的步驟分開加鎖，提升併發。
用分桶的思想，將一個資源拆分紅多個桶，一個加鎖失敗當即嘗試下一個。好比批量任務處理的場景，要處理200w個商戶的任務，爲了提升處理速度，用多個線程，每一個線程取100個商戶處理，就得給這100個商戶加鎖，若是不加處理，很難保證同一時刻兩個線程加鎖的商戶沒有重疊，這時能夠按一個維度，好比某個標籤，對商戶進行分桶，而後一個任務處理一個分桶，處理完這個分桶再處理下一個分桶，減小競爭。

重試的問題。 不管是簡單實現仍是redlock實現，都會有重試的邏輯。若是直接按上面的算法實現，是會存在多個client幾乎在同一時刻獲取同一個鎖，而後每一個client都鎖住了部分節點，可是沒有一個client獲取大多數節點的狀況。解決的方案也很常見，在重試的時候讓多個節點錯開，錯開的方式就是在重試時間中加一個隨機時間。這樣並不能根治這個問題，可是能夠有效緩解問題，親試有效。

節點宕機

對於單master節點且沒有作持久化的場景，宕機就掛了，這個就必須在實現上支持重複操做，本身作好冪等。

對於多master的場景，好比redlock，咱們來看這樣一個場景：

假設有5個redis的節點：A、B、C、D、E，沒有作持久化。
client1從A、B、C 3個節點獲取鎖成功，那麼client1獲取鎖成功。
節點C掛了。
client2從C、D、E獲取鎖成功，client2也獲取鎖成功，那麼在同一時刻client1和client2同時獲取鎖，redlock被玩壞了。

怎麼解決呢？最容易想到的方案是打開持久化。持久化能夠作到持久化每一條redis命令，但這對性能影響會很大，通常不會採用，若是不採用這種方式，在節點掛的時候確定會損失小部分的數據，可能咱們的鎖就在其中。另外一個方案是延遲啓動。就是一個節點掛了修復後，不當即加入，而是等待一段時間再加入，等待時間要大於宕機那一刻全部鎖的最大TTL。但這個方案依然不能解決問題，若是在上述步驟3中B和C都掛了呢，那麼只剩A、D、E三個節點，從D和E獲取鎖成功就能夠了，仍是會出問題。那麼只能增長master節點的總量，緩解這個問題了。增長master節點會提升穩定性，可是也增長了成本，須要在二者之間權衡。

任務執行時間超過鎖的TTL

以前產線上出現過由於網絡延遲致使任務的執行時間遠超預期，鎖過時，被多個線程執行的狀況。這個問題是全部分佈式鎖都要面臨的問題，包括基於zookeeper和DB實現的分佈式鎖，這是鎖過時了和client不知道鎖過時了之間的矛盾。在加鎖的時候，咱們通常都會給一個鎖的TTL，這是爲了防止加鎖後client宕機，鎖沒法被釋放的問題。可是全部這種姿式的用法都會面臨同一個問題，就是沒發保證client的執行時間必定小於鎖的TTL。雖然大多數程序員都會樂觀的認爲這種狀況不可能發生，我也曾經這麼認爲，直到被現實一次又一次的打臉。

Martin Kleppmann也質疑過這一點，這裏直接用他的圖：

Client1獲取到鎖
Client1開始任務，而後發生了STW的GC，時間超過了鎖的過時時間
Client2 獲取到鎖，開始了任務
Client1的GC結束，繼續任務，這個時候Client1和Client2都認爲本身獲取了鎖，都會處理任務，從而發生錯誤。

Martin Kleppmann舉的是GC的例子，我碰到的是網絡延遲的狀況。無論是哪一種狀況，不能否認的是這種狀況沒法避免，一旦出現很容易懵逼。

如何解決呢？一種解決方案是不設置TTL，而是在獲取鎖成功後，給鎖加一個watchdog，watchdog會起一個定時任務，在鎖沒有被釋放且快要過時的時候會續期。這樣說有些抽象，下面結合redisson源碼說下：

public class RedissonLock extends RedissonExpirable implements RLock {
    ...
    @Override
    public void lock() {
        try {
            lockInterruptibly();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    @Override
    public void lock(long leaseTime, TimeUnit unit) {
        try {
            lockInterruptibly(leaseTime, unit);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
    ...
 }

複製代碼

redisson經常使用的加鎖api是上面兩個，一個是不傳入TTL，這時是redisson本身維護，會主動續期；另一種是本身傳入TTL，這種redisson就不會幫咱們自動續期了，或者本身將leaseTime的值傳成-1，可是不建議這種方式，既然已經有現成的API了，何須還要用這種奇怪的寫法呢。接下來分析下不傳參的方法的加鎖邏輯：

public class RedissonLock extends RedissonExpirable implements RLock {

    ...
        
    public static final long LOCK_EXPIRATION_INTERVAL_SECONDS = 30;
    protected long internalLockLeaseTime = TimeUnit.SECONDS.toMillis(LOCK_EXPIRATION_INTERVAL_SECONDS);

        
    @Override
    public void lock() {
        try {
            lockInterruptibly();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
        
    @Override
    public void lockInterruptibly() throws InterruptedException {
        lockInterruptibly(-1, null);
    }
    
    @Override
    public void lockInterruptibly(long leaseTime, TimeUnit unit) throws InterruptedException {
        long threadId = Thread.currentThread().getId();
        Long ttl = tryAcquire(leaseTime, unit, threadId);
        // lock acquired
        if (ttl == null) {
            return;
        }

        RFuture<RedissonLockEntry> future = subscribe(threadId);
        commandExecutor.syncSubscription(future);

        try {
            while (true) {
                ttl = tryAcquire(leaseTime, unit, threadId);
                // lock acquired
                if (ttl == null) {
                    break;
                }

                // waiting for message
                if (ttl >= 0) {
                    getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } else {
                    getEntry(threadId).getLatch().acquire();
                }
            }
        } finally {
            unsubscribe(future, threadId);
        }
// get(lockAsync(leaseTime, unit));
    }

    private Long tryAcquire(long leaseTime, TimeUnit unit, long threadId) {
        return get(tryAcquireAsync(leaseTime, unit, threadId));
    }

    private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, final long threadId) {
        if (leaseTime != -1) {
            return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
        }
        RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(LOCK_EXPIRATION_INTERVAL_SECONDS, TimeUnit.SECONDS, threadId, RedisCommands.EVAL_LONG);
        ttlRemainingFuture.addListener(new FutureListener<Long>() {
            @Override
            public void operationComplete(Future<Long> future) throws Exception {
                if (!future.isSuccess()) {
                    return;
                }

                Long ttlRemaining = future.getNow();
                // lock acquired
                if (ttlRemaining == null) {
                    scheduleExpirationRenewal(threadId);
                }
            }
        });
        return ttlRemainingFuture;
    }

    private void scheduleExpirationRenewal(final long threadId) {
        if (expirationRenewalMap.containsKey(getEntryName())) {
            return;
        }

        Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
            @Override
            public void run(Timeout timeout) throws Exception {
                
                RFuture<Boolean> future = commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
                        "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                            "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                            "return 1; " +
                        "end; " +
                        "return 0;",
                          Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
                
                future.addListener(new FutureListener<Boolean>() {
                    @Override
                    public void operationComplete(Future<Boolean> future) throws Exception {
                        expirationRenewalMap.remove(getEntryName());
                        if (!future.isSuccess()) {
                            log.error("Can't update lock " + getName() + " expiration", future.cause());
                            return;
                        }
                        
                        if (future.getNow()) {
                            // reschedule itself
                            scheduleExpirationRenewal(threadId);
                        }
                    }
                });
            }
        }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);

        if (expirationRenewalMap.putIfAbsent(getEntryName(), task) != null) {
            task.cancel();
        }
    }

    
    ...
}

複製代碼

能夠看到，最後加鎖的邏輯會進入到org.redisson.RedissonLock#tryAcquireAsync中，在獲取鎖成功後，會進入scheduleExpirationRenewal，這裏面初始化了一個定時器，dely的時間是internalLockLeaseTime / 3。在redisson中，internalLockLeaseTime是30s，也就是每隔10s續期一次，每次30s。若是是基於zookeeper實現的分佈式鎖，能夠利用zookeeper檢查節點是否存活，從而實現續期，zookeeper分佈式鎖沒用過，不詳細說。

不過這種作法也沒法百分百作到同一時刻只有一個client獲取到鎖，若是續期失敗，好比發生了Martin Kleppmann所說的STW的GC，或者client和redis集羣失聯了，只要續期失敗，就會形成同一時刻有多個client得到鎖了。在個人場景下，我將鎖的粒度拆小了，redisson的續期機制已經夠用了。若是要作得更嚴格，得加一個續期失敗終止任務的邏輯。這種作法在之前Python的代碼中實現過，Java尚未碰到這麼嚴格的狀況。

這裏也提下Martin Kleppmann的解決方案，我本身以爲這個方案並不靠譜，緣由後面會提到。他的方案是讓加鎖的資源本身維護一套保證不會因加鎖失敗而致使多個client在同一時刻訪問同一個資源的狀況。

在客戶端獲取鎖的同時，也獲取到一個資源的token，這個token是單調遞增的，每次在寫資源時，都檢查當前的token是不是較老的token，若是是就不讓寫。對於上面的場景，Client1獲取鎖的同時分配一個33的token，Client2獲取鎖的時候分配一個34的token，在client1 GC期間，Client2已經寫了資源，這時最大的token就是34了，client1 從GC中回來，再帶着33的token寫資源時，會由於token過時被拒絕。這種作法須要資源那一邊提供一個token生成器。對於這種fencing的方案，我有幾點問題：

沒法保證事務。示意圖中畫的只有34訪問了storage，可是在實際場景中，可能出如今一個任務內屢次訪問storage的狀況，並且必須是原子的。若是client1帶着33token在GC前訪問過一次storage，而後發生了GC。client2獲取到鎖，帶着34的token也訪問了storage，這時兩個client寫入的數據是否還能保證數據正確？若是不能，那麼這種方案就有缺陷，除非storage本身有其餘機制能夠保證，好比事務機制；若是能，那麼這裏的token就是多餘的，fencing的方案就是畫蛇添足。
高併發場景不實用。由於每次只有最大的token能寫，這樣storage的訪問就是線性的，在高併發場景下，這種方式會極大的限制吞吐量，而分佈式鎖也大可能是在這種場景下用的，很矛盾的設計。
這是全部分佈式鎖的問題。這個方案是一個通用的方案，能夠和Redlock用，也能夠和其餘的lock用。因此我理解僅僅是一個和Redlock無關的解決方案。

系統時鐘漂移

這個問題只是考慮過，但在實際項目中並無碰到過，由於理論上是可能出現的，這裏也說下。 redis的過時時間是依賴系統時鐘的，若是時鐘漂移過大時會影響到過時時間的計算。

爲何系統時鐘會存在漂移呢？先簡單說下系統時間，linux提供了兩個系統時間：clock realtime和clock monotonic。clock realtime也就是xtime/wall time，這個時間時能夠被用戶改變的，被NTP改變，gettimeofday拿的就是這個時間，redis的過時計算用的也是這個時間。 clock monotonic ，直譯過來時單調時間，不會被用戶改變，可是會被NTP改變。

最理想的狀況時，全部系統的時鐘都時時刻刻和NTP服務器保持同步，但這顯然時不可能的。致使系統時鐘漂移的緣由有兩個：

系統的時鐘和NTP服務器不一樣步。這個目前沒有特別好的解決方案，只能相信運維同窗了。
clock realtime被人爲修改。在實現分佈式鎖時，不要使用clock realtime。不過很惋惜，redis使用的就是這個時間，我看了下Redis 5.0源碼，使用的仍是clock realtime。Antirez說過改爲clock monotonic的，不過大佬尚未改。也就是說，人爲修改redis服務器的時間，就能讓redis出問題了。