Redis分布式鎖有什么用

這篇文章給大家分享的是有關Redis分布式鎖有什么用的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1. 什么是分布式鎖

分布式與單機情況下最大的不同在于其不是多線程而是多進程，而數據只有一份（或有限制），也就是說單機的共享內存已解決不了一致性寫問題，此時需要利用鎖的技術控制某一時刻修改數據的進程數。

當在分布式模型下，分布式鎖還是可以將標記存在內存，只是該內存不是某個進程分配的內存而是公共內存（Redis、Memcache）。至于利用數據庫、文件等做鎖與單機的實現是一樣的，只要保證標記能互斥就行。

2. 分布式鎖該具備的特性

• 最好是可重入鎖（避免死鎖）

• 最好是一把阻塞鎖（根據業務需求決定）

• 最好是一把公平鎖（根據業務需求決定）

• 有高可用、高性能的獲取鎖和釋放鎖功能

3. 基于數據庫做分布式鎖

• 基于樂觀鎖，CAS，但如果是insert的情況采用主鍵沖突防重，在大并發情況下有可能會造成鎖表現象

• 基于悲觀鎖，也就是排他鎖，會有各種各樣的問題（操作數據庫需要一定的開銷，使用數據庫的行級鎖并不一定靠譜，性能不靠譜）

如果按分布式該具備的特性來逐條匹配，特別是高可用（存在單點）、高性能是硬傷

4. 基于Redis做分布式鎖

一般都使用 setnx(set if not exists) 指令，只允許被一個客戶端占有，先來先得， 用完后再通過 del 指令釋放。

如果中間邏輯執行時發生異常，可能會導致 del 指令沒有被執行，這樣就會陷入死鎖，怎么破？

對，給鎖加個過期時間（即使出現異常也可以保證幾秒之后鎖會自動釋放）！

但setnx 和 expire 之間redis服務器突然掛掉，怎么破？

其實該問題的根源就在于 setnx 和 expire 是兩條指令而不是原子指令。為了解決這個疑難，Redis 開源社區涌現了一堆分布式鎖的 解決方案。為了治理這個亂象，Redis 2.8 版本中加入了 set 指令的擴展參數，使得 setnx 和 expire 指令可以一起執行，徹底解決了分布式鎖的亂象。

總之，setnx 和 expire 組合就是分布式鎖的奧義所在。

4.1 超時問題

如果在加鎖和釋放鎖之間的邏輯執行的太長，超出了超時限制，怎么破？

也就是說第一個線程持有的鎖過期了但臨界區的邏輯還沒有執行完，這個時候第二個線程就提前重新持有了這把鎖，導致每個請求執行臨界區代碼時不能嚴格的串行執行。

Redis 的分布式鎖不能解決超時問題，建議分布式鎖不要用于較長時間的任務。

稍微安全一點的方案是為 set 指令的 value 參數設置為一個隨機數，釋放鎖時先匹配隨機數是否一致，一致的話再刪除 key，這是可以確保當前線程占有的鎖不會被其它線程釋放，但是并不能解決鎖被redis服務器自動釋放的。

int tag = random.nextint()//隨機數
boolean nx=true;
int ex=5;
if(redis.set(key, tag, nx, ex)){
    do_something()
    redis.delifequals(key, tag)//不存在這樣的命令
}

但是匹配 value 和刪除 key 不是一個原子操作，怎么破？

需要使用 Lua 腳本來處理了，因為 Lua 腳本可以保證連續多個指令的原子性執行。

#delifequals.lua文件，下面的是社區熱門代碼
if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end
//java調用
public void delifequals(){
    String script = readScript("delifequals.lua");
    int tag = 5;
    String key = "key";
    Object eval = jedis.eval(script, Lists.newArrayList(key), Lists.newArrayList(tag));
    System.out.println(eval);
}

4.2 可重入鎖

redis有類似Java 語言里有個 ReentrantLock 就是可重入鎖嗎？

要支持可重入，需要對jedis 的 set 方法進行包裝，思路是：使用 Threadlocal 存儲當前持有鎖的計數。可重入鎖加重了客戶端的復雜性，精確一點還需要考慮內存鎖計數的過期時間，代碼復雜度將會繼續升高。

public class JedisWithReentrantLock {
    private Jedis jedis;
    /**
     * 當前線程的鎖及計數
     */
    private ThreadLocal<Map<String, Integer>> lockers = new ThreadLocal<>();
    public JedisWithReentrantLock(Jedis jedis) {
        this.jedis = jedis;
    }
    private boolean set(String key) {
        return jedis.set(key, "", "nx", "ex", 5L) != null;
    }
    private void del(String key) {
        jedis.del(key);
    }
    private Map<String, Integer> getLockers() {
        Map<String, Integer> refs = lockers.get();
        if (refs != null) {
            return refs;
        }
        lockers.set(Maps.newHashMap());
        return lockers.get();
    }
 
    public boolean lock(String key) {
        Map<String, Integer> refs = getLockers();
        Integer refCount = refs.get(key);
        if (refCount != null) {
            refs.put(key, refCount + 1);
            return true;
        }
        if (!this.set(key)) {
            return false;
        }
        refs.put(key, 1);
        return true;
    }
 
    public boolean unlock(String key) {
        Map<String, Integer> refs = getLockers();
        Integer refCount = refs.get(key);
        if (refCount == null) {
            return false;
        }
        refCount -= 1;
        if (refCount > 0) {
            refs.put(key, refCount);
        } else {
            refs.remove(key);
            this.del(key);
        }
        return true;
    }
}
    @Test
    public void runJedisWithReentrantLock() {
        JedisWithReentrantLock redis = new JedisWithReentrantLock(jedis);
        System.out.println(redis.lock("alex"));
        System.out.println(redis.lock("alex"));
        System.out.println(redis.unlock("alex"));
        System.out.println(redis.unlock("alex"));
    }

4.3 集群環境的缺陷

在集群環境下，這種方式是有缺陷的（數據不一致的情況）。比如在 Sentinel 集群中，主節點掛掉時（原先第一個客戶端在主節點中申請成功了一把鎖），從節點A 會取而代之并晉升為主（但是這把鎖還沒有來得及同步），雖然客戶端上卻并沒有明顯感知，但是這時另一個客戶端過來請求 從節點A 可以成功加鎖，這樣就會導致系統中同樣一把鎖被兩個客戶端同時持有。

主從發生故障轉移，一般持續時間極短，數據不一致的情況基本上都是小概率事件。

4.4 Redlock

上面的集群同步問題導致的缺陷，難道就沒有解決方案嗎？

為此Antirez 發明了 Redlock 算法，它的流程比較復雜，不過已經有了很多開源的實現。

原理

使用 Redlock，需要提供多個 Redis 實例，這些實例之前相互獨立沒有主從關系。同很多分布式算法一樣，redlock 也使用少數服從多數。

加鎖時，它會向過半節點發送 set(key, value, nx, ex) 指令，只要過半節點 set 成功，那就認為加鎖成功。釋放鎖時，需要向所有節點發送 del 指令。缺陷：因為 Redlock 需要向多個節點進行讀寫，意味著相比單實例 Redis 性能會下降一些。

注：Redlock算法還需要考慮出錯重試、時鐘漂移等很多細節問題

使用場景

如果你很在乎高可用性，希望掛了一臺 redis 完全不受影響，那就應該考慮 redlock。

感謝各位的閱讀！關于“Redis分布式鎖有什么用”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！