問題描述

隨著業(yè)務(wù)發(fā)展的需要，原單體單機(jī)部署的系統(tǒng)被演化成分布式集群系統(tǒng)后，由于分布式系統(tǒng)多線程、多進(jìn)程并且分布在不同機(jī)器上，這將使原單機(jī)部署情況下的并發(fā)控制鎖策略失效，單純的Java API并不能提供分布式鎖的能力。為了解決這個(gè)問題就需要一種跨JVM的互斥機(jī)制來控制共享資源的訪問，這就是分布式鎖要解決的問題！

分布式鎖主流的實(shí)現(xiàn)方案：

1. 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖

2. 基于緩存（Redis等）

3. 基于Zookeeper

每一種分布式鎖解決方案都有各自的優(yōu)缺點(diǎn)：

1. 性能：redis最高

2. 可靠性：zookeeper最高

這里，我們就基于redis實(shí)現(xiàn)分布式鎖。

解決方案

使用redis實(shí)現(xiàn)分布式鎖

redis:命令

# set sku:1:info “OK” NX PX 10000

EX second ：設(shè)置鍵的過期時(shí)間為 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。

PX millisecond ：設(shè)置鍵的過期時(shí)間為 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。

NX ：只在鍵不存在時(shí)，才對鍵進(jìn)行設(shè)置操作。 SET key value NX 效果等同于 SETNX key value 。

XX ：只在鍵已經(jīng)存在時(shí)，才對鍵進(jìn)行設(shè)置操作。

1. 多個(gè)客戶端同時(shí)獲取鎖（setnx）

2. 獲取成功，執(zhí)行業(yè)務(wù)邏輯{從db獲取數(shù)據(jù)，放入緩存}，執(zhí)行完成釋放鎖（del）

3. 其他客戶端等待重試

編寫代碼

Redis:

set num 0

@GetMapping("testLock")
public void testLock(){
    //1獲取鎖，setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2獲取鎖成功、查詢num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判斷num為空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就轉(zhuǎn)成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4釋放鎖，del
        redisTemplate.delete("lock");
    }else{
        //3獲取鎖失敗、每隔0.1秒再獲取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

重啟，服務(wù)集群，通過網(wǎng)關(guān)壓力測試：

ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock

查看redis中num的值：

基本實(shí)現(xiàn)。

問題：setnx剛好獲取到鎖，業(yè)務(wù)邏輯出現(xiàn)異常，導(dǎo)致鎖無法釋放

解決：設(shè)置過期時(shí)間，自動釋放鎖。

優(yōu)化之設(shè)置鎖的過期時(shí)間

設(shè)置過期時(shí)間有兩種方式：

1. 首先想到通過expire設(shè)置過期時(shí)間（缺乏原子性：如果在setnx和expire之間出現(xiàn)異常，鎖也無法釋放）

2. 在set時(shí)指定過期時(shí)間（推薦）

設(shè)置過期時(shí)間：

壓力測試肯定也沒有問題。自行測試

問題：可能會釋放其他服務(wù)器的鎖。

場景：如果業(yè)務(wù)邏輯的執(zhí)行時(shí)間是7s。執(zhí)行流程如下

index1業(yè)務(wù)邏輯沒執(zhí)行完，3秒后鎖被自動釋放。index2獲取到鎖，執(zhí)行業(yè)務(wù)邏輯，3秒后鎖被自動釋放。index3獲取到鎖，執(zhí)行業(yè)務(wù)邏輯index1業(yè)務(wù)邏輯執(zhí)行完成，開始調(diào)用del釋放鎖，這時(shí)釋放的是index3的鎖，導(dǎo)致index3的業(yè)務(wù)只執(zhí)行1s就被別人釋放。最終等于沒鎖的情況。

解決：setnx獲取鎖時(shí)，設(shè)置一個(gè)指定的唯一值（例如：uuid）；釋放前獲取這個(gè)值，判斷是否自己的鎖

優(yōu)化之UUID防誤刪

到此這篇關(guān)于redis深入淺出分布式鎖實(shí)現(xiàn)上篇的文章就介紹到這了,更多相關(guān)redis分布式鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！