服務註冊中心zookeeper

一、背景

場景：1、服務位址如何維護；

-- 服務啟動的時候，註冊到乙個服務中；key,服務名 value 若干個http位址；

2、如何對目標服務負載均衡

-- 從註冊服務中拿到目標服務位址列表，通過輪詢或者隨機演算法得到乙個位址；

3、服務的動態感知（目標服務可能宕機）

-- 心跳機制；註冊中心定期和客戶端心跳，如果沒有返回，就認為掛掉，註冊中心再push或者客戶端pull位址列表；

二、實現框架 zookeeper(其他的有eureka/consul)

zookeeper的背景：

1、zk真正用意是分布式協調元件；（基於google chubby 不是開源的，解決分布式一致性問題，分布式鎖；幾個客戶端去 chubby申請乙個key,第乙個客戶端成功得到就是master,原理類似分布式鎖）；後來雅虎實現類似chubby的功能zookeeper，後來捐獻給apache;zookeeper集群，帶中心節點的集群（kafka，es），不帶中心節點的集群（redis）

定義一種協議（paxos）

2、資料結構，樹形結構，每個節點進行編號；

zookeeper的設計

1、解決單點問題，集群 master/salve leader/follower/observer

2、資料同步（過半的節點成功，才進行資料提交 observer不參與投票）

3、leader選舉演算法（一致性演算法）zab協議 observer不參與投票

4、2pc協議

zookeeper基本特性

節點就是乙個資料node(key-value)

1、建立節點順序節點持久化臨時節點同一級別不能重複臨時節點不能存在子節點 2、刪除節點 3、修改節點

4、watcher 通過對get -w 進行監聽，處理一次，就不再監聽了，配合臨時節點，可以做動態感知；

5、master節點 >>zookeeper節點，create lock後，使用完後，會釋放該鏈結（臨時節點的特性），這樣剩下的節點來搶鎖，會帶來驚群效應；可以通過對客戶端節點進行順序儲存，每個節點監控前乙個節點；

6、acl

操作許可權，read=1 write=2...

schema 許可權模式 ip/digest/world/super

7、watcher 機制

針對資料節點進行監聽，然後通知客戶端；zookeeper new的時候就可以增加watch機制；

原理：客戶端通過getdata,或者 exists,或者getchildren註冊通知事件到 outgoingqueue佇列中,然後sendthread 將佇列中的資料傳送到 zk server （nioservercnxnfactory）,註冊watch事件，

zookeeper的應用

1、提供服務註冊和發現；利用節點特性持久和臨時節點特性；

2、給別的應用程式提供master選舉；

會建立一組臨時有序節點，最小的節點就是master，後面的監聽前一節點；

場景：多節點的定時排程；

zookeeper本身也是分leader-follower的，基於zab協議；事務請求只能是leader節點；

zab協議：崩潰恢復，已經被丟棄的資訊需要放棄，那就選舉zxid是最大的；原子廣播；重新選舉後，epoch會增加；

3、提供實現分布式鎖；

會建立一組臨時有序節點，最小的節點獲得鎖，後面的監聽前一節點；interprocessmutx;和master選舉乙個原理，都是利用臨時有序的最小節點；

zookeeper的一致性

順序一致性：在zk伺服器上時間上值一致的，通過【佇列、zxid】實現順序一致性；

lead選舉

myid(sid)/epoch（時鐘週期）/選舉狀態（looking|following|leading|observing）

選舉流程：單個節點先選自己，然後把訊息廣播其他節點，各自進行比較，按照規則（先去比較epoch;zxid最大為leader;myid最大為leader）進行比較；進行下一輪（epoch會+1）的投票，再按少數服從多數的原則，選出leader;

quorumpeermain啟動類，暴露2181埠後；開始leade選舉；.fastleaderelection負責leader邏輯的判斷;quorumcnxmanager 負責通訊；

** 的執行流程：

缺點：選舉的時候，服務不可用；寫多讀少的場景 leader有效能瓶頸；

服務註冊中心zookeeper

註冊中心Zookeeper

基於zookeeper的服務註冊中心

Zookeeper註冊中心的搭建

服務註冊中心zookeeper

註冊中心Zookeeper

基於zookeeper的服務註冊中心

Zookeeper註冊中心的搭建

相關推薦