七種方案！探討Redis分佈式鎖的正確使用姿式

前言

平常開發中，秒殺下單、搶紅包等等業務場景，都須要用到分佈式鎖。而Redis很是適合做爲分佈式鎖使用。本文將分七個方案展開，跟你們探討Redis分佈式鎖的正確使用方式。若是有不正確的地方，歡迎你們指出哈，一塊兒學習一塊兒進步。git

公衆號：撿田螺的小男孩github

什麼是分佈式鎖redis
方案一：SETNX + EXPIRE算法
方案二：SETNX + value值是（系統時間+過時時間）安全
方案三：使用Lua腳本(包含SETNX + EXPIRE兩條指令)服務器
方案四：SET的擴展命令（SET EX PX NX）markdown
方案五：SET EX PX NX + 校驗惟一隨機值,再釋放鎖網絡
方案六: 開源框架:Redisson多線程
方案七：多機實現的分佈式鎖Redlock併發
github地址，感謝每顆star

github.com/whx123/Java…

什麼是分佈式鎖

分佈式鎖其實就是，控制分佈式系統不一樣進程共同訪問共享資源的一種鎖的實現。若是不一樣的系統或同一個系統的不一樣主機之間共享了某個臨界資源，每每須要互斥來防止彼此干擾，以保證一致性。

咱們先來看下，一把靠譜的分佈式鎖應該有哪些特徵：

互斥性: 任意時刻，只有一個客戶端能持有鎖。
鎖超時釋放：持有鎖超時，能夠釋放，防止沒必要要的資源浪費，也能夠防止死鎖。
可重入性:一個線程若是獲取了鎖以後,能夠再次對其請求加鎖。
高性能和高可用：加鎖和解鎖須要開銷儘量低，同時也要保證高可用，避免分佈式鎖失效。
安全性：鎖只能被持有的客戶端刪除，不能被其餘客戶端刪除

Redis分佈式鎖方案一：SETNX + EXPIRE

提到Redis的分佈式鎖，不少小夥伴立刻就會想到setnx+ expire命令。即先用setnx來搶鎖，若是搶到以後，再用expire給鎖設置一個過時時間，防止鎖忘記了釋放。

SETNX 是SET IF NOT EXISTS的簡寫.平常命令格式是SETNX key value，若是 key不存在，則SETNX成功返回1，若是這個key已經存在了，則返回0。

假設某電商網站的某商品作秒殺活動，key能夠設置爲key_resource_id,value設置任意值，僞代碼以下：

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加鎖
    expire（key_resource_id，100）; //設置過時時間
    try {
        do something  //業務請求
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}
複製代碼

可是這個方案中，setnx和expire兩個命令分開了，不是原子操做。若是執行完setnx加鎖，正要執行expire設置過時時間時，進程crash或者要重啓維護了，那麼這個鎖就「長生不老」了，別的線程永遠獲取不到鎖啦。

Redis分佈式鎖方案二：SETNX + value值是(系統時間+過時時間)

爲了解決方案一，發生異常鎖得不到釋放的場景，有小夥伴認爲，能夠把過時時間放到setnx的value值裏面。若是加鎖失敗，再拿出value值校驗一下便可。加鎖代碼以下：

long expires = System.currentTimeMillis() + expireTime; //系統時間+設置的過時時間
String expiresStr = String.valueOf(expires);

// 若是當前鎖不存在，返回加鎖成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 若是鎖已經存在，獲取鎖的過時時間
String currentValueStr = jedis.get(key_resource_id);

// 若是獲取到的過時時間，小於系統當前時間，表示已通過期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 鎖已過時，獲取上一個鎖的過時時間，並設置如今鎖的過時時間（不瞭解redis的getSet命令的小夥伴，能夠去官網看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考慮多線程併發的狀況，只有一個線程的設置值和當前值相同，它才能夠加鎖
         return true;
    }
}
        
//其餘狀況，均返回加鎖失敗
return false;
}
複製代碼

這個方案的優勢是，巧妙移除expire單獨設置過時時間的操做，把過時時間放到setnx的value值裏面來。解決了方案一發生異常，鎖得不到釋放的問題。可是這個方案還有別的缺點：

過時時間是客戶端本身生成的（System.currentTimeMillis()是當前系統的時間），必需要求分佈式環境下，每一個客戶端的時間必須同步。

若是鎖過時的時候，併發多個客戶端同時請求過來，都執行jedis.getSet()，最終只能有一個客戶端加鎖成功，可是該客戶端鎖的過時時間，可能被別的客戶端覆蓋

該鎖沒有保存持有者的惟一標識，可能被別的客戶端釋放/解鎖。

Redis分佈式鎖方案三：使用Lua腳本(包含SETNX + EXPIRE兩條指令)

實際上，咱們還可使用Lua腳原本保證原子性（包含setnx和expire兩條指令），lua腳本以下：

if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;
複製代碼

加鎖代碼以下：

String lua_scripts = "if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then" +
            " redis.call('expire',KEYS[1],ARGV[2]) return 1 else return 0 end";   
Object result = jedis.eval(lua_scripts, Collections.singletonList(key_resource_id), Collections.singletonList(values));
//判斷是否成功
return result.equals(1L);
複製代碼

這個方案仍是有缺點的哦，至於哪些缺點，你先思考一下。也能夠想下。跟方案二對比，哪一個更好？

Redis分佈式鎖方案方案四：SET的擴展命令（SET EX PX NX）

除了使用，使用Lua腳本，保證SETNX + EXPIRE兩條指令的原子性，咱們還能夠巧用Redis的SET指令擴展參數！（SET key value[EX seconds][PX milliseconds][NX|XX]），它也是原子性的！

SET key value[EX seconds][PX milliseconds][NX|XX]

NX :表示key不存在的時候，才能set成功，也即保證只有第一個客戶端請求才能得到鎖，而其餘客戶端請求只能等其釋放鎖，才能獲取。

EX seconds :設定key的過時時間，時間單位是秒。

PX milliseconds: 設定key的過時時間，單位爲毫秒

XX: 僅當key存在時設置值

僞代碼demo以下：

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加鎖
    try {
        do something  //業務處理
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}
複製代碼

可是呢，這個方案仍是可能存在問題：

問題一：鎖過時釋放了，業務還沒執行完。假設線程a獲取鎖成功，一直在執行臨界區的代碼。可是100s過去後，它還沒執行完。可是，這時候鎖已通過期了，此時線程b又請求過來。顯然線程b就能夠得到鎖成功，也開始執行臨界區的代碼。那麼問題就來了，臨界區的業務代碼都不是嚴格串行執行的啦。
問題二：鎖被別的線程誤刪。假設線程a執行完後，去釋放鎖。可是它不知道當前的鎖多是線程b持有的（線程a去釋放鎖時，有可能過時時間已經到了，此時線程b進來佔有了鎖）。那線程a就把線程b的鎖釋放掉了，可是線程b臨界區業務代碼可能都還沒執行完呢。

方案五：SET EX PX NX + 校驗惟一隨機值,再刪除

既然鎖可能被別的線程誤刪，那咱們給value值設置一個標記當前線程惟一的隨機數，在刪除的時候，校驗一下，不就OK了嘛。僞代碼以下：

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加鎖
    try {
        do something  //業務處理
    }catch(){
　　}
　　finally {
       //判斷是否是當前線程加的鎖,是才釋放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //釋放鎖
        }
    }
}
複製代碼

在這裏，判斷是否是當前線程加的鎖和釋放鎖不是一個原子操做。若是調用jedis.del()釋放鎖的時候，可能這把鎖已經不屬於當前客戶端，會解除他人加的鎖。

爲了更嚴謹，通常也是用lua腳本代替。lua腳本以下：

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;
複製代碼

Redis分佈式鎖方案六：Redisson框架

方案五仍是可能存在鎖過時釋放，業務沒執行完的問題。有些小夥伴認爲，稍微把鎖過時時間設置長一些就能夠啦。其實咱們設想一下，是否能夠給得到鎖的線程，開啓一個定時守護線程，每隔一段時間檢查鎖是否還存在，存在則對鎖的過時時間延長，防止鎖過時提早釋放。

當前開源框架Redisson解決了這個問題。咱們一塊兒來看下Redisson底層原理圖吧：

只要線程一加鎖成功，就會啓動一個watch dog看門狗，它是一個後臺線程，會每隔10秒檢查一下，若是線程1還持有鎖，那麼就會不斷的延長鎖key的生存時間。所以，Redisson就是使用Redisson解決了鎖過時釋放，業務沒執行完問題。

Redis分佈式鎖方案七：多機實現的分佈式鎖Redlock+Redisson

前面六種方案都只是基於單機版的討論，還不是很完美。其實Redis通常都是集羣部署的：

若是線程一在Redis的master節點上拿到了鎖，可是加鎖的key還沒同步到slave節點。剛好這時，master節點發生故障，一個slave節點就會升級爲master節點。線程二就能夠獲取同個key的鎖啦，但線程一也已經拿到鎖了，鎖的安全性就沒了。

爲了解決這個問題，Redis做者 antirez提出一種高級的分佈式鎖算法：Redlock。Redlock核心思想是這樣的：

搞多個Redis master部署，以保證它們不會同時宕掉。而且這些master節點是徹底相互獨立的，相互之間不存在數據同步。同時，須要確保在這多個master實例上，是與在Redis單實例，使用相同方法來獲取和釋放鎖。

咱們假設當前有5個Redis master節點，在5臺服務器上面運行這些Redis實例。

RedLock的實現步驟:以下

1.獲取當前時間，以毫秒爲單位。

2.按順序向5個master節點請求加鎖。客戶端設置網絡鏈接和響應超時時間，而且超時時間要小於鎖的失效時間。（假設鎖自動失效時間爲10秒，則超時時間通常在5-50毫秒之間,咱們就假設超時時間是50ms吧）。若是超時，跳過該master節點，儘快去嘗試下一個master節點。

3.客戶端使用當前時間減去開始獲取鎖時間（即步驟1記錄的時間），獲得獲取鎖使用的時間。當且僅當超過一半（N/2+1，這裏是5/2+1=3個節點）的Redis master節點都得到鎖，而且使用的時間小於鎖失效時間時，鎖纔算獲取成功。（如上圖，10s> 30ms+40ms+50ms+4m0s+50ms）

若是取到了鎖，key的真正有效時間就變啦，須要減去獲取鎖所使用的時間。

若是獲取鎖失敗（沒有在至少N/2+1個master實例取到鎖，有或者獲取鎖時間已經超過了有效時間），客戶端要在全部的master節點上解鎖（即使有些master節點根本就沒有加鎖成功，也須要解鎖，以防止有些漏網之魚）。

簡化下步驟就是：

按順序向5個master節點請求加鎖
根據設置的超時時間來判斷，是否是要跳過該master節點。
若是大於等於三個節點加鎖成功，而且使用的時間小於鎖的有效期，便可認定加鎖成功啦。
若是獲取鎖失敗，解鎖！

Redisson實現了redLock版本的鎖，有興趣的小夥伴，能夠去了解一下哈~

公衆號

歡迎關注公衆號：撿田螺的小男孩