前言

日常開(kāi)發(fā)中，秒殺下單、搶紅包等等業(yè)務(wù)場(chǎng)景，都需要用到分布式鎖。而Redis非常適合作為分布式鎖使用。本文將分七個(gè)方案展開(kāi)，跟大家探討Redis分布式鎖的正確使用方式。如果有不正確的地方，歡迎大家指出哈，一起學(xué)習(xí)一起進(jìn)步。

什么是分布式鎖

方案一：SETNX + EXPIRE

方案二：SETNX + value值是（系統(tǒng)時(shí)間+過(guò)期時(shí)間）

方案三：使用Lua腳本（包含SETNX + EXPIRE兩條指令）

方案四：SET的擴(kuò)展命令（SET EX PX NX）

方案五：SET EX PX NX + 校驗(yàn)唯一隨機(jī)值，再釋放鎖

方案六： 開(kāi)源框架~Redisson

方案七：多機(jī)實(shí)現(xiàn)的分布式鎖Redlock

什么是分布式鎖

分布式鎖其實(shí)就是，控制分布式系統(tǒng)不同進(jìn)程共同訪問(wèn)共享資源的一種鎖的實(shí)現(xiàn)。如果不同的系統(tǒng)或同一個(gè)系統(tǒng)的不同主機(jī)之間共享了某個(gè)臨界資源，往往需要互斥來(lái)防止彼此干擾，以保證一致性。

我們先來(lái)看下，一把靠譜的分布式鎖應(yīng)該有哪些特征：

「互斥性」： 任意時(shí)刻，只有一個(gè)客戶端能持有鎖。

「鎖超時(shí)釋放」：持有鎖超時(shí)，可以釋放，防止不必要的資源浪費(fèi)，也可以防止死鎖。

「可重入性」：一個(gè)線程如果獲取了鎖之后，可以再次對(duì)其請(qǐng)求加鎖。

「高性能和高可用」：加鎖和解鎖需要開(kāi)銷盡可能低，同時(shí)也要保證高可用，避免分布式鎖失效。

「安全性」：鎖只能被持有的客戶端刪除，不能被其他客戶端刪除

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

提到Redis的分布式鎖，很多小伙伴馬上就會(huì)想到setnx+ expire命令。即先用setnx來(lái)?yè)屾i，如果搶到之后，再用expire給鎖設(shè)置一個(gè)過(guò)期時(shí)間，防止鎖忘記了釋放。

SETNX 是SET IF NOT EXISTS的簡(jiǎn)寫(xiě)。日常命令格式是SETNX key value，如果 key不存在，則SETNX成功返回1，如果這個(gè)key已經(jīng)存在了，則返回0。

假設(shè)某電商網(wǎng)站的某商品做秒殺活動(dòng)，key可以設(shè)置為key_resource_id，value設(shè)置任意值，偽代碼如下：

if（jedis.setnx（key_resource_id，lock_value） == 1）{ //加鎖

expire（key_resource_id，100）; //設(shè)置過(guò)期時(shí)間

try {

do something //業(yè)務(wù)請(qǐng)求

}catch（）{

}

finally {

jedis.del（key_resource_id）; //釋放鎖

}

}

但是這個(gè)方案中，setnx和expire兩個(gè)命令分開(kāi)了，「不是原子操作」。如果執(zhí)行完setnx加鎖，正要執(zhí)行expire設(shè)置過(guò)期時(shí)間時(shí)，進(jìn)程crash或者要重啟維護(hù)了，那么這個(gè)鎖就“長(zhǎng)生不老”了，「別的線程永遠(yuǎn)獲取不到鎖啦」。

Redis分布式鎖方案二：SETNX + value值是（系統(tǒng)時(shí)間+過(guò)期時(shí)間）

為了解決方案一，「發(fā)生異常鎖得不到釋放的場(chǎng)景」，有小伙伴認(rèn)為，可以把過(guò)期時(shí)間放到setnx的value值里面。如果加鎖失敗，再拿出value值校驗(yàn)一下即可。加鎖代碼如下：

long expires = System.currentTimeMillis（） + expireTime; //系統(tǒng)時(shí)間+設(shè)置的過(guò)期時(shí)間

String expiresStr = String.valueOf（expires）;

// 如果當(dāng)前鎖不存在，返回加鎖成功

if （jedis.setnx（key_resource_id， expiresStr） == 1） {

return true;

}

// 如果鎖已經(jīng)存在，獲取鎖的過(guò)期時(shí)間

String currentValueStr = jedis.get（key_resource_id）;

// 如果獲取到的過(guò)期時(shí)間，小于系統(tǒng)當(dāng)前時(shí)間，表示已經(jīng)過(guò)期

if （currentValueStr ！= null && Long.parseLong（currentValueStr） 《 System.currentTimeMillis（）） {

// 鎖已過(guò)期，獲取上一個(gè)鎖的過(guò)期時(shí)間，并設(shè)置現(xiàn)在鎖的過(guò)期時(shí)間（不了解redis的getSet命令的小伙伴，可以去官網(wǎng)看下哈）

String oldValueStr = jedis.getSet（key_resource_id， expiresStr）;

if （oldValueStr ！= null && oldValueStr.equals（currentValueStr）） {

// 考慮多線程并發(fā)的情況，只有一個(gè)線程的設(shè)置值和當(dāng)前值相同，它才可以加鎖

return true;

}

}

//其他情況，均返回加鎖失敗

return false;

}

這個(gè)方案的優(yōu)點(diǎn)是，巧妙移除expire單獨(dú)設(shè)置過(guò)期時(shí)間的操作，把「過(guò)期時(shí)間放到setnx的value值」里面來(lái)。解決了方案一發(fā)生異常，鎖得不到釋放的問(wèn)題。但是這個(gè)方案還有別的缺點(diǎn)：

過(guò)期時(shí)間是客戶端自己生成的（System.currentTimeMillis（）是當(dāng)前系統(tǒng)的時(shí)間），必須要求分布式環(huán)境下，每個(gè)客戶端的時(shí)間必須同步。

如果鎖過(guò)期的時(shí)候，并發(fā)多個(gè)客戶端同時(shí)請(qǐng)求過(guò)來(lái)，都執(zhí)行jedis.getSet（），最終只能有一個(gè)客戶端加鎖成功，但是該客戶端鎖的過(guò)期時(shí)間，可能被別的客戶端覆蓋

該鎖沒(méi)有保存持有者的唯一標(biāo)識(shí)，可能被別的客戶端釋放/解鎖。

Redis分布式鎖方案三：使用Lua腳本（包含SETNX + EXPIRE兩條指令）

實(shí)際上，我們還可以使用Lua腳本來(lái)保證原子性（包含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）;

這個(gè)方案，跟方案二對(duì)比，你覺(jué)得哪個(gè)更好呢？

Redis分布式鎖方案方案四：SET的擴(kuò)展命令（SET EX PX NX）

除了使用，使用Lua腳本，保證SETNX + EXPIRE兩條指令的原子性，我們還可以巧用Redis的SET指令擴(kuò)展參數(shù)！（SET key value［EX seconds］［PX milliseconds］［NX|XX］），它也是原子性的！

SET key value［EX seconds］［PX milliseconds］［NX|XX］

NX ：表示key不存在的時(shí)候，才能set成功，也即保證只有第一個(gè)客戶端請(qǐng)求才能獲得鎖，而其他客戶端請(qǐng)求只能等其釋放鎖，才能獲取。

EX seconds ：設(shè)定key的過(guò)期時(shí)間，時(shí)間單位是秒。

PX milliseconds： 設(shè)定key的過(guò)期時(shí)間，單位為毫秒

XX： 僅當(dāng)key存在時(shí)設(shè)置值

偽代碼demo如下：

if（jedis.set（key_resource_id， lock_value， “NX”， “EX”， 100s） == 1）{ //加鎖

try {

do something //業(yè)務(wù)處理

}catch（）{

}

finally {

jedis.del（key_resource_id）; //釋放鎖

}

}

但是呢，這個(gè)方案還是可能存在問(wèn)題：

問(wèn)題一：「鎖過(guò)期釋放了，業(yè)務(wù)還沒(méi)執(zhí)行完」。假設(shè)線程a獲取鎖成功，一直在執(zhí)行臨界區(qū)的代碼。但是100s過(guò)去后，它還沒(méi)執(zhí)行完。但是，這時(shí)候鎖已經(jīng)過(guò)期了，此時(shí)線程b又請(qǐng)求過(guò)來(lái)。顯然線程b就可以獲得鎖成功，也開(kāi)始執(zhí)行臨界區(qū)的代碼。那么問(wèn)題就來(lái)了，臨界區(qū)的業(yè)務(wù)代碼都不是嚴(yán)格串行執(zhí)行的啦。

問(wèn)題二：「鎖被別的線程誤刪」。假設(shè)線程a執(zhí)行完后，去釋放鎖。但是它不知道當(dāng)前的鎖可能是線程b持有的（線程a去釋放鎖時(shí)，有可能過(guò)期時(shí)間已經(jīng)到了，此時(shí)線程b進(jìn)來(lái)占有了鎖）。那線程a就把線程b的鎖釋放掉了，但是線程b臨界區(qū)業(yè)務(wù)代碼可能都還沒(méi)執(zhí)行完呢。

方案五：SET EX PX NX + 校驗(yàn)唯一隨機(jī)值，再刪除

既然鎖可能被別的線程誤刪，那我們給value值設(shè)置一個(gè)標(biāo)記當(dāng)前線程唯一的隨機(jī)數(shù)，在刪除的時(shí)候，校驗(yàn)一下，不就OK了嘛。偽代碼如下：

if（jedis.set（key_resource_id， uni_request_id， “NX”， “EX”， 100s） == 1）{ //加鎖

try {

do something //業(yè)務(wù)處理

}catch（）{

}

finally {

//判斷是不是當(dāng)前線程加的鎖，是才釋放

if （uni_request_id.equals（jedis.get（key_resource_id））） {

jedis.del（lockKey）; //釋放鎖

}

}

}

在這里，「判斷是不是當(dāng)前線程加的鎖」和「釋放鎖」不是一個(gè)原子操作。如果調(diào)用jedis.del（）釋放鎖的時(shí)候，可能這把鎖已經(jīng)不屬于當(dāng)前客戶端，會(huì)解除他人加的鎖。

為了更嚴(yán)謹(jǐn)，一般也是用lua腳本代替。lua腳本如下：

if redis.call（‘get’，KEYS［1］） == ARGV［1］ then

return redis.call（‘del’，KEYS［1］）

else

return 0

end;

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

方案五還是可能存在「鎖過(guò)期釋放，業(yè)務(wù)沒(méi)執(zhí)行完」的問(wèn)題。有些小伙伴認(rèn)為，稍微把鎖過(guò)期時(shí)間設(shè)置長(zhǎng)一些就可以啦。其實(shí)我們?cè)O(shè)想一下，是否可以給獲得鎖的線程，開(kāi)啟一個(gè)定時(shí)守護(hù)線程，每隔一段時(shí)間檢查鎖是否還存在，存在則對(duì)鎖的過(guò)期時(shí)間延長(zhǎng)，防止鎖過(guò)期提前釋放。

當(dāng)前開(kāi)源框架Redisson解決了這個(gè)問(wèn)題。我們一起來(lái)看下Redisson底層原理圖吧：

只要線程一加鎖成功，就會(huì)啟動(dòng)一個(gè)watch dog看門(mén)狗，它是一個(gè)后臺(tái)線程，會(huì)每隔10秒檢查一下，如果線程1還持有鎖，那么就會(huì)不斷的延長(zhǎng)鎖key的生存時(shí)間。因此，Redisson就是使用Redisson解決了「鎖過(guò)期釋放，業(yè)務(wù)沒(méi)執(zhí)行完」問(wèn)題。

Redis分布式鎖方案七：多機(jī)實(shí)現(xiàn)的分布式鎖Redlock+Redisson

前面六種方案都只是基于單機(jī)版的討論，還不是很完美。其實(shí)Redis一般都是集群部署的：

如果線程一在Redis的master節(jié)點(diǎn)上拿到了鎖，但是加鎖的key還沒(méi)同步到slave節(jié)點(diǎn)。恰好這時(shí)，master節(jié)點(diǎn)發(fā)生故障，一個(gè)slave節(jié)點(diǎn)就會(huì)升級(jí)為master節(jié)點(diǎn)。線程二就可以獲取同個(gè)key的鎖啦，但線程一也已經(jīng)拿到鎖了，鎖的安全性就沒(méi)了。

為了解決這個(gè)問(wèn)題，Redis作者 antirez提出一種高級(jí)的分布式鎖算法：Redlock。Redlock核心思想是這樣的：

搞多個(gè)Redis master部署，以保證它們不會(huì)同時(shí)宕掉。并且這些master節(jié)點(diǎn)是完全相互獨(dú)立的，相互之間不存在數(shù)據(jù)同步。同時(shí)，需要確保在這多個(gè)master實(shí)例上，是與在Redis單實(shí)例，使用相同方法來(lái)獲取和釋放鎖。

我們假設(shè)當(dāng)前有5個(gè)Redis master節(jié)點(diǎn)，在5臺(tái)服務(wù)器上面運(yùn)行這些Redis實(shí)例。

RedLock的實(shí)現(xiàn)步驟：如下

1.獲取當(dāng)前時(shí)間，以毫秒為單位。

2.按順序向5個(gè)master節(jié)點(diǎn)請(qǐng)求加鎖。客戶端設(shè)置網(wǎng)絡(luò)連接和響應(yīng)超時(shí)時(shí)間，并且超時(shí)時(shí)間要小于鎖的失效時(shí)間。（假設(shè)鎖自動(dòng)失效時(shí)間為10秒，則超時(shí)時(shí)間一般在5-50毫秒之間，我們就假設(shè)超時(shí)時(shí)間是50ms吧）。如果超時(shí)，跳過(guò)該master節(jié)點(diǎn)，盡快去嘗試下一個(gè)master節(jié)點(diǎn)。

3.客戶端使用當(dāng)前時(shí)間減去開(kāi)始獲取鎖時(shí)間（即步驟1記錄的時(shí)間），得到獲取鎖使用的時(shí)間。當(dāng)且僅當(dāng)超過(guò)一半（N/2+1，這里是5/2+1=3個(gè)節(jié)點(diǎn)）的Redis master節(jié)點(diǎn)都獲得鎖，并且使用的時(shí)間小于鎖失效時(shí)間時(shí)，鎖才算獲取成功。（如上圖，10s》 30ms+40ms+50ms+4m0s+50ms）

如果取到了鎖，key的真正有效時(shí)間就變啦，需要減去獲取鎖所使用的時(shí)間。

如果獲取鎖失敗（沒(méi)有在至少N/2+1個(gè)master實(shí)例取到鎖，有或者獲取鎖時(shí)間已經(jīng)超過(guò)了有效時(shí)間），客戶端要在所有的master節(jié)點(diǎn)上解鎖（即便有些master節(jié)點(diǎn)根本就沒(méi)有加鎖成功，也需要解鎖，以防止有些漏網(wǎng)之魚(yú)）。

簡(jiǎn)化下步驟就是：

按順序向5個(gè)master節(jié)點(diǎn)請(qǐng)求加鎖

根據(jù)設(shè)置的超時(shí)時(shí)間來(lái)判斷，是不是要跳過(guò)該master節(jié)點(diǎn)。

如果大于等于3個(gè)節(jié)點(diǎn)加鎖成功，并且使用的時(shí)間小于鎖的有效期，即可認(rèn)定加鎖成功啦。

如果獲取鎖失敗，解鎖！

Redisson實(shí)現(xiàn)了redLock版本的鎖，有興趣的小伙伴，可以去了解一下哈~

原文標(biāo)題：七種方案！探討Redis分布式鎖的正確使用姿勢(shì)

文章出處：【微信公眾號(hào)：數(shù)據(jù)分析與開(kāi)發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq