日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

又到了一周一次的分享時(shí)間啦，老規(guī)矩，還是先荒腔走板的聊聊生活。

成都創(chuàng)新互聯(lián)是一家專注于網(wǎng)站建設(shè)、網(wǎng)站制作和綿陽服務(wù)器托管的網(wǎng)絡(luò)公司，有著豐富的建站經(jīng)驗(yàn)和案例。

有上面的圖是讀大學(xué)的時(shí)候，一次自行車騎行途中隊(duì)友抓拍的我的照片。拍照的地方，名字叫做牛背山，一個(gè)名字很 low，實(shí)際很美的地方。

那條上山的路很難騎，超級爛路和極度變態(tài)的陡坡。真是一種折磨，是對意志力的完全考驗(yàn)。

在我們幾近崩潰，彈盡糧絕，離山頂還有近兩個(gè)多小時(shí)的時(shí)候，一個(gè)卡車司機(jī)主動(dòng)要求把我們免費(fèi)帶到山頂。我們拒絕了。

因?yàn)橥械男歉缢f了一句話：“騎行牛背山這件事情，我這輩子只會(huì)做這一次。現(xiàn)在的情況還不是那么糟，如果我搭車上去了，之后想起來我會(huì)有遺憾的。所以我更情愿推車?！?/p>

第二天下午山上下了一場暴風(fēng)雪。于是我們幾個(gè)南方孩子在這少見的雪景中肆意打鬧。打雪仗，堆雪人，滑雪......

晚上雪停了之后，我看到了讓我終身難忘的場景。星空，美麗到讓人想哭的星空!

后來，在人生路上的很多場景中，我都會(huì)想起星哥的那句話：這件事，我這輩子只會(huì)做這一次，我不想留下遺憾。還會(huì)想起那晚璀璨的、觸手可及般的星空。

堅(jiān)持不住的時(shí)候再堅(jiān)持一下，確實(shí)是一種難能可貴的精神。

好了，說回文章。

背景鋪墊

面試的時(shí)候，不管你的簡歷寫沒寫 Redis，它基本上是一個(gè)繞不過的話題。

為了引出本文要討論的關(guān)于 Redlock 的神仙打架的問題，我們就得先通過一個(gè)面試連環(huán)炮：

1. Redis 做分布式鎖的時(shí)候有需要注意的問題?
2. 如果是 Redis 是單點(diǎn)部署的，會(huì)帶來什么問題?
3. 那你準(zhǔn)備怎么解決單點(diǎn)問題呢?
4. 集群模式下，比如主從模式，有沒有什么問題呢?
5. 你知道 Redis 是怎么解決集群模式也不靠譜的問題的嗎?
6. 那你簡單的介紹一下 Redlock 吧?
7. 你覺得 Redlock 有什么問題呢?

很明顯，上面是一個(gè)常規(guī)的面試連環(huán)套路題。中間還可以插入很多其他的 Redis 的考察點(diǎn)，我這里就不做擴(kuò)展了。

單點(diǎn)的 Redis 做分布式鎖不靠譜，導(dǎo)致了基于 Redis 集群模式的分布式鎖解決方案的出現(xiàn)。

基于 Redis 集群模式的分布式鎖解決方案還是不靠譜，Redis 的作者提出了 Redlock 的解決方案。

Redis 作者提出的 Redlock 的解決方案，另一位分布式系統(tǒng)的大神覺得它不靠譜，于是他們之間開始了 battle。

基于這場 battle，又引發(fā)了更多的討論。

這場 battle 難分伯仲，沒有最后的贏家。如果一定要選出誰是最大的贏家的話，那一定是吃瓜網(wǎng)友。因?yàn)閷τ诔怨暇W(wǎng)友來說(比如我)，可以從兩位大神的交鋒中學(xué)習(xí)到很多東西。

讓你深刻的體會(huì)到：看起來那么無懈可擊的想法，細(xì)細(xì)推敲之下，并不是那么天衣無縫。

所以本文就按照下面的五個(gè)模塊展開講述。

先來一波勸退：本文近1.2w字，謹(jǐn)慎觀看。看不下去不要緊，拉到最后點(diǎn)個(gè)“在看”。就是對于我最大的鼓勵(lì)。奧利給!

單點(diǎn)Redis

按照我的經(jīng)驗(yàn)，當(dāng)面試聊到 Redis 的時(shí)候，百分之 90 的朋友都會(huì)說：Redis在我們的項(xiàng)目中是用來做熱點(diǎn)數(shù)據(jù)緩存的。

然后百分之百的面試官都會(huì)問：

Redis除了拿來做緩存，你還見過基于Redis的什么用法?

接下來百分之 80 的朋友都會(huì)說到：我們還用 Redis 做過分布式鎖。

(當(dāng)然， Redis 除了緩存、分布式鎖之外還有非常非常多的奇技淫巧，不是本文重點(diǎn)，大家有興趣的可以自己去了解一下。)

那么面試官就會(huì)接著說：

那你給我描述(或者寫一下偽代碼)基于Redis的加鎖和釋放鎖的細(xì)節(jié)吧。

注意面試官這里說的是加鎖和釋放鎖的細(xì)節(jié)，魔鬼都在細(xì)節(jié)里。

問這個(gè)問題面試官無非是想要聽到下面幾個(gè)關(guān)鍵點(diǎn)：

關(guān)鍵點(diǎn)一：原子命令加鎖。因?yàn)橛械摹澳昃檬蕖钡奈恼轮袑τ?Redis 的加鎖操作是先set key，再設(shè)置 key 的過期時(shí)間。這樣寫的根本原因是在早期的 Redis 版本中并不支持原子命令加鎖的操作。不是原子操作會(huì)帶來什么問題，就不用我說了吧?如果你不知道，你先回去等通知吧。

而在 2.6.12 版本后，可以通過向 Redis 發(fā)送下面的命令，實(shí)現(xiàn)原子性的加鎖操作：

SET key random_value NX PX 30000

關(guān)鍵點(diǎn)二：設(shè)置值的時(shí)候，放的是random_value。而不是你隨便扔個(gè)“OK”進(jìn)去。

先解釋一下上面的命令中的幾個(gè)參數(shù)的含義：

random_value：是由客戶端生成的一個(gè)隨機(jī)字符串，它要保證在足夠長的一段時(shí)間內(nèi)在所有客戶端的所有獲取鎖的請求中都是唯一的。

NX：表示只有當(dāng)要設(shè)置的 key 值不存在的時(shí)候才能 set 成功。這保證了只有第一個(gè)請求的客戶端才能獲得鎖，而其它客戶端在鎖被釋放之前都無法獲得鎖。

PX 30000：表示這個(gè)鎖有一個(gè) 30 秒的自動(dòng)過期時(shí)間。當(dāng)然，這里 30 秒只是一個(gè)例子，客戶端可以選擇合適的過期時(shí)間。

再解釋一下為什么 value 需要設(shè)置為一個(gè)隨機(jī)字符串。這也是第三個(gè)關(guān)鍵點(diǎn)。

關(guān)鍵點(diǎn)三：value 的值設(shè)置為隨機(jī)數(shù)主要是為了更安全的釋放鎖，釋放鎖的時(shí)候需要檢查 key 是否存在，且 key 對應(yīng)的值是否和我指定的值一樣，是一樣的才能釋放鎖。所以可以看到這里有獲取、判斷、刪除三個(gè)操作，為了保障原子性，我們需要用 lua 腳本。

(基本上能答到這幾個(gè)關(guān)鍵點(diǎn)，面試官也就會(huì)進(jìn)入下一個(gè)問題了。常規(guī)熱身送分題呀，朋友們，得記住了。)

集群模式

面試官就會(huì)接著問了：

經(jīng)過剛剛的討論，我們已經(jīng)有較好的方法獲取鎖和釋放鎖?；赗edis單實(shí)例，假設(shè)這個(gè)單實(shí)例總是可用，這種方法已經(jīng)足夠安全。如果這個(gè)Redis節(jié)點(diǎn)掛掉了呢?

到這個(gè)問題其實(shí)可以直接聊到 Redlock 了。但是你別慌啊，為了展示你豐富的知識儲備(瘋狂的刷題準(zhǔn)備)，你得先自己聊一聊 Redis 的集群，你可以這樣去說：

為了避免節(jié)點(diǎn)掛掉導(dǎo)致的問題，我們可以采用Redis集群的方法來實(shí)現(xiàn)Redis的高可用。

Redis集群方式共有三種：主從模式，哨兵模式，cluster(集群)模式

其中主從模式會(huì)保證數(shù)據(jù)在從節(jié)點(diǎn)還有一份，但是主節(jié)點(diǎn)掛了之后，需要手動(dòng)把從節(jié)點(diǎn)切換為主節(jié)點(diǎn)。它非常簡單，但是在實(shí)際的生產(chǎn)環(huán)境中是很少使用的。

哨兵模式就是主從模式的升級版，該模式下會(huì)對響應(yīng)異常的主節(jié)點(diǎn)進(jìn)行主觀下線或者客觀下線的操作，并進(jìn)行主從切換。它可以保證高可用。

cluster (集群)模式保證的是高并發(fā)，整個(gè)集群分擔(dān)所有數(shù)據(jù)，不同的 key 會(huì)放到不同的 Redis 中。每個(gè) Redis 對應(yīng)一部分的槽。

(上面三種模式也是面試重點(diǎn)，可以說很多道道出來，由于不是本文重點(diǎn)就不詳細(xì)描述了。主要表達(dá)的意思是你得在面試的時(shí)候遇到相關(guān)問題，需要展示自己是知道這些東西的，都是面試的套路。)

在上面描述的集群模式下還是會(huì)出現(xiàn)一個(gè)問題，由于節(jié)點(diǎn)之間是采用異步通信的方式。如果剛剛在 Master 節(jié)點(diǎn)上加了鎖，但是數(shù)據(jù)還沒被同步到 Salve。這時(shí) Master 節(jié)點(diǎn)掛了，它上面的鎖就沒了，等新的 Master 出來后(主從模式的手動(dòng)切換或者哨兵模式的一次 failover 的過程)，就可以再次獲取同樣的鎖，出現(xiàn)一把鎖被拿到了兩次的場景。

鎖都被拿了兩次了，也就不滿足安全性了。一個(gè)安全的鎖，不管是不是分布式的，在任意一個(gè)時(shí)刻，都只有一個(gè)客戶端持有。

Redlock簡介

為了解決上面的問題，Redis 的作者提出了名為 Redlock 的算法。

在 Redis 的分布式環(huán)境中，我們假設(shè)有 N 個(gè) Redis Master。這些節(jié)點(diǎn)完全互相獨(dú)立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機(jī)制。

前面已經(jīng)描述了在單點(diǎn) Redis 下，怎么安全地獲取和釋放鎖，我們確保將在 N 個(gè)實(shí)例上使用此方法獲取和釋放鎖。

在下面的示例中，我們假設(shè)有 5 個(gè)完全獨(dú)立的 Redis Master 節(jié)點(diǎn)，他們分別運(yùn)行在 5 臺服務(wù)器中，可以保證他們不會(huì)同時(shí)宕機(jī)。

從官網(wǎng)上我們可以知道，一個(gè)客戶端如果要獲得鎖，必須經(jīng)過下面的五個(gè)步驟：

步驟描述來源：

http://redis.cn/topics/distlock.html

1. 獲取當(dāng)前 Unix 時(shí)間，以毫秒為單位。
2. 依次嘗試從 N 個(gè)實(shí)例，使用相同的 key 和隨機(jī)值獲取鎖。在步驟 2，當(dāng)向 Redis 設(shè)置鎖時(shí)，客戶端應(yīng)該設(shè)置一個(gè)網(wǎng)絡(luò)連接和響應(yīng)超時(shí)時(shí)間，這個(gè)超時(shí)時(shí)間應(yīng)該小于鎖的失效時(shí)間。例如你的鎖自動(dòng)失效時(shí)間為 10 秒，則超時(shí)時(shí)間應(yīng)該在 5-50 毫秒之間。這樣可以避免服務(wù)器端 Redis 已經(jīng)掛掉的情況下，客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時(shí)間內(nèi)響應(yīng)，客戶端應(yīng)該盡快嘗試另外一個(gè) Redis 實(shí)例。
3. 客戶端使用當(dāng)前時(shí)間減去開始獲取鎖時(shí)間(步驟 1 記錄的時(shí)間)就得到獲取鎖使用的時(shí)間。當(dāng)且僅當(dāng)從大多數(shù)(這里是 3 個(gè)節(jié)點(diǎn))的 Redis 節(jié)點(diǎn)都取到鎖，并且使用的時(shí)間小于鎖失效時(shí)間時(shí)，鎖才算獲取成功。
4. 如果取到了鎖，key 的真正有效時(shí)間等于有效時(shí)間減去獲取鎖所使用的時(shí)間(步驟 3 計(jì)算的結(jié)果)。
5. 如果因?yàn)槟承┰?，獲取鎖失敗(沒有在至少 N/2+1 個(gè)Redis實(shí)例取到鎖或者取鎖時(shí)間已經(jīng)超過了有效時(shí)間)，客戶端應(yīng)該在所有的 Redis 實(shí)例上進(jìn)行解鎖(即便某些 Redis 實(shí)例根本就沒有加鎖成功)。

通過上面的步驟我們可以知道，只要大多數(shù)的節(jié)點(diǎn)可以正常工作，就可以保證 Redlock 的正常工作。這樣就可以解決前面單點(diǎn) Redis 的情況下我們討論的節(jié)點(diǎn)掛掉，由于異步通信，導(dǎo)致鎖失效的問題。

但是，還是不能解決故障重啟后帶來的鎖的安全性的問題。你想一下下面這個(gè)場景：

我們一共有 A、B、C 這三個(gè)節(jié)點(diǎn)。

1. 客戶端 1 在 A，B 上加鎖成功。C 上加鎖失敗。
2. 這時(shí)節(jié)點(diǎn) B 崩潰重啟了，但是由于持久化策略導(dǎo)致客戶端 1 在 B 上的鎖沒有持久化下來。
3. 客戶端 2 發(fā)起申請同一把鎖的操作，在 B，C 上加鎖成功。
4. 這個(gè)時(shí)候就又出現(xiàn)同一把鎖，同時(shí)被客戶端 1 和客戶端 2 所持有了。

(接下來又得說一說Redis的持久化策略了，全是知識點(diǎn)啊，朋友們)

比如，Redis 的 AOF 持久化方式默認(rèn)情況下是每秒寫一次磁盤，即 fsync 操作，因此最壞的情況下可能丟失 1 秒的數(shù)據(jù)。

當(dāng)然，你也可以設(shè)置成每次修改數(shù)據(jù)都進(jìn)行 fsync 操作(fsync=always)，但這會(huì)嚴(yán)重降低 Redis 的性能，違反了它的設(shè)計(jì)理念。(我也沒見過這樣用的，可能還是見的太少了吧。)

而且，你以為執(zhí)行了 fsync 就不會(huì)丟失數(shù)據(jù)了?天真，真實(shí)的系統(tǒng)環(huán)境是復(fù)雜的，這都已經(jīng)脫離 Redis 的范疇了。上升到服務(wù)器、系統(tǒng)問題了。

所以，根據(jù)墨菲定律，上面舉的例子：由于節(jié)點(diǎn)重啟引發(fā)的鎖失效問題，總是有可能出現(xiàn)的。

為了解決這一問題，Redis 的作者又提出了延遲重啟(delayed restarts)的概念。

意思就是說，一個(gè)節(jié)點(diǎn)崩潰后，不要立即重啟它，而是等待一定的時(shí)間后再重啟。等待的時(shí)間應(yīng)該大于鎖的過期時(shí)間(TTL)。這樣做的目的是保證這個(gè)節(jié)點(diǎn)在重啟前所參與的鎖都過期。相當(dāng)于把以前的帳勾銷之后才能參與后面的加鎖操作。

但是有個(gè)問題就是：在等待的時(shí)間內(nèi)，這個(gè)節(jié)點(diǎn)是不對外工作的。那么如果大多數(shù)節(jié)點(diǎn)都掛了，進(jìn)入了等待。就會(huì)導(dǎo)致系統(tǒng)的不可用，因?yàn)橄到y(tǒng)在TTL時(shí)間內(nèi)任何鎖都將無法加鎖成功。

Redlock 算法還有一個(gè)需要注意的點(diǎn)是它的釋放鎖操作。

釋放鎖的時(shí)候是要向所有節(jié)點(diǎn)發(fā)起釋放鎖的操作的。這樣做的目的是為了解決有可能在加鎖階段，這個(gè)節(jié)點(diǎn)收到加鎖請求了，也set成功了，但是由于返回給客戶端的響應(yīng)包丟了，導(dǎo)致客戶端以為沒有加鎖成功。所有，釋放鎖的時(shí)候要向所有節(jié)點(diǎn)發(fā)起釋放鎖的操作。

你可以覺得這不是常規(guī)操作嗎?

有的細(xì)節(jié)就是這樣，說出來后覺得不過如此，但是有可能自己就是想不到這個(gè)點(diǎn)，導(dǎo)致問題的出現(xiàn)，所以我們才會(huì)說：細(xì)節(jié)，魔鬼都在細(xì)節(jié)里。

好了，簡介大概就說到這里，有興趣的朋友可以再去看看官網(wǎng)，補(bǔ)充一下。

中文：http://redis.cn/topics/distlock.html

英文：https://redis.io/topics/distlock

好了，經(jīng)過這么長，這么長的鋪墊，我們終于可以進(jìn)入到神仙打架環(huán)節(jié)。

神仙打架

神仙一：Redis 的作者 antirez 。有的朋友對英文名字不太敏感，所以后面我就叫他卷發(fā)哥吧。

神仙二：分布式領(lǐng)域?qū)＜?Martin Kleppmann，我們叫他長發(fā)哥吧。

看完上面兩位神仙的照片，再看看我為了寫這篇文章又日漸稀少的頭發(fā)，我忍不住哭出聲來?？赡苤挥薪o我點(diǎn)贊，才能平復(fù)我的心情吧。

卷發(fā)哥在官網(wǎng)介紹 Redlock 頁面的最后寫到：如果你也是使用分布式系統(tǒng)的人員，你的觀點(diǎn)和意見非常重要，歡迎和我們討論。

于是，“求錘得錘”!這一錘，錘出了眾多的吃瓜網(wǎng)友，其中不乏在相關(guān)領(lǐng)域的專業(yè)人士。

長發(fā)哥出錘

故事得從 2016年2月8號 長發(fā)哥發(fā)布的一篇文章《How to do distributed locking》說起：

文章地址：

http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

這一部分直接翻譯過來就是：

作為本書(《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)》)研究的一部分，我在Redis網(wǎng)站上 看到了一種稱為Redlock的算法。該算法聲稱在Redis實(shí)現(xiàn)容錯(cuò)的分布式鎖(或更確切地說， 租約)，并且該頁面要求來自分布式系統(tǒng)人員的反饋。這個(gè)算法讓我產(chǎn)生了一些思考，因此我花了一些時(shí)間寫了我的這篇文章。

由于Redlock已經(jīng)有10多個(gè)獨(dú)立的實(shí)現(xiàn)，而且我們不知道誰已經(jīng)在依賴此算法，因此我認(rèn)為值得公開分享我的筆記。我不會(huì)討論Redis的其他方面，其中一些已經(jīng)在其他地方受到了批評 。

你看這個(gè)文章，開頭就是火藥味十足：你說要反饋，那我就給你反饋。而且你這個(gè)東西有其他問題，我也就不說了。(其實(shí)作者在這篇文章中也說了，他很喜歡并且也在使用 Redis，只是他覺得這個(gè) Redlock 算法是不嚴(yán)謹(jǐn)?shù)?

長發(fā)哥主要圍繞了下面的這張圖進(jìn)行了展開：

要是一眼沒看明白，我再給你一個(gè)中文版的，來自長發(fā)哥于2017年出版的書《數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計(jì)》：

可以看到上面的圖片中提到了申請租約、租約到期的關(guān)鍵詞，租約其實(shí)就是可以理解為帶超時(shí)時(shí)間的鎖。

而在書中，這張圖片的下面寫的描述這樣的，你咂摸咂摸：

拿 HBase 舉例，其設(shè)計(jì)的目標(biāo)是確保存儲系統(tǒng)的文件一次只能由一個(gè)客戶端訪問，如果多個(gè)客戶端試圖同時(shí)寫入該文件，文件就會(huì)被破壞。那么上面的圖片解釋起來就是：

1. 客戶端 1 先去申請鎖，并且成功獲取到鎖。之后客戶端進(jìn)行了長時(shí)間的 GC 導(dǎo)致了 STW 的情況。
2. 在 STW 期間，客戶端 1 獲取的鎖的超時(shí)時(shí)間到了，鎖也就失效了。
3. 由于客戶端 1 的鎖已經(jīng)過期失效了，所以客戶端 2 去申請鎖就可以成功獲得鎖。
4. 客戶端 2 開始寫文件，并完成文件的寫入。
5. 客戶端 1 從 STW 中恢復(fù)過來，他并不知道自己的鎖過期了，還是會(huì)繼續(xù)執(zhí)行文件寫入操作，導(dǎo)致客戶端 2 寫入的文件被破壞。而且可以看到，它沒有滿足鎖在任意時(shí)刻只有一個(gè)客戶端持有的原則，即沒有滿足互斥性。

書里面沒有明說，但是你品一品，這里的鎖服務(wù)難道不是在說 Redis?

有的朋友就會(huì)說了，那客戶端 1 寫入文件的時(shí)候，再判斷一下自己的鎖有沒有過期不就可以了嗎?

你可真是個(gè)小機(jī)靈鬼呢，那我問你，GC 可能是發(fā)生在任何時(shí)間的，萬一 GC 發(fā)生在判斷之后呢?

你繼續(xù)懟我，如果客戶端使用的是沒有 GC 的語言呢?

GC 不是導(dǎo)致線程暫停的唯一原因啊，朋友們。發(fā)生這種情況的原因有很多的，你看看長發(fā)哥書里舉的例子：

上面的內(nèi)容總結(jié)起來，就是就算鎖服務(wù)是正常的，但是由于鎖是有持有時(shí)間的，由于客戶端阻塞、長時(shí)間的 GC 或者網(wǎng)絡(luò)原因，導(dǎo)致共享資源被一個(gè)以上的客戶端同時(shí)訪問了。

其實(shí)上面長發(fā)哥在書里直接說了：這是不正確的實(shí)現(xiàn)。

你多品一品，上面的圖是不是有點(diǎn)像由于 Redis 鎖的過期時(shí)間設(shè)置的不合理，導(dǎo)致前一個(gè)任務(wù)還沒執(zhí)行完成，但是鎖的時(shí)間到期了，后一個(gè)任務(wù)也申請到了鎖。

對于這種場景，Redission 其實(shí)有自己的看門狗機(jī)制。但是不在這次 Redlock 的討論范圍內(nèi)，所以這里就不描述了。

長發(fā)哥提出的解決方案是什么呢?

他稱為：fencing token。

長發(fā)哥認(rèn)為使用鎖和租約機(jī)制來保護(hù)資源的并發(fā)訪問時(shí)，必須確保因?yàn)楫惓Ｔ颍瑢?dǎo)致鎖過期的那個(gè)節(jié)點(diǎn)不能影響其他正常的部分，要實(shí)現(xiàn)這一目標(biāo)，可以采用一直相當(dāng)簡單的 fencing(柵欄)。

假設(shè)每次鎖服務(wù)在授予鎖或者租約時(shí)，還會(huì)同時(shí)返回一個(gè) fencing 令牌，該令牌每次授予都會(huì)遞增。

然后，要求客戶端每次向存儲系統(tǒng)發(fā)送寫請求時(shí)，都必須包含所持有的 fencing 令牌。存儲系統(tǒng)需要對令牌進(jìn)行校驗(yàn)，發(fā)現(xiàn)如果已經(jīng)處理過更高令牌的請求，則拒絕執(zhí)行該請求。

比如下面的圖片：

1. 客戶端 1 獲得一個(gè)具有超時(shí)時(shí)間的鎖的同時(shí)得到了令牌號 33，但隨后陷入了一個(gè)長時(shí)間的暫停直到鎖到期。
2. 這時(shí)客戶端2已經(jīng)獲得了鎖和令牌號 34 ，然后發(fā)送寫請求(以及令牌號 34 )到存儲服務(wù)。
3. 接下來客戶端 1 恢復(fù)過來，并以令牌號 33 來嘗試寫入，存儲服務(wù)器由于記錄了最近已經(jīng)完成了更高令牌號(34 )，因此拒絕令牌號 33 的寫請求。

這種版本號的機(jī)制，讓我不禁想起了 Zookeeper。當(dāng)使用 ZK 做鎖服務(wù)時(shí)，可以用事務(wù)標(biāo)識 zxid 或節(jié)點(diǎn)版本 cversion 來充當(dāng) fencing 令牌，這兩個(gè)都可以滿足單調(diào)遞增的要求。

在長發(fā)哥的這種機(jī)制中，實(shí)際上就是要求資源本身必須主動(dòng)檢查請求所持令牌信息，如果發(fā)現(xiàn)已經(jīng)處理過更高令牌的請求，要拒絕持有低令牌的所有寫請求。

但是，不是所有的資源都是數(shù)據(jù)庫里面的數(shù)據(jù)，我們可以通過版本號去支持額外的令牌檢查的，那么對于不支持額外的令牌檢查資源，我們也可以借助這種思想繞過這個(gè)限制，比如對于訪問文件存儲服務(wù)的情況，我們可以將令牌嵌入到文件名中。

總之，為了避免在鎖保護(hù)之外發(fā)生請求處理，需要進(jìn)行額外的檢查機(jī)制。

長發(fā)哥在書中也說到了：在服務(wù)端檢查令牌可能看起來有點(diǎn)復(fù)雜，但是這其實(shí)是推薦的正確的做法：系統(tǒng)服務(wù)不能假定所有的客戶端都表現(xiàn)的符合預(yù)期。從安全角度講，服務(wù)端必須防范這種來自客戶端的濫用。

這個(gè)就類似于我們作為后端開發(fā)人員，也不能相信來自前端或者其他接口過來的數(shù)據(jù)，必須對其進(jìn)行校驗(yàn)。

到這里長發(fā)哥鋪墊完成了，開始轉(zhuǎn)頭指向 RedLock，他認(rèn)為 Redlock 是一個(gè)嚴(yán)重依賴系統(tǒng)時(shí)鐘的分布式鎖。

他舉了一個(gè)例子：

1. 客戶端 1 從 Redis 節(jié)點(diǎn) A, B, C 成功獲取了鎖。由于網(wǎng)絡(luò)問題，無法訪問 D 和 E。
2. 節(jié)點(diǎn) C 上的時(shí)鐘發(fā)生了向前跳躍，導(dǎo)致它上面維護(hù)的鎖過期了。
3. 客戶端 2 從 Redis 節(jié)點(diǎn) C, D, E 成功獲取了同一個(gè)資源的鎖。由于網(wǎng)絡(luò)問題，無法訪問 A 和 B。
4. 現(xiàn)在，客戶端 1 和客戶端 2 都認(rèn)為自己持有了鎖。

這樣的場景是可能出現(xiàn)的，因?yàn)?Redlock 嚴(yán)重依賴系統(tǒng)時(shí)鐘，所以一旦系統(tǒng)的時(shí)間變得不準(zhǔn)確了，那么該算法的安全性也就得不到保障了。

長發(fā)哥舉這個(gè)例子其實(shí)是為了輔佐他前面提出的觀點(diǎn)：一個(gè)好的分布式算法應(yīng)該是基于異步模型的，算法的安全性不應(yīng)該依賴與任何記時(shí)假設(shè)，就是不能把時(shí)間作為安全保障的。在異步模型中，程序暫停、消息在網(wǎng)絡(luò)中延遲甚至丟失、系統(tǒng)時(shí)間錯(cuò)誤這些因素都不應(yīng)該影響它的安全性，只能影響到它的活性。

用大白話說，就是在極其極端的情況下，分布式系統(tǒng)頂天了也就是在有限的時(shí)間內(nèi)不能給出結(jié)果而已，而不能給出一個(gè)錯(cuò)誤的結(jié)果。

這樣的算法實(shí)際上是存在的，比如 Paxos、Raft。很明顯，按照這個(gè)標(biāo)準(zhǔn)， Redlock 的安全級別是不夠的。

而對于卷發(fā)哥提出的延遲啟動(dòng)方案，長發(fā)哥還是一棒子打死：你延遲啟動(dòng)咋的?延遲啟動(dòng)還不是依賴于合理準(zhǔn)確的時(shí)間度量。

可能是長發(fā)哥覺得舉這個(gè)時(shí)鐘跳躍的例子不夠好的，大家都可能認(rèn)為時(shí)鐘跳躍是不現(xiàn)實(shí)的，因?yàn)閷φ_配置NTP就能擺正時(shí)鐘非常有信心。

在這種情況下，他舉了一個(gè)進(jìn)程暫?？赡軐?dǎo)致算法失敗的示例：

1. 客戶端 1 向 Redis 節(jié)點(diǎn) A, B, C, D, E 發(fā)起鎖請求。
2. 各個(gè) Redis 節(jié)點(diǎn)已經(jīng)把請求結(jié)果返回給了客戶端 1，但客戶端 1 在收到請求結(jié)果之前進(jìn)入了長時(shí)間的 GC 階段。
3. 長時(shí)間的 GC，導(dǎo)致在所有的 Redis 節(jié)點(diǎn)上，鎖過期了。
4. 客戶端 2 在 A, B, C, D, E 上申請并獲取到了鎖。
5. 客戶端 1 從 GC 階段中恢復(fù)，收到了前面第 2 步來自各個(gè) Redis 節(jié)點(diǎn)的請求結(jié)果。客戶端 1 認(rèn)為自己成功獲取到了鎖。
6. 客戶端 1 和客戶端 2 現(xiàn)在都認(rèn)為自己持有了鎖。

其實(shí)只要十分清楚 Redlock 的加鎖過程，我們就知道，這種情況其實(shí)對于 Redlock 是沒有影響的，因?yàn)樵诘?5 步，客戶端 1 從 GC 階段中恢復(fù)過來以后，在 Redlock 算法中，(我們前面 Redlock 簡介的時(shí)候提到的第四步)如果取到了鎖，key 的真正有效時(shí)間等于有效時(shí)間減去獲取鎖所使用的時(shí)間。

所以客戶端1通過這個(gè)檢查發(fā)現(xiàn)鎖已經(jīng)過期了，不會(huì)再認(rèn)為自己成功獲取到鎖了。

而隨后卷發(fā)哥的回?fù)糁幸蔡岬搅诉@點(diǎn)。

但是，細(xì)細(xì)想來，我覺得長發(fā)哥的意圖不在于此。拋開上面的問題來講，他更想突出的是，一個(gè)鎖在客戶端拿到后，還沒使用就過期了，這是不好的。從客戶端的角度來看，就是這玩意不靠譜啊，你給我一把鎖，我還沒用呢，你就過期了?

除了上面說的這些點(diǎn)外，長發(fā)哥還提出了一個(gè)算是自己的經(jīng)驗(yàn)之談吧：

我們獲取鎖的用途是什么?

在他看來不外乎兩個(gè)方面，效率和正確性。他分別描述如下：

如果是為了效率，那么就是要協(xié)調(diào)各個(gè)客戶端，避免他們做重復(fù)的工作。這種場景下，即使鎖偶爾失效了，只是可能出現(xiàn)兩個(gè)客戶端完成了同樣的工作，其結(jié)果是成本略有增加(您最終向 AWS 支付的費(fèi)用比原本多5美分)，或者帶來不便(例如，用戶最終兩次收到相同的電子郵件通知)。

如果是為了正確性，那么在任何情況下都不允許鎖失效的情況發(fā)生，因?yàn)橐坏┌l(fā)生，就可能意味著數(shù)據(jù)不一致，數(shù)據(jù)丟失，文件損壞，或者其它嚴(yán)重的問題。(比如個(gè)患者注射了兩倍的藥劑)

最后，長發(fā)哥得出的結(jié)論是：neither fish nor fowl(不倫不類)

對于提升效率的場景下，使用分布式鎖，允許鎖的偶爾失效，那么使用單 Redis 節(jié)點(diǎn)的鎖方案就足夠了，簡單而且效率高。用 Redlock 太重。

對于正確性要求高的場景下，它是依賴于時(shí)間的，不是一個(gè)足夠強(qiáng)的算法。Redlock并沒有保住正確性。

那應(yīng)該使用什么技術(shù)呢?

長發(fā)哥認(rèn)為，應(yīng)該考慮類似 Zookeeper 的方案，或者支持事務(wù)的數(shù)據(jù)庫。

卷發(fā)哥回?fù)?/strong>

長發(fā)哥發(fā)出《How to do distributed locking》這篇文章的第二天，卷發(fā)哥就進(jìn)行了回?fù)簦l(fā)布了名為《Is Redlock safe?》的文章。

文章地址：http://antirez.com/news/101

要說大佬不愧是大佬，卷發(fā)哥的回?fù)魲l理清楚，行文流暢。他總結(jié)后認(rèn)為長發(fā)哥覺得 Redlock 不安全主要分為兩個(gè)方面：

1. 帶有自動(dòng)過期功能的分布式鎖，需要一種方法(fencing機(jī)制)來避免客戶端在過期時(shí)間后使用鎖時(shí)出現(xiàn)問題，從而對共享資源進(jìn)行真正的互斥保護(hù)。馬丁說Redlock沒有這種機(jī)制。
2. 馬丁說，無論問題“1”如何解決，該算法本質(zhì)上都是不安全的，因?yàn)樗鼘ο到y(tǒng)模型進(jìn)行了記時(shí)假設(shè)，而這些假設(shè)在實(shí)際系統(tǒng)中是無法保證的。