如何優(yōu)雅地用Redis實現(xiàn)分布式鎖？

首先明確分布式鎖應(yīng)該具備什么特性:獲取鎖的業(yè)務(wù)無論正常與否，都必須能釋放鎖，這樣才能避免死鎖;鎖應(yīng)該具有高可用性。

我們來看看redis是怎么來實現(xiàn)鎖的的。

redis主要是通過setnx、get、getset、del命令來完成加鎖，搶鎖和釋放鎖的操作的，這里我用兩個客戶端來模擬下加鎖的過程。下面有實際操作的截圖。

1、客戶端1使用setnx獲取到鎖，并設(shè)置鎖的當(dāng)前時間。設(shè)置超時時間就是為了業(yè)務(wù)掛了，鎖不能釋放成為死鎖。

執(zhí)行命令

setnx lock 0

為了方便舉例，我們假定鎖的當(dāng)前時間是從0秒開始的，超時時間為3秒。如果結(jié)果返回為1，表明加鎖成功，可以執(zhí)行業(yè)務(wù)邏輯了。

2、當(dāng)?shù)谝幻腌娍蛻舳?使用setnx獲取鎖，執(zhí)行命令

setnx lock 1

返回值為0，則加鎖失敗。

3、客戶端2接收到加鎖時間的回應(yīng)后，會去查看鎖是否超時。執(zhí)行命令

get lock

返回值為加鎖的時間，假設(shè)現(xiàn)在時間已經(jīng)到第4秒了，客戶端會使用返回的時間0加上超時時間3小于當(dāng)前時間4，鎖已經(jīng)超時了。

4、客戶端2使用getset命令去獲取鎖。

getset lock 4

這時候返回的是前一次加鎖的時間，如果這個時間是0，證明加鎖成功，因為和前一次get的值相同。如果不同，說明鎖已經(jīng)被別人搶占了，加鎖失敗，繼續(xù)重復(fù)步驟3和4。

5、業(yè)務(wù)執(zhí)行完成后，判斷下鎖是否超時，沒有超時，不用管了。如果沒有超時，調(diào)用del命令釋放鎖即可。

redis存在的問題

1、redis如果是單機的話是有單點問題的，不滿足高可用性。redis集群因為是ap模型，是不能保證一致性的，官方提供了redlock算法來解決這個問題，但是至少需要3個master-slave節(jié)點才能完成，成本也較大。redlock相當(dāng)于是來實現(xiàn)一致性協(xié)議的。

2、鎖的超時時間設(shè)定問題，太長太短都不合適，太長了如果服務(wù)掛掉了會一直阻塞業(yè)務(wù)，太短了有可能業(yè)務(wù)還沒執(zhí)行完成就釋放了。當(dāng)然可以用官方提供redisson解決。

可以關(guān)注我，我在文章里面還分享了zk,etcd怎么實現(xiàn)分布式鎖的。