前言：
目前網(wǎng)上大部分的基于zookpeer，和redis的分布式鎖的文章都不夠全面。要么就是特意避開(kāi)集群的情況，要么就是考慮不全，讀者看著還是一臉迷茫。坦白說(shuō)，這種老題材，很難寫(xiě)出新創(chuàng)意，博主內(nèi)心戰(zhàn)戰(zhàn)兢兢，如履薄冰，文中有什么不嚴(yán)謹(jǐn)之處，歡迎批評(píng)。
這篇文章， 不上代碼，只講分析 。
(1)在redis方面，有開(kāi)源redisson的jar包供你使用。
(2)在zookpeer方面，有開(kāi)源的curator的jar包供你使用
因?yàn)橐呀?jīng)有開(kāi)源jar包供你使用，沒(méi)有必要再去自己封裝一個(gè)，大家出門(mén)百度一個(gè)api即可，不需要再羅列一堆實(shí)現(xiàn)代碼。
需要說(shuō)明的是，Google有一個(gè)名為Chubby的粗粒度分布鎖的服務(wù)，然而，Google Chubby并不是開(kāi)源的，我們只能通過(guò)其論文和其他相關(guān)的文檔中了解具體的細(xì)節(jié)。值得慶幸的是，Yahoo！借鑒Chubby的設(shè)計(jì)思想開(kāi)發(fā)了Zookeeper，并將其開(kāi)源，因此本文不討論Chubby。至于Tair，是阿里開(kāi)源的一個(gè)分布式K-V存儲(chǔ)方案。我們?cè)诠ぷ髦谢旧蟫edis使用的比較多，討論Tair所實(shí)現(xiàn)的分布式鎖，不具有代表性。
因此，主要分析的還是redis和zookpper所實(shí)現(xiàn)的分布式鎖。
文章結(jié)構(gòu)
本文借鑒了兩篇國(guó)外大神的文章，redis的作者antirez的《Is Redlock safe?》以及分布式系統(tǒng)專(zhuān)家Martin的《How to do distributed locking》，再加上自己微薄的見(jiàn)解從而形成這篇文章，文章的目錄結(jié)構(gòu)如下:
(1)為什么使用分布式鎖
(2)單機(jī)情形比較
(3)集群情形比較
(4)鎖的其他特性比較
正文
先上 結(jié)論 :
zookpper可靠性比redis強(qiáng)太多，只是效率低了點(diǎn)，如果并發(fā)量不是特別大，追求可靠性，選zookpeer。為了效率，則選redis實(shí)現(xiàn)。
為什么使用分布式鎖？
使用分布式鎖的目的，無(wú)外乎就是保證同一時(shí)間只有一個(gè)客戶(hù)端可以對(duì)共享資源進(jìn)行操作。
但是Martin指出，根據(jù)鎖的用途還可以細(xì)分為以下兩類(lèi)
(1)允許多個(gè)客戶(hù)端操作共享資源
這種情況下，對(duì)共享資源的操作 一定是 冪等性操作，無(wú)論你操作多少次都不會(huì)出現(xiàn)不同結(jié)果。在這里使用鎖，無(wú)外乎就是為了避免重復(fù)操作共享資源從而提高效率。
(2)只允許一個(gè)客戶(hù)端操作共享資源
這種情況下，對(duì)共享資源的操作 一般是 非冪等性操作。在這種情況下，如果出現(xiàn)多個(gè)客戶(hù)端操作共享資源，就可能意味著數(shù)據(jù)不一致，數(shù)據(jù)丟失。
第一回合，單機(jī)情形比較
(1)redis
先說(shuō)加鎖，根據(jù)redis官網(wǎng)文檔的描述，使用下面的命令加鎖
SET resource_name my_random_value NX PX 30000
my_random_value是由客戶(hù)端生成的一個(gè)隨機(jī)字符串，相當(dāng)于是客戶(hù)端持有鎖的標(biāo)志
NX表示只有當(dāng)resource_name對(duì)應(yīng)的key值不存在的時(shí)候才能SET成功，相當(dāng)于只有第一個(gè)請(qǐng)求的客戶(hù)端才能獲得鎖
PX 30000表示這個(gè)鎖有一個(gè)30秒的自動(dòng)過(guò)期時(shí)間。
至于解鎖，為了防止客戶(hù)端1獲得的鎖，被客戶(hù)端2給釋放,采用下面的Lua腳本來(lái)釋放鎖
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
在執(zhí)行這段LUA腳本的時(shí)候，KEYS[1]的值為resource_name，ARGV[1]的值為my_random_value。原理就是先獲取鎖對(duì)應(yīng)的value值，保證和客戶(hù)端穿進(jìn)去的my_random_value值相等，這樣就能避免自己的鎖被其他人釋放。另外，采取Lua腳本操作保證了原子性.如果不是原子性操作，則有了下述情況出現(xiàn)
分析: 這套redis加解鎖機(jī)制看起來(lái)很完美，然而有一個(gè)無(wú)法避免的硬傷，就是 過(guò)期時(shí)間如何設(shè)置 。如果客戶(hù)端在操作共享資源的過(guò)程中，因?yàn)殚L(zhǎng)期阻塞的原因，導(dǎo)致鎖過(guò)期，那么接下來(lái)訪問(wèn)共享資源就不安全。
可是，有的人會(huì)說(shuō)
那可以在客戶(hù)端操作完共享資源后，判斷鎖是否依然歸該客戶(hù)端所有，如果依然歸客戶(hù)端所有，則提交資源，釋放鎖。若不歸客戶(hù)端所有，則不提交資源啊 .
OK,這么做，只能降低多個(gè)客戶(hù)端操作共享資源發(fā)生的概率，并不能解決問(wèn)題。
為了方便讀者理解，博主舉一個(gè)業(yè)務(wù)場(chǎng)景。
業(yè)務(wù)場(chǎng)景: 我們有一個(gè)內(nèi)容修改頁(yè)面，為了避免出現(xiàn)多個(gè)客戶(hù)端修改同一個(gè)頁(yè)面的請(qǐng)求，采用分布式鎖。只有獲得鎖的客戶(hù)端，才能修改頁(yè)面。那么正常修改一次頁(yè)面的流程如下圖所示
注意看，上面的步驟(3)-->步驟(4.1)并不是原子性操作。也就說(shuō)，你可能出現(xiàn)在步驟(3)的時(shí)候返回的是有效這個(gè)標(biāo)志位，但是在傳輸過(guò)程中，因?yàn)檠訒r(shí)等原因，在步驟(4.1)的時(shí)候，鎖已經(jīng)超時(shí)失效了。那么，這個(gè)時(shí)候鎖就會(huì)被另一個(gè)客戶(hù)端鎖獲得。就出現(xiàn)了兩個(gè)客戶(hù)端共同操作共享資源的情況。
大家可以思考一下，無(wú)論你如何采用任何補(bǔ)償手段，你都只能降低多個(gè)客戶(hù)端操作共享資源的概率，而無(wú)法避免。例如，你在步驟(4.1)的時(shí)候也可能發(fā)生長(zhǎng)時(shí)間GC停頓，然后在停頓的時(shí)候，鎖超時(shí)失效，從而鎖也有可能被其他客戶(hù)端獲得。這些大家可以自行思考推敲。
(2)zookpeer
先簡(jiǎn)單說(shuō)下原理，根據(jù)網(wǎng)上文檔描述，zookpeer的分布式鎖原理是利用了臨時(shí)節(jié)點(diǎn)(EPHEMERAL)的特性。
當(dāng)znode被聲明為EPHEMERAL的后，如果創(chuàng)建znode的那個(gè)客戶(hù)端崩潰了，那么相應(yīng)的znode會(huì)被自動(dòng)刪除。這樣就避免了設(shè)置過(guò)期時(shí)間的問(wèn)題。
客戶(hù)端嘗試創(chuàng)建一個(gè)znode節(jié)點(diǎn)，比如/lock。那么第一個(gè)客戶(hù)端就創(chuàng)建成功了，相當(dāng)于拿到了鎖；而其它的客戶(hù)端會(huì)創(chuàng)建失?。▃node已存在），獲取鎖失敗。
分析: 這種情況下，雖然避免了設(shè)置了有效時(shí)間問(wèn)題，然而還是有可能出現(xiàn)多個(gè)客戶(hù)端操作共享資源的。
大家應(yīng)該知道，Zookpeer如果長(zhǎng)時(shí)間檢測(cè)不到客戶(hù)端的心跳的時(shí)候(Session時(shí)間)，就會(huì)認(rèn)為Session過(guò)期了，那么這個(gè)Session所創(chuàng)建的所有的ephemeral類(lèi)型的znode節(jié)點(diǎn)都會(huì)被自動(dòng)刪除。
這種時(shí)候會(huì)有如下情形出現(xiàn)
如上圖所示，客戶(hù)端1發(fā)生GC停頓的時(shí)候，zookpeer檢測(cè)不到心跳，也是有可能出現(xiàn)多個(gè)客戶(hù)端同時(shí)操作共享資源的情形。當(dāng)然，你可以說(shuō)，我們可以通過(guò)JVM調(diào)優(yōu)，避免GC停頓出現(xiàn)。但是注意了，我們所做的一切，只能盡可能避免多個(gè)客戶(hù)端操作共享資源，無(wú)法完全消除。
第二回合，集群情形比較
我們?cè)谏a(chǎn)中，一般都是用集群情形，所以第一回合討論的單機(jī)情形。算是給大家熱熱身。
(1)redis
為了redis的高可用，一般都會(huì)給redis的節(jié)點(diǎn)掛一個(gè)slave,然后采用哨兵模式進(jìn)行主備切換。但由于Redis的主從復(fù)制（replication）是異步的，這可能會(huì)出現(xiàn)在數(shù)據(jù)同步過(guò)程中， master宕機(jī)，slave來(lái)不及同步數(shù)據(jù)就被選為master，從而數(shù)據(jù)丟失 。具體流程如下所示:
(1)客戶(hù)端1從Master獲取了鎖。
(2)Master宕機(jī)了，存儲(chǔ)鎖的key還沒(méi)有來(lái)得及同步到Slave上。
(3)Slave升級(jí)為Master。
(4)客戶(hù)端2從新的Master獲取到了對(duì)應(yīng)同一個(gè)資源的鎖。
為了應(yīng)對(duì)這個(gè)情形， redis的作者antirez提出了 RedLock算法 ，步驟如下(該流程出自官方文檔)，假設(shè)我們有N個(gè)master節(jié)點(diǎn)(官方文檔里將N設(shè)置成5，其實(shí)大等于3就行)
(1)獲取當(dāng)前時(shí)間（單位是毫秒）。
(2)輪流用相同的key和隨機(jī)值在N個(gè)節(jié)點(diǎn)上請(qǐng)求鎖，在這一步里，客戶(hù)端在每個(gè)master上請(qǐng)求鎖時(shí)，會(huì)有一個(gè)和總的鎖釋放時(shí)間相比小的多的超時(shí)時(shí)間。比如如果鎖自動(dòng)釋放時(shí)間是10秒鐘，那每個(gè)節(jié)點(diǎn)鎖請(qǐng)求的超時(shí)時(shí)間可能是5-50毫秒的范圍，這個(gè)可以防止一個(gè)客戶(hù)端在某個(gè)宕掉的master節(jié)點(diǎn)上阻塞過(guò)長(zhǎng)時(shí)間，如果一個(gè)master節(jié)點(diǎn)不可用了，我們應(yīng)該盡快嘗試下一個(gè)master節(jié)點(diǎn)。
(3)客戶(hù)端計(jì)算第二步中獲取鎖所花的時(shí)間，只有當(dāng)客戶(hù)端在大多數(shù)master節(jié)點(diǎn)上成功獲取了鎖（在這里是3個(gè)），而且總共消耗的時(shí)間不超過(guò)鎖釋放時(shí)間，這個(gè)鎖就認(rèn)為是獲取成功了。
(4)如果鎖獲取成功了，那現(xiàn)在鎖自動(dòng)釋放時(shí)間就是最初的鎖釋放時(shí)間減去之前獲取鎖所消耗的時(shí)間。
(5)如果鎖獲取失敗了，不管是因?yàn)楂@取成功的鎖不超過(guò)一半（N/2+1)還是因?yàn)榭傁臅r(shí)間超過(guò)了鎖釋放時(shí)間，客戶(hù)端都會(huì)到每個(gè)master節(jié)點(diǎn)上釋放鎖，即便是那些他認(rèn)為沒(méi)有獲取成功的鎖。
分析: RedLock算法細(xì)想一下還存在下面的問(wèn)題
節(jié)點(diǎn)崩潰重啟，會(huì)出現(xiàn)多個(gè)客戶(hù)端持有鎖
假設(shè)一共有5個(gè)Redis節(jié)點(diǎn)：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：
(1)客戶(hù)端1成功鎖住了A, B, C，獲取鎖成功（但D和E沒(méi)有鎖住）。
(2)節(jié)點(diǎn)C崩潰重啟了，但客戶(hù)端1在C上加的鎖沒(méi)有持久化下來(lái)，丟失了。
(3)節(jié)點(diǎn)C重啟后，客戶(hù)端2鎖住了C, D, E，獲取鎖成功。
這樣，客戶(hù)端1和客戶(hù)端2同時(shí)獲得了鎖（針對(duì)同一資源）。
為了應(yīng)對(duì)節(jié)點(diǎn)重啟引發(fā)的鎖失效問(wèn)題，redis的作者antirez提出了 延遲重啟 的概念，即一個(gè)節(jié)點(diǎn)崩潰后，先不立即重啟它，而是等待一段時(shí)間再重啟，等待的時(shí)間大于鎖的有效時(shí)間。采用這種方式，這個(gè)節(jié)點(diǎn)在重啟前所參與的鎖都會(huì)過(guò)期，它在重啟后就不會(huì)對(duì)現(xiàn)有的鎖造成影響。這其實(shí)也是通過(guò)人為補(bǔ)償措施，降低不一致發(fā)生的概率。
時(shí)間跳躍問(wèn)題
(1)假設(shè)一共有5個(gè)Redis節(jié)點(diǎn)：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：
(2)客戶(hù)端1從Redis節(jié)點(diǎn)A, B, C成功獲取了鎖（多數(shù)節(jié)點(diǎn)）。由于網(wǎng)絡(luò)問(wèn)題，與D和E通信失敗。
(3)節(jié)點(diǎn)C上的時(shí)鐘發(fā)生了向前跳躍，導(dǎo)致它上面維護(hù)的鎖快速過(guò)期。
客戶(hù)端2從Redis節(jié)點(diǎn)C, D, E成功獲取了同一個(gè)資源的鎖（多數(shù)節(jié)點(diǎn)）。
客戶(hù)端1和客戶(hù)端2現(xiàn)在都認(rèn)為自己持有了鎖。
為了應(yīng)對(duì)始終跳躍引發(fā)的鎖失效問(wèn)題，redis的作者antirez提出了應(yīng)該禁止人為修改系統(tǒng)時(shí)間，使用一個(gè)不會(huì)進(jìn)行“跳躍”式調(diào)整系統(tǒng)時(shí)鐘的ntpd程序。這也是通過(guò)人為補(bǔ)償措施，降低不一致發(fā)生的概率。
超時(shí)導(dǎo)致鎖失效問(wèn)題
RedLock算法并沒(méi)有解決，操作共享資源超時(shí)，導(dǎo)致鎖失效的問(wèn)題。回憶一下RedLock算法的過(guò)程，如下圖所示
如圖所示，我們將其分為上下兩個(gè)部分。對(duì)于上半部分框圖里的步驟來(lái)說(shuō)，無(wú)論因?yàn)槭裁丛虬l(fā)生了延遲，RedLock算法都能處理，客戶(hù)端不會(huì)拿到一個(gè)它認(rèn)為有效，實(shí)際卻失效的鎖。然而，對(duì)于下半部分框圖里的步驟來(lái)說(shuō)，如果發(fā)生了延遲導(dǎo)致鎖失效，都有可能使得客戶(hù)端2拿到鎖。因此，RedLock算法并沒(méi)有解決該問(wèn)題。
(2)zookpeer
zookpeer在集群部署中，zookpeer節(jié)點(diǎn)數(shù)量一般是奇數(shù)，且一定大等于3。我們先回憶一下，zookpeer的寫(xiě)數(shù)據(jù)的原理
如圖所示，這張圖懶得畫(huà)，直接搬其他文章的了。
那么寫(xiě)數(shù)據(jù)流程步驟如下
1.在Client向Follwer發(fā)出一個(gè)寫(xiě)的請(qǐng)求
2.Follwer把請(qǐng)求發(fā)送給Leader
3.Leader接收到以后開(kāi)始發(fā)起投票并通知Follwer進(jìn)行投票
4.Follwer把投票結(jié)果發(fā)送給Leader， 只要半數(shù)以上返回了ACK信息，就認(rèn)為通過(guò)
5.Leader將結(jié)果匯總后如果需要寫(xiě)入，則開(kāi)始寫(xiě)入同時(shí)把寫(xiě)入操作通知給Leader，然后commit;
6.Follwer把請(qǐng)求結(jié)果返回給Client
還有一點(diǎn)，zookpeer采取的是 全局串行化操作
OK,現(xiàn)在開(kāi)始分析
集群同步
client給Follwer寫(xiě)數(shù)據(jù)，可是Follwer卻宕機(jī)了，會(huì)出現(xiàn)數(shù)據(jù)不一致問(wèn)題么？不可能，這種時(shí)候，client建立節(jié)點(diǎn)失敗，根本獲取不到鎖。
client給Follwer寫(xiě)數(shù)據(jù)，F(xiàn)ollwer將請(qǐng)求轉(zhuǎn)發(fā)給Leader,Leader宕機(jī)了，會(huì)出現(xiàn)不一致的問(wèn)題么？不可能，這種時(shí)候，zookpeer會(huì)選取新的leader,繼續(xù)上面的提到的寫(xiě)流程。
總之，采用zookpeer作為分布式鎖，你要么就獲取不到鎖，一旦獲取到了，必定節(jié)點(diǎn)的數(shù)據(jù)是一致的，不會(huì)出現(xiàn)redis那種異步同步導(dǎo)致數(shù)據(jù)丟失的問(wèn)題。
時(shí)間跳躍問(wèn)題
不依賴(lài)全局時(shí)間，怎么會(huì)存在這種問(wèn)題
超時(shí)導(dǎo)致鎖失效問(wèn)題
不依賴(lài)有效時(shí)間，怎么會(huì)存在這種問(wèn)題
第三回合，鎖的其他特性比較
(1)redis的讀寫(xiě)性能比zookpeer強(qiáng)太多，如果在高并發(fā)場(chǎng)景中，使用zookpeer作為分布式鎖，那么會(huì)出現(xiàn)獲取鎖失敗的情況，存在性能瓶頸。
(2)zookpeer可以實(shí)現(xiàn)讀寫(xiě)鎖，redis不行。
(3)ZooKeeper的watch機(jī)制,客戶(hù)端試圖創(chuàng)建znode的時(shí)候，發(fā)現(xiàn)它已經(jīng)存在了，這時(shí)候創(chuàng)建失敗,那么進(jìn)入一種等待狀態(tài)，當(dāng)znode節(jié)點(diǎn)被刪除的時(shí)候，ZooKeeper通過(guò)watch機(jī)制通知它，這樣它就可以繼續(xù)完成創(chuàng)建操作（獲取鎖）。這可以讓分布式鎖在客戶(hù)端用起來(lái)就像一個(gè)本地的鎖一樣：加鎖失敗就阻塞住，直到獲取到鎖為止。這套機(jī)制，redis無(wú)法實(shí)現(xiàn)
作者：孤獨(dú)煙 出處： http://rjzheng.cnblogs.com/
總結(jié)
OK，正文啰嗦了一大堆。其實(shí)只是想表明兩個(gè)觀點(diǎn)，無(wú)論是redis還是zookpeer，其實(shí)可靠性都存在一點(diǎn)問(wèn)題。但是，zookpeer的分布式鎖的可靠性比redis強(qiáng)太多！但是,zookpeer讀寫(xiě)性能不如redis,存在著性能瓶頸。大家在生產(chǎn)上使用，可自行進(jìn)行評(píng)估使用。
為了讓學(xué)習(xí)變得輕松、高效，今天給大家免費(fèi)分享一套阿里架構(gòu)師傳授的一套教學(xué)資源。幫助大家在成為架構(gòu)師的道路上披荊斬棘。
這套視頻課程詳細(xì)講解了（Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)）等這些成為架構(gòu)師必備的內(nèi)容！
而且還把框架需要用到的各種程序進(jìn)行了打包，根據(jù)基礎(chǔ)視頻可以讓你輕松搭建分布式框架環(huán)境，像在企業(yè)生產(chǎn)環(huán)境一樣進(jìn)行學(xué)習(xí)和實(shí)踐。
加Java高級(jí)交流群：725633148 就可以馬上免費(fèi)獲得這套價(jià)值一萬(wàn)八的內(nèi)部教材！
重慶分公司
重慶分公司
