如何理解Redis分布式鎖

本篇內容主要講解“如何理解Redis分布式鎖”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解Redis分布式鎖”吧!

你真的需要分布式鎖嗎?

用到分布式鎖說明遇到了多個進程共同訪問同一個資源的問題，

一般是在兩個場景下會防止對同一個資源的重復訪問：

• 提高效率。比如多個節點計算同一批任務，如果某個任務已經有節點在計算了，那其他節點就不用重復計算了，以免浪費計算資源。不過重復計算也沒事，不會造成其他更大的損失。也就是允許偶爾的失敗。

• 保證正確性。這種情況對鎖的要求就很高了，如果重復計算，會對正確性造成影響。這種不允許失敗。

引入分布式鎖勢必要引入一個第三方的基礎設施，比如MySQL，Redis，Zookeeper等，這些實現分布式鎖的基礎設施出問題了，也會影響業務，所以在使用分布式鎖前可以考慮下是否可以不用加鎖的方式實現？

不過這個不在本文的討論范圍內，本文假設加鎖的需求是合理的，并且偏向于上面的第二種情況，為什么是偏向？因為不存在100%靠譜的分布式鎖，看完下面的內容就明白了。

從一個簡單的分布式鎖實現說起

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

最簡單的實現

實現很經典了，這里只提兩個要點？

• 加鎖和解鎖的鎖必須是同一個，常見的解決方案是給每個鎖一個鑰匙（唯一ID），加鎖時生成，解鎖時判斷。

• 不能讓一個資源永久加鎖。常見的解決方案是給一個鎖的過期時間。當然了還有其他方案，后面再說。

一個可復制粘貼的實現方式如下：

加鎖

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]：https://redis.io/commands/set

解鎖

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的實現如下：

1）獲取當前時間。

2）依次獲取N個節點的鎖。每個節點加鎖的實現方式同上。這里有個細節，就是每次獲取鎖的時候的過期時間都不同，需要減去之前獲取鎖的操作的耗時：

• 比如傳入的鎖的過期時間為500ms；

• 獲取第一個節點的鎖花了1ms，那么第一個節點的鎖的過期時間就是499ms；

• 獲取第二個節點的鎖花了2ms，那么第二個節點的鎖的過期時間就是497ms；

• 如果鎖的過期時間小于等于0了，說明整個獲取鎖的操作超時了，整個操作失敗。

3）判斷是否獲取鎖成功。如果client在上述步驟中獲取到了(N/2 + 1)個節點鎖，并且每個鎖的過期時間都是大于0的，則獲取鎖成功，否則失敗。失敗時釋放鎖。

4）釋放鎖。對所有節點發送釋放鎖的指令，每個節點的實現邏輯和上面的簡單實現一樣。為什么要對所有節點操作？因為分布式場景下從一個節點獲取鎖失敗不代表在那個節點上加速失敗，可能實際上加鎖已經成功了，但是返回時因為網絡抖動超時了。

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

分布式鎖的坑

高并發場景下的問題

以下問題不是說在并發不高的場景下不容易出現，只是在高并發場景下出現的概率更高些而已。

性能問題。 性能問題來自于兩個方面。

1）獲取鎖的時間上。如果redlock運用在高并發的場景下，存在N個master節點，一個一個去請求，耗時會比較長，從而影響性能。這個好解決。通過上面描述不難發現，從多個節點獲取鎖的操作并不是一個同步操作，可以是異步操作，這樣可以多個節點同時獲取。即使是并行處理的，還是得預估好獲取鎖的時間，保證鎖的TTL > 獲取鎖的時間+任務處理時間。

2）被加鎖的資源太大。加鎖的方案本身就是會為了正確性而犧牲并發的，犧牲和資源大小成正比。這個時候可以考慮對資源做拆分，拆分的方式有兩種：

• 從業務上將鎖住的資源拆分成多段，每段分開加鎖。比如，我要對一個商戶做若干個操作，操作前要鎖住這個商戶，這時我可以將若干個操作拆成多個獨立的步驟分開加鎖，提高并發。

• 用分桶的思想，將一個資源拆分成多個桶，一個加鎖失敗立即嘗試下一個。比如批量任務處理的場景，要處理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出問題了。

總結

本文從一個簡單的基于redis的分布式鎖出發，到更復雜的Redlock的實現，介紹了在使用分布式鎖的過程中才踩過的一些坑以及解決方案。

到此，相信大家對“如何理解Redis分布式鎖”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！