面試官：怎麼用Zk（Zookeeper）實現實現分佈式鎖呀？

點贊再看，養成習慣，微信搜索【三太子敖丙】關注這個互聯網苟且偷生的工具人。

本文 GitHub github.com/JavaFamily 已收錄，有一線大廠面試完整考點、資料以及個人系列文章。

前言

鎖我想不須要我過多的去說，你們都知道是怎麼一回事了吧？

在多線程環境下，因爲上下文的切換，數據可能出現不一致的狀況或者數據被污染，咱們須要保證數據安全，因此想到了加鎖。

所謂的加鎖機制呢，就是當一個線程訪問該類的某個數據時，進行保護，其餘線程不能進行訪問，直到該線程讀取完，其餘線程纔可以使用。

還記得我以前說過Redis在分佈式的狀況下，須要對存在併發競爭的數據進行加鎖，大家十分費解，Redis是單線程的嘛？爲啥還要加鎖呢？

看來仍是年輕啊，你說的不須要加鎖的狀況是這樣的：

單個服務去訪問Redis的時候，確實由於Redis自己單線程的緣由是不用考慮線程安全的，可是，如今有哪一個公司仍是單機的呀？確定都是分佈式集羣了嘛。

你看下這樣的場景是否是就有問題了：

大家常常不是說秒殺嘛，拿到庫存判斷，那老婆告訴你分佈式狀況就是會出問題的。

咱們爲了減小DB的壓力，把庫存預熱到了KV，如今KV的庫存是1。

1. 服務A去Redis查詢到庫存發現是1，那說明我能搶到這個商品對不對，那我就準備減一了，可是還沒減。
2. 同時服務B也去拿發現也是1，那我也搶到了呀，那我也減。
3. C同理。
4. 等全部的服務都判斷完了，你發現誒，怎麼變成-2了，超賣了呀，這下完了。

是否是發現問題了，這就須要分佈式鎖的介入了，我會分三個章節去分別介紹分佈式鎖的三種實現方式（Zookeeper，Redis，MySQL），說出他們的優缺點，以及通常大廠的實踐場景。

正文

一個騷裏騷氣的面試官啥也沒拿的就走了進來，你一看，這不是你老婆嘛，你正準備叫他的時候，發現他一臉嚴肅，死鬼還裝嚴肅，確定會給我放水的吧。

B站搜：三太子敖丙

咳咳，咱們啥也不說了，開始今天的面試吧。

正常線程進程同步的機制有哪些？

• 互斥：互斥的機制，保證同一時間只有一個線程能夠操做共享資源 synchronized，Lock等。
• 臨界值：讓多線程串行話去訪問資源
• 事件通知：經過事件的通知去保證你們都有序訪問共享資源
• 信號量：多個任務同時訪問，同時限制數量，好比發令槍CDL，Semaphore等

那分佈式鎖你瞭解過有哪些麼？

分佈式鎖實現主要以Zookeeper（如下簡稱zk）、Redis、MySQL這三種爲主。

那先跟我聊一下zk吧，你能說一下他常見的使用場景麼？

他主要的應用場景有如下幾個：

• 服務註冊與訂閱（共用節點）
• 分佈式通知（監聽znode）
• 服務命名（znode特性）
• 數據訂閱、發佈（watcher）
• 分佈式鎖（臨時節點）

zk是啥？

他是個數據庫，文件存儲系統，而且有監聽通知機制（觀察者模式）

存文件系統，他存了什麼？

節點

zk的節點類型有4大類

• 持久化節點（zk斷開節點還在）

• 持久化順序編號目錄節點

• 臨時目錄節點（客戶端斷開後節點就刪除了）

• 臨時目錄編號目錄節點

節點名稱都是惟一的。

節點怎麼建立？

我特麼，這樣問的麼？但是我面試只看了分佈式鎖，我得好好想一想！！！

還好我以前在本身的服務器搭建了一個zk的集羣，我恰好跟你們回憶一波。

create /test laogong // 建立永久節點
複製代碼

那臨時節點呢？

create -e /test laogong // 建立臨時節點
複製代碼

臨時節點就建立成功了，若是我斷開此次連接，這個節點天然就消失了，這是個人一個zk管理工具，目錄可能清晰點。

若是建立順序節點呢？

create -s /test // 建立順序節點
複製代碼

臨時順序節點呢？

我想聰明的夥伴都會搶答了

create -e -s /test  // 建立臨時順序節點
複製代碼

我退出後，從新鏈接，發現剛纔建立的全部臨時節點都沒了。

開篇演示這麼多呢，我就是想給你們看到的zk大概的一個操做流程和數據結構，中間涉及的搭建以及其餘的技能我就不說了，咱們重點聊一下他在分佈式鎖中的實現。

zk就是基於節點去實現各類分佈式鎖的。

就拿開頭的場景來講，zk應該怎麼去保證分佈式狀況下的線程安全呢？併發競爭他是怎麼控制的呢？

爲了模擬併發競爭這樣一個狀況，我寫了點僞代碼，你們能夠先看看

我定義了一個庫存inventory值爲1，還用到了一個CountDownLatch發令槍，等10個線程都就緒了一塊兒去扣減庫存。

是否是就像10臺機器一塊兒去拿到庫存，而後扣減庫存了？

全部機器一塊兒去拿，發現都是1，那你們都認爲是本身搶到了，都作了減一的操做，可是等全部人都執行完，再去set值的時候，發現其實已經超賣了，我打印出來給你們看看。

image-20200406143556640

是吧，這還不是超賣一個兩個的問題，超賣7個都有，代碼裏面明明判斷了庫存大於0纔去減的，怎麼回事開頭我說明了。

那怎麼解決這個問題？

sync，lock也只能保證你當前機器線程安全，這樣分佈式訪問仍是有問題。

上面跟你們提到的zk的節點就能夠解決這個問題。

zk節點有個惟一的特性，就是咱們建立過這個節點了，你再建立zk是會報錯的，那咱們就利用一下他的惟一性去實現一下。

怎麼實現呢？

上面不是10個線程嘛？

咱們所有去建立，建立成功的第一個返回true他就能夠繼續下面的扣減庫存操做，後續的節點訪問就會所有報錯，扣減失敗，咱們把它們丟一個隊列去排隊。

那怎麼釋放鎖呢？

刪除節點咯，刪了再通知其餘的人過來加鎖，依次類推。

咱們實現一下，zk加鎖的場景。

image-20200406151627845

是否是，只有第一個線程能扣減成功，其餘的都失敗了。

可是你發現問題沒有，你加了鎖了，你得釋放啊，你不釋放後面的報錯了就不重試了。

那簡單，刪除鎖就釋放掉了，Lock在finally裏面unLock，如今咱們在finally刪除節點。

加鎖咱們知道建立節點就夠了，可是你得實現一個阻塞的效果呀，那咋搞？

死循環，遞歸不斷去嘗試，直到成功，一個假裝的阻塞效果。

怎麼知道前面的老哥刪除節點了嗯？

監聽節點的刪除事件

可是你發現你這樣作的問題沒？

是的，會出現死鎖。

第一個仔加鎖成功了，在執行代碼的時候，機器宕機了，那節點是否是就不能刪除了？

你要故做沉思，自問自答，時而看看遠方，時而看看面試官，僞裝本身什麼都不知道。

哦我想起來了，建立臨時節點就行了，客戶端鏈接一斷開，別的就能夠監聽到節點的變化了。

嗯還不錯，那你發現還有別的問題沒？

好像這種監聽機制也很差。

怎麼個很差呢？

大家能夠看到，監聽，是全部服務都去監聽一個節點的，節點的釋放也會通知全部的服務器，若是是900個服務器呢？

這對服務器是很大的一個挑戰，一個釋放的消息，就好像一個牧羊犬進入了羊羣，你們都四散而開，隨時可能幹掉機器，會佔用服務資源，網絡帶寬等等。

這就是羊羣效應。

那怎麼解決這個問題？

繼續故做沉思，啊啊啊，好難，個人腦殼。。。。

你TM別裝了好很差？

好的，臨時順序節點，能夠順利解決這個問題。

怎麼實現你先別往下看，先本身想一想。

以前說了所有監聽一個節點問題很大，那咱們就監聽咱們的前一個節點，由於是順序的，很容易找到本身的先後。

和以前監聽一個永久節點的區別就在於，這裏每一個節點只監聽了本身的前一個節點，釋放固然也是一個個釋放下去，就不會出現羊羣效應了。

以上全部代碼我都會開源到個人https://github.com/AobingJava/Thanos其實上面的還有瑕疵，你們能夠去拉下來改一下提交pr，我會看合適的會經過的。

你說了這麼多，挺不錯的，你能說說ZK在分佈式鎖中實踐的一些缺點麼？

Zk性能上可能並無緩存服務那麼高。

由於每次在建立鎖和釋放鎖的過程當中，都要動態建立、銷燬瞬時節點來實現鎖功能。

ZK中建立和刪除節點只能經過Leader服務器來執行，而後將數據同步到全部的Follower機器上。（這裏涉及zk集羣的知識，我就不展開了，之後zk章節跟大家細聊）

還有麼？

使用Zookeeper也有可能帶來併發問題，只是並不常見而已。

因爲網絡抖動，客戶端可ZK集羣的session鏈接斷了，那麼zk覺得客戶端掛了，就會刪除臨時節點，這時候其餘客戶端就能夠獲取到分佈式鎖了。

就可能產生併發問題了，這個問題不常見是由於zk有重試機制，一旦zk集羣檢測不到客戶端的心跳，就會重試，Curator客戶端支持多種重試策略。

屢次重試以後還不行的話纔會刪除臨時節點。

Tip：因此，選擇一個合適的重試策略也比較重要，要在鎖的粒度和併發之間找一個平衡。

有更好的實現麼？

基於Redis的分佈式鎖

能跟我聊聊麼？

我看看了手上的表，今每天色不早了，你全問完了，我怎麼多水幾篇文章呢？

行確實很晚了，那你回家去把家務幹了吧？

我？？？？

=

總結

zk經過臨時節點，解決掉了死鎖的問題，一旦客戶端獲取到鎖以後忽然掛掉（Session鏈接斷開），那麼這個臨時節點就會自動刪除掉，其餘客戶端自動獲取鎖。

zk經過節點排隊監聽的機制，也實現了阻塞的原理，其實就是個遞歸在那無限等待最小節點釋放的過程。

我上面沒實現鎖的可重入，可是也很好實現，能夠帶上線程信息就能夠了，或者機器信息這樣的惟一標識，獲取的時候判斷一下。

zk的集羣也是高可用的，只要半數以上的或者，就能夠對外提供服務了。

這週會寫完Redis和數據庫的分佈式鎖的，大家等好。

我是敖丙，一個在互聯網苟且偷生的工具人。

最好的關係是互相成就，老公們的**「三連」**就是丙丙創做的最大動力，咱們下期見！

注：若是本篇博客有任何錯誤和建議，歡迎老公們留言，老公你快說句話啊！

---

文章持續更新，能夠微信搜索「 三太子敖丙 」第一時間閱讀，回覆【資料】【面試】【簡歷】有我準備的一線大廠面試資料和簡歷模板，本文 GitHub github.com/JavaFamily 已經收錄，有大廠面試完整考點，歡迎Star。

你知道的越多，你不知道的越多