分布式Redis的分布式鎖Redlock

作者：Java開(kāi)發(fā)交流 2019-06-19 15:40:06

開(kāi)發(fā)

后端

其他數(shù)據(jù)庫(kù)

分布式

分布式

Redis 之前自己在用redis來(lái)實(shí)現(xiàn)分布式鎖的時(shí)候都是基于單個(gè)Redis實(shí)例，也就是說(shuō)Redis本身是有單點(diǎn)故障的，Redis的官方文檔介紹了一種"自認(rèn)為"合理的算法，Redlock來(lái)實(shí)現(xiàn)分布式Redis下的分布式鎖。

創(chuàng)新互聯(lián)是一家專(zhuān)業(yè)提供桐梓企業(yè)網(wǎng)站建設(shè),專(zhuān)注與網(wǎng)站制作、做網(wǎng)站、H5建站、小程序制作等業(yè)務(wù)。10年已為桐梓眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專(zhuān)業(yè)的建站公司優(yōu)惠進(jìn)行中。

引言

之前自己在用redis來(lái)實(shí)現(xiàn)分布式鎖的時(shí)候都是基于單個(gè)Redis實(shí)例，也就是說(shuō)Redis本身是有單點(diǎn)故障的，Redis的官方文檔介紹了一種"自認(rèn)為"合理的算法，Redlock來(lái)實(shí)現(xiàn)分布式Redis下的分布式鎖。

Martin Kleppmann寫(xiě)了一篇文章分析Redlock。然后redis的作者寫(xiě)了一篇反駁的文章這里。加油。

Redlock實(shí)現(xiàn)庫(kù)

• Java Redisson Star 9458
• C# RedLock.net Star 259
• Go redsync.go Star 249

雖然后面的算法是一樣的，不過(guò)這個(gè)點(diǎn)贊數(shù)確實(shí)服。

單點(diǎn)Redis鎖

先簡(jiǎn)單回顧一下單點(diǎn)的Redis鎖是怎么實(shí)現(xiàn)的。

獲取鎖

  
 
 
 

   
  
  
  
SET resource_name my_random_value NX PX 30000
  
 
 
 

客戶(hù)端A在Redis上設(shè)置一個(gè)特定的鍵值對(duì)，同時(shí)給一個(gè)超時(shí)時(shí)間(避免死鎖)。其他客戶(hù)端在訪(fǎng)問(wèn)的時(shí)候先看看這個(gè)key是否已經(jīng)存在，并且值等于my_random_value。如果已存在就等待，否則就獲取成功，執(zhí)行業(yè)務(wù)代碼。resource_name和my_random_value是所有客戶(hù)端都知道并且共享的。

釋放鎖

  
 
 
 

   
  
  
  
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end
  
 
 
 

對(duì)比key獲取到的對(duì)應(yīng)的value是否相等，如果相等，就刪除(釋放)，否則就返回失敗。

之前也寫(xiě)過(guò)一篇文章。

單點(diǎn)Redis鎖的缺陷

這個(gè)缺陷其實(shí)很明顯，如果只有一個(gè)Redis實(shí)例，這個(gè)掛了，所有依賴(lài)他的服務(wù)都掛了。顯然不太適合大型的應(yīng)用。

簡(jiǎn)單的Redis主從架構(gòu)碰到的問(wèn)題

為了避免單點(diǎn)故障，我們給Redis做一個(gè)Master/Slave的主從架構(gòu)，一個(gè)Master，一臺(tái)Slave。下面就會(huì)碰到這么一個(gè)問(wèn)題。下面是使用場(chǎng)景。

1. 客戶(hù)端A在Master上獲取到一個(gè)鎖。
2. Master把這個(gè)數(shù)據(jù)同步到Slave的時(shí)候掛了(因?yàn)镸aster和Slave之間同步是異步的)。
3. Slave變成了Master。
4. 客戶(hù)端B通過(guò)相同的key，和value獲取到鎖。分布式鎖失效

Redlock算法

假設(shè)我們有N(假設(shè)5)個(gè)Redis master實(shí)例，所有節(jié)點(diǎn)相互獨(dú)立，并且業(yè)務(wù)系統(tǒng)也是單純的調(diào)用，并沒(méi)有什么其他的類(lèi)似消息重發(fā)之類(lèi)的輔助系統(tǒng)。下面來(lái)模擬一下算法：

       1.客戶(hù)端獲取服務(wù)器當(dāng)前的的時(shí)間t0，毫秒數(shù)。

        2.使用相同的key和value依次向5個(gè)實(shí)例獲取鎖?？蛻?hù)端在獲取鎖的時(shí)候自身設(shè)置一個(gè)遠(yuǎn)小于業(yè)務(wù)鎖需要的持續(xù)時(shí)間的超時(shí)時(shí)間。舉個(gè)例子，假設(shè)鎖需要10秒，超時(shí)時(shí)間可以設(shè)置成比如5-50毫秒。這個(gè)避免某個(gè)Redis本身已經(jīng)掛了，但是客戶(hù)端一直在嘗試獲取鎖的情況。超時(shí)了之后就直接跳到下一個(gè)節(jié)點(diǎn)。

        3.客戶(hù)端通過(guò)當(dāng)前時(shí)間(t1)減去t0，計(jì)算獲取鎖所消耗的時(shí)間t2(=t1-t0)。只有t2小于鎖的業(yè)務(wù)有效時(shí)間(也就是第二步的10秒)，并且，客戶(hù)端在至少3(5/2+1)臺(tái)上獲取到鎖我們才認(rèn)為鎖獲取成功。

        4.如果鎖已經(jīng)獲取，那么鎖的業(yè)務(wù)有效時(shí)間為10s-t2。

        5.如果客戶(hù)端沒(méi)有獲取到鎖，可能是沒(méi)有在大于等于N/2+1個(gè)實(shí)例上獲取鎖，也可能是有效時(shí)間(10s-t2)為負(fù)數(shù)，我們就嘗試去釋放鎖，即使是并沒(méi)有在那個(gè)節(jié)點(diǎn)上獲取到。

鎖的釋放

釋放比較簡(jiǎn)單，直接刪除所有實(shí)例上對(duì)應(yīng)的key就好。喜歡文章的可以點(diǎn)個(gè)關(guān)注喲，感謝你的閱讀!

網(wǎng)站名稱(chēng)：分布式Redis的分布式鎖Redlock
文章路徑：http://uogjgqi.cn/article/dpcephd.html