前言
鎖我想不需要我過多的去說，大家都知道是怎麼一回事了吧？
在多線程環境下，由于上下文的切換，資料可能出現不一緻的情況或者資料被污染，我們需要保證資料安全，是以想到了加鎖。
所謂的加鎖機制呢，就是當一個線程通路該類的某個資料時，進行保護，其他線程不能進行通路，直到該線程讀取完，其他線程才可使用。
還記得我之前說過Redis在分布式的情況下，需要對存在并發競争的資料進行加鎖，你們十分費解，Redis是單線程的嘛？為啥還要加鎖呢？
看來還是年輕啊，你說的不需要加鎖的情況是這樣的：
單個服務去通路Redis的時候，确實因為Redis本身單線程的原因是不用考慮線程安全的，但是，現在有哪個公司還是單機的呀？肯定都是分布式叢集了嘛。
你看下這樣的場景是不是就有問題了：
你們經常不是說秒殺嘛，拿到庫存判斷，那老婆告訴你分布式情況就是會出問題的。
我們為了減少DB的壓力，把庫存預熱到了KV，現在KV的庫存是1。
服務A去Redis查詢到庫存發現是1，那說明我能搶到這個商品對不對，那我就準備減一了，但是還沒減。
同時服務B也去拿發現也是1，那我也搶到了呀，那我也減。
C同理。
等所有的服務都判斷完了，你發現诶，怎麼變成-2了，超賣了呀，這下完了。
是不是發現問題了，這就需要分布式鎖的介入了，我會分三個章節去分别介紹分布式鎖的三種實作方式（Zookeeper，Redis，MySQL），說出他們的優缺點，以及一般大廠的實踐場景。
正常線程程序同步的機制有哪些？
互斥：互斥的機制，保證同一時間隻有一個線程可以操作共享資源 synchronized，Lock等。
臨界值：讓多線程串行話去通路資源
事件通知：通過事件的通知去保證大家都有序通路共享資源
信号量：多個任務同時通路，同時限制數量，比如發令槍CDL，Semaphore等
那分布式鎖你了解過有哪些麼？
分布式鎖實作主要以Zookeeper（以下簡稱zk）、Redis、MySQL這三種為主。
那先跟我聊一下zk吧，你能說一下他常見的使用場景麼？
他主要的應用場景有以下幾個：
服務注冊與訂閱（共用節點）
分布式通知（監聽znode）
服務命名（znode特性）
資料訂閱、釋出（watcher）
分布式鎖（臨時節點）
zk是啥？
他是個資料庫，檔案存儲系統，并且有監聽通知機制（觀察者模式）
存檔案系統，他存了什麼？
節點
zk的節點類型有4大類
持久化節點（zk斷開節點還在）
持久化順序編号目錄節點
臨時目錄節點（用戶端斷開後節點就删除了）
臨時目錄編号目錄節點
節點名稱都是唯一的。
節點怎麼建立？
我特麼，這樣問的麼？可是我面試隻看了分布式鎖，我得好好想想！！！
還好我之前在自己的伺服器搭建了一個zk的叢集，我剛好跟大家回憶一波。
那臨時節點呢？
臨時節點就建立成功了，如果我斷開這次連結，這個節點自然就消失了，這是我的一個zk管理工具，目錄可能清晰點。
如果建立順序節點呢？
臨時順序節點呢？
我想聰明的夥伴都會搶答了
我退出後，重新連接配接，發現剛才建立的所有臨時節點都沒了。
開篇示範這麼多呢，我就是想給大家看到的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的叢集也是高可用的，隻要半數以上的或者，就可以對外提供服務了。
你知道的越多，你不知道的越多