zookeeper簡介
1、什麼是zookeeper
ZooKeeper 是一個分佈式的,開放源碼的分佈式應用程序協同服務。
ZooKeeper 的設計目標是將那些複雜且容易出錯的分佈式一致性服 務封裝起來,構成一個高效可靠的原語集,並以一系列簡單易用 的接口提供給用戶使用。
2、zookeeper的使用場景
2.1、數據發佈/訂閱,配置中心
1、發佈者將數據發佈到Zookeeper的節點上,供訂閱者進行數據訂閱。
2、Zookeeper採用了推拉相結合的模式,客戶端向服務端註冊自己需要關注的節點,一旦該節點數據發生變更,那麼服務端就會向相應的客戶端推送Watcher事件通知,客戶端接收到此通知後,主動到服務端獲取最新的數據。
2.2、分佈式鎖
1、排它鎖也叫獨佔鎖
① 獲取鎖,在需要獲取排它鎖時,所有客戶端通過調用接口,在/exclusive_lock節點下創建臨時子節點/exclusive_lock/lock。Zookeeper可以保證只有一個客戶端能夠創建成功,沒有成功的客戶端需要註冊/exclusive_lock節點監聽。
② 釋放鎖,當獲取鎖的客戶端宕機或者正常完成業務邏輯都會導致臨時節點的刪除,此時,所有在/exclusive_lock節點上註冊監聽的客戶端都會收到通知,可以重新發起分佈式鎖獲取。
2、讀寫鎖
① 獲取鎖,在需要獲取共享鎖時,所有客戶端都會到/shared_lock下面創建一個臨時順序節點,如果是讀請求,那麼就創建例如/shared_lock/host1-R-00000001的節點,如果是寫請求,那麼就創建例如/shared_lock/host2-W-00000002的節點。
② 判斷讀寫順序
1. 創建完節點後,獲取/shared_lock節點下所有子節點,並對該節點變更註冊監聽。
2. 確定自己的節點序號在所有子節點中的順序。
3. 對於讀請求:若沒有比自己序號小的子節點或所有比自己序號小的子節點都是讀請求,那麼表明自己已經成功獲取到共享鎖,同時開始執行讀取邏輯,若有寫請求,則需要等待。對於寫請求:若自己不是序號最小的子節點,那麼需要等待。
4. 接收到Watcher通知後,重複步驟1。
③ 釋放鎖,其釋放鎖的流程與獨佔鎖一致。
兩種鎖如何避免羊羣效應?
1、獨佔鎖:
2、讀寫鎖呢?
2.2.3、一主多從,master-worker協同
- 使用一個臨時節點/master表示master。master在行使master的職能之前,首先要創建這個znode。如果能 創建成功,開始行使master職能。
- worker通過在/workers下面創建臨時節點來加入集羣
- master會通過watch機制監控/workers下面的worker節點列表來實時獲取worker成員的變化。
2.2.4、kafak如何使用zookeeper
1、master-worker模式
一個Kafka集羣由多個broker組成,這些borker是系統中的worker。Kafka會從這些worker選舉出一個 controller,這個controlle是系統中的master,負責把topic和partition分配給各個broker。
2、Topic註冊
Topic的消息會被分成多個分區並將其分佈在多個Broker上,這些分區信息及與Broker的對應關係也都是由Zookeeper在維護。
3、消費分區與消費者的關係,消息消費位移記錄
同一個消費者組內,每個分區只能有一個消費者進行消費,每條消息只被消費一次,所以消費者和消費分區之間的關係也寫入zookeeper。
zookeeper中的重要概念
數據模型
ZooKeeper 使用文件系統模型,Datatree。Datatree 的每個節點叫作 znode。每個節點都可以保存數據。每個節點都有一個版本 (version)。版本從 0 開始計數。
基於版本號的條件更新
znode節點
- 持久性的 znode (PERSISTENT): ZooKeeper 宕機,或者 client 宕機,這個 znode 一旦創建就不會丟失。
- 臨時性的 znode (EPHEMERAL): ZooKeeper 宕機了,或者 client 在指定的 timeout 時間內沒有連接 server ,都會被認爲丟失。
znode 節點也可以是順序性的。每一個順序性的 znode 關聯一個唯一的單調遞增整數。這個單調遞增整 數是 znode 名字的後綴。 - 持久順序性的 znode(PERSISTENT_SEQUENTIAL): znode 除了具備持久性 znode 的特點之外,znode 的名字具備順序性。
- 臨時順序性的 znode(EPHEMERAL_SEQUENTIAL): znode 除了具備臨時性 znode 的特點之外,znode 的名字具備順序性。
standalone 模式和 quorum模式
quorum模式要求至少3個節點
其中2181是默認客戶端服務端口,3333是quorum之間的通信,3334是用於leader選舉的端口。
服務器節點角色與區別
事務日誌和快照
zookeeper數據一致性
1、CAP理論下,zookeeper是如何工作的。
2、zookeeper的數據一致性
• 可線性化(Linearizable)寫入:先到達 leader 的寫請求會被先處理,leader 決定寫請求的執 行順序。
• 客戶端FIFO順序:來自給定客戶端的請求按照發送順序執行。
3、ZAB協議
1、2PC,3PC,Paxos,Raft算法
2、ZAB(ZooKeeper Atomic Broadcast)協議
- Leader發送PROPOSAL給集羣中所有的節點。
- 節點在收到PROPOSAL之後,把PROPOSAL落盤,發送一個ACK給Leader。
- Leader在收到大多數節點的ACK之後,發送COMMIT給集羣中所有的節點。
Leader選舉
1、Vote投票包含的信息:sid(服務器ID),zxid(事務ID),epoch(leader週期)
2、投票過程
一個ZooKeeper節點通過向所有的節點發送vote開始選舉
一個節點在接收到vote之後如果發現接收到的投票新,就把自己的投票更新成最新的投票,並把vote發送給所有的ZooKeeper節點。否則的話,什麼也不用做。
如何判斷一個投票是新的?
一個3節點集羣選舉一個leader的時序圖:
3、腦裂-長時間的消息發送延遲導致選舉出兩個leader