[[282700]]

在分布式系統(tǒng)中，分布式鎖是為了解決多實(shí)例之間的同步問(wèn)題。例如master選舉，能夠獲取分布式鎖的就是master，獲取失敗的就是slave。又或者能夠獲取鎖的實(shí)例能夠完成特定的操作。

目前比較常用的分布式鎖實(shí)現(xiàn)有兩種，基于zookeeper實(shí)現(xiàn)和基于redis實(shí)現(xiàn)。zookeeper和redis也是生產(chǎn)環(huán)境中經(jīng)常用到的第三方組件。下面我會(huì)分析它們的實(shí)現(xiàn)原理。

分布式鎖實(shí)現(xiàn)要求

實(shí)現(xiàn)一個(gè)分布式鎖至少要滿足下面三點(diǎn)要求：

1. 互斥，在任何時(shí)候同一個(gè)鎖只能由一個(gè)客戶端持有。
2. 不會(huì)死鎖，就算持有的客戶端異常崩潰也不會(huì)影響后續(xù)客戶端加鎖。
3. 誰(shuí)加鎖誰(shuí)解鎖，加鎖和解鎖都必須是同一個(gè)客戶端。

zookeeper分布式鎖

在講解zookeeper的分布式鎖之前有兩個(gè)概念需要明確：

1. 臨時(shí)節(jié)點(diǎn)：生命周期和鏈接周期一致。例如客戶端鏈接A創(chuàng)建了臨時(shí)節(jié)點(diǎn)NodeA，如果鏈接A關(guān)閉或者網(wǎng)絡(luò)異常斷開(kāi)，那么NodeA也會(huì)跟著消失。
2. 順序節(jié)點(diǎn)：節(jié)點(diǎn)名稱按照順序從小到大創(chuàng)建，例如先創(chuàng)建了000000001，那么接著創(chuàng)建的節(jié)點(diǎn)就會(huì)分配000000002。

zookeeper的分布式鎖實(shí)現(xiàn)原理就是利用臨時(shí)順序節(jié)點(diǎn)，大概流程為：

• 每個(gè)客戶端對(duì)某個(gè)功能加鎖時(shí)，在zookeeper指定目錄下生成一個(gè)唯一的臨時(shí)順序節(jié)點(diǎn)。
• 所有臨時(shí)節(jié)點(diǎn)中序號(hào)最小的節(jié)點(diǎn)即為當(dāng)前鎖的持有者。
• 釋放鎖時(shí)將自己持有的臨時(shí)節(jié)點(diǎn)刪除即可。

例如，對(duì)于加鎖過(guò)程，所有的客戶端都在/lock目錄下面創(chuàng)建臨時(shí)節(jié)點(diǎn)，如果發(fā)現(xiàn)自己創(chuàng)建的臨時(shí)節(jié)點(diǎn)是/lock目錄中最小的節(jié)點(diǎn)，那么就獲取鎖成功，否則就watch比自己小的節(jié)點(diǎn)中的最大節(jié)點(diǎn)。

監(jiān)控比自己小的節(jié)點(diǎn)中的最大節(jié)點(diǎn)是為了避免“驚群”效應(yīng)，避免一個(gè)鎖釋放把所有等待的客戶端喚醒，但是只有一個(gè)客戶端能獲取鎖。

對(duì)于釋放鎖，只需要把自己創(chuàng)建的臨時(shí)順序節(jié)點(diǎn)刪除即可。整個(gè)過(guò)程流程圖如下：

優(yōu)點(diǎn)：鎖安全性高，zookeeper數(shù)據(jù)不易丟失。用戶使用簡(jiǎn)單。

缺點(diǎn)：性能消耗比較高。因?yàn)樾枰獎(jiǎng)討B(tài)產(chǎn)生和刪除臨時(shí)節(jié)點(diǎn)，當(dāng)集群負(fù)載比較高時(shí)臨時(shí)節(jié)點(diǎn)消失會(huì)有時(shí)間差(一般在一分鐘范圍內(nèi))。

redis分布式鎖

redis的分布式鎖實(shí)現(xiàn)比zookeeper分布式鎖實(shí)現(xiàn)復(fù)雜，也分為redis單實(shí)例和多實(shí)例(master-master)實(shí)現(xiàn)方式。

需要特別指出的是redis如果是master-slave這種結(jié)構(gòu)部署時(shí)，獲取和釋放鎖都只能向master請(qǐng)求，和單實(shí)例的實(shí)現(xiàn)原理基本一樣，否則主從切換時(shí)會(huì)出現(xiàn)多人拿到同一把鎖的情況。

例如：

客戶端A在master拿到了鎖。

master節(jié)點(diǎn)在把A創(chuàng)建的key寫(xiě)入slave之前宕機(jī)了。(主從同步是異步操作)

slave變成了master節(jié)點(diǎn)。

B也得到了和A還持有的相同的鎖，因?yàn)閟lave還沒(méi)有A持有鎖的信息。

redis單實(shí)例實(shí)現(xiàn)方案

通過(guò)下面命令獲得鎖：

SET resource_name my_random_value NX PX 30000

這個(gè)命令的作用是只有這個(gè)key不存在時(shí)才會(huì)設(shè)置這個(gè)key的值(NX的作用，即not exist)，超時(shí)時(shí)間設(shè)置為30000毫秒(PX的作用)，這個(gè)key的值設(shè)置為my_random_value。這個(gè)值必須在所有獲取鎖請(qǐng)求的客戶端里面保持唯一。

key值的超時(shí)時(shí)間，也叫做“鎖有效時(shí)間”。這是鎖的自動(dòng)釋放時(shí)間。

這套實(shí)現(xiàn)方案在非分布式的、單點(diǎn)的、保證永不宕機(jī)的環(huán)境是適用的。

redis集群實(shí)現(xiàn)方案(Redlock算法)

在分布式版本的算法里我們假設(shè)有N個(gè)redis master節(jié)點(diǎn)，這些節(jié)點(diǎn)完全獨(dú)立，不用任何的復(fù)制或者分布式協(xié)調(diào)算法來(lái)同步數(shù)據(jù)。

這里假設(shè)N=5，一個(gè)客戶端獲取鎖的過(guò)程如下：

• 獲取當(dāng)前以毫秒為單位的時(shí)間。
• 輪詢用相同的key在N個(gè)節(jié)點(diǎn)上面請(qǐng)求鎖。(每個(gè)請(qǐng)求的超時(shí)時(shí)間設(shè)置的短一些，為了一個(gè)master節(jié)點(diǎn)不用時(shí)，快速請(qǐng)求下一個(gè)master)。
• 如果在超過(guò)一半master節(jié)點(diǎn)上面成功獲取鎖(這里是3個(gè))，客戶端計(jì)算第二步請(qǐng)求鎖花費(fèi)的時(shí)間，如果小于鎖釋放時(shí)間，則認(rèn)為獲取鎖成功。
• 如果鎖獲取成功了，那么現(xiàn)在 鎖自動(dòng)釋放時(shí)間=最初鎖釋放時(shí)間-請(qǐng)求鎖花費(fèi)的時(shí)間
• 如果獲取鎖失敗了(成功的鎖不超過(guò)master數(shù)量的一般 或者 請(qǐng)求耗時(shí)>鎖釋放時(shí)間)，那么客戶端都會(huì)在每個(gè)master節(jié)點(diǎn)上面釋放鎖。

獲取鎖成功的節(jié)點(diǎn)數(shù)需要超過(guò)master節(jié)點(diǎn)數(shù)量的一半才認(rèn)為是獲取鎖成功的思路應(yīng)該是借鑒了zookeeper的paxos算法。

還有一個(gè)需要指出的點(diǎn)是，當(dāng)一個(gè)客戶端獲取失敗時(shí)應(yīng)該隨時(shí)延時(shí)后再進(jìn)行重試，避免多個(gè)客戶端同時(shí)重試又同時(shí)失敗。

優(yōu)點(diǎn)：性能高

缺點(diǎn)：?jiǎn)螌?shí)例會(huì)有單點(diǎn)問(wèn)題，多實(shí)例主從切換會(huì)導(dǎo)致數(shù)據(jù)丟失，master-master集群模式實(shí)現(xiàn)復(fù)雜。

看大佬給你講解基于Zookeeper、Redis的分布式鎖