Redis分布式鎖設(shè)置超時(shí)時(shí)間

Redis分布式鎖主要依靠Redis服務(wù)來(lái)完成，我們的應(yīng)用程序其實(shí)是Redis節(jié)點(diǎn)的客戶端，一旦客戶端沒(méi)有釋放鎖，服務(wù)端就會(huì)一直持有這個(gè)鎖，其他進(jìn)程中的線程就無(wú)法獲取到這把鎖，于是就會(huì)發(fā)生鎖死的情況。

所以我們?cè)谑褂肦edis分布式鎖的時(shí)候，務(wù)必要設(shè)置鎖的過(guò)期時(shí)間。

主要基于下面兩點(diǎn)：

網(wǎng)絡(luò)抖動(dòng)

客戶端A中的一個(gè)線程獲取到了鎖，然后執(zhí)行finally中的釋放鎖的代碼時(shí)，這時(shí)候網(wǎng)絡(luò)出問(wèn)題了，導(dǎo)致客戶端A沒(méi)有成功釋放鎖。此時(shí)對(duì)于redis服務(wù)端來(lái)說(shuō)，它會(huì)一直把鎖給客戶端A，這樣的話其他客戶端自然也就不能獲取到這個(gè)鎖。

如果是設(shè)置了過(guò)期時(shí)間的話，即使客戶端和服務(wù)端的網(wǎng)絡(luò)不通了，服務(wù)端依然在進(jìn)行時(shí)間的計(jì)算，時(shí)間到了直接把鎖釋放掉，等網(wǎng)絡(luò)通了，不影響其他客戶端獲取鎖。

Redis宕機(jī)

客戶端A獲取到了鎖，Redis服務(wù)器突然宕機(jī)，鎖沒(méi)有釋放。等到Redis再次恢復(fù)的時(shí)候，Redis服務(wù)端還會(huì)把鎖給到客戶端A，這樣也會(huì)發(fā)生鎖死的情況。

如果是設(shè)置了過(guò)期時(shí)間的話，服務(wù)器恢復(fù)后就會(huì)繼續(xù)倒計(jì)時(shí)，時(shí)間到了服務(wù)器自動(dòng)把鎖釋放，其他客戶端也就可以嘗試去獲取鎖了。

Redis分布式鎖的超時(shí)問(wèn)題

Redis的分布式鎖并不能解決超時(shí)問(wèn)題，如果在加鎖和釋放鎖之間的邏輯執(zhí)行得太長(zhǎng)，以至于超出了鎖的超時(shí)限制，就會(huì)出現(xiàn)問(wèn)題，因?yàn)檫@時(shí)候第一個(gè)線程持有的鎖過(guò)期了，臨界區(qū)的邏輯還沒(méi)有執(zhí)行完，而同時(shí)第二個(gè)線程就提前持有了這把鎖，導(dǎo)致臨界區(qū)代碼不能得到嚴(yán)格串行執(zhí)行。

為了避免這個(gè)問(wèn)題，分布式鎖不要用于較長(zhǎng)時(shí)間的任務(wù)，如果真的偶爾出現(xiàn)了問(wèn)題，造成的數(shù)據(jù)小錯(cuò)亂，可能需要人工介入解決。

有一個(gè)稍微安全一點(diǎn)的方案，是將set指令的value參數(shù)設(shè)置為一個(gè)隨機(jī)數(shù)，釋放鎖時(shí)先匹配隨機(jī)數(shù)是否一致，然后在刪除key，這是為了確保當(dāng)前線程占有的鎖不會(huì)被其他線程釋放，除非這個(gè)鎖是自動(dòng)超時(shí)，但是匹配value,和刪除ke y不是一個(gè)原子操作，所以只是相對(duì)安全。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論