兩大類分布式鎖：類自旋式的分布式鎖 mysql redis ； 事件通知后續(xù)鎖的變化 zookeeper etcd
redis：單線程的串行的 本地方法setnx+timeout
發(fā)布訂閱模式，阻塞隊列+超時
redis集群
redlock
zookeeper：
zookeeper集群
Zookeeper集群是一個主從集群，它一般是由一個Leader(領(lǐng)導(dǎo)者)和多個Follower(跟隨者)組成。此外，針對訪問量比較大的Zookeeper集群，還可新增Observer(觀察者)。Zookeeper集群中的三種角色各司其職，共同完成分布式協(xié)調(diào)服務(wù)。下面我們針對Zookeeper集群中的三種角色進行簡單介紹。
1.Leader
它是Zookeeper集群工作的核心，也是事務(wù)性請求(寫操作)的唯一調(diào)度和處理者，它保證集群事務(wù)處理的順序性，同時負責(zé)進行投票的發(fā)起和決議，以及更新系統(tǒng)狀態(tài)。
2.Follower
它負責(zé)處理客戶端的非事務(wù)(讀操作)請求，如果接收到客戶端發(fā)來的事務(wù)性請求，則會轉(zhuǎn)發(fā)給Leader，讓Leader進行處理，同時還負責(zé)在Leader選舉過程中參與投票。
3.Observer
它負責(zé)觀察Zookeeper集群的最新狀態(tài)的變化
zookeeper
jvm鎖： cas自旋鎖
ZooKeeper和Reids做分布式鎖的區(qū)別?
Reids:
- Redis只保證最終一致性，副本間的數(shù)據(jù)復(fù)制是異步進行(Set是寫，Get是讀，Reids集群一 般是讀寫分離架構(gòu)，存在主從同步延遲情況)，主從切換之后可能有部分數(shù)據(jù)沒有復(fù)制過去可能會「丟失鎖」 情況，故強一致性要求的業(yè)務(wù)不推薦使用Reids,推薦使用zk。
- Redis集群各方法的響應(yīng)時間均為最低。隨著并發(fā)量和業(yè)務(wù)數(shù)量的提升其響應(yīng)時間會有明顯上升(公網(wǎng)集群影響因素偏大)，但是極限qps可以達到最大且基本無異常
ZooKeeper
- 使用ZooKeeper集群，鎖原理是使用ZooKeeper的臨時順序節(jié)點，臨時順序節(jié)點的生命周期在Client與集群的Session結(jié)束時結(jié)束。因此如果某個Client節(jié)點存在網(wǎng)絡(luò)問題，與ZooKeeper集群斷開連接 ，Session超時同樣會導(dǎo)致鎖被錯誤的釋放(導(dǎo)致被其他線程錯誤地持有) , 因此ZooKeeper也無法保證完全- -致。
- ZK具有較好的穩(wěn)定性;響應(yīng)時間抖動很小，沒有出現(xiàn)異常。但是隨著并發(fā)量和業(yè)務(wù)數(shù)量的提升其響應(yīng)時間和qps會明顯下降。
總結(jié):
- Zookeeper每次進行鎖操作前都要創(chuàng)建若干節(jié)點，完成后要釋放節(jié)點，會浪費很多時間;
- 而Redis只是簡單的數(shù)據(jù)操作，沒有這個問題。
