管動物園的家伙

Zookeeper? 是大家耳熟能詳的分布式管理中間件，在很多場景下都有很經典的應用。下面主要對zk的架構原理和使用場景做一番總結

Zookeeper特性

最終一致性

保證各個節點服務器數據能夠最終達成一致，zk的招牌功能

順序性

從同一客戶端發起的事務請求，都會最終被嚴格的按照其發送順序被應用到zk中，這也是zk選舉leader的依據之一

可靠性

凡是服務器成功的使用一個事務，并完成了客戶端的響應，那么這個事務所引起的服務端狀態變更會被一直保留下去

實時性

zk不能保證多個客戶端能同時得到剛更新的數據，所以如果要最新數據，需要在讀數據之前強制調用sync接口來保證數據的實時性

原子性

數據更新要么成功要么失敗

單一視圖

無論客戶端連的是哪個節點，看到的數據模型對外一致

ZooKeeper架構

下面看一下zk的架構，看看他是怎么保證最終一致性的。

首先按照角色，zk可以分為leader，follower和observer。只有leader才能真正處理事務請求，在整個集群中，當follower和observer收到來自客戶端的事務請求時，會轉發給leader。當leader處理事務請求的時候，他會向整個集群廣播一個提議，也就是我們常說的zab，這個提議的意思就是告訴follower你們要創建，修改，刪除某znode，然后follower接受leader的提議之后呢，就會做出相應的操作，并告訴leader操作已經完成。

當leader接受到集群里大多數follower的成功操作的回復之后，（這里大多數指的是集群里機器數的一半，這也是zk為啥要使用奇數臺機器湊成集群的一個依據之一），leader認為這次事務被成功處理了，接著再向所有的follower進行通知，告知其進行事務提交，最后會返回客戶端一個事務被成功處理的狀態。此時如果有落后的follower也就是還沒來得及進行事務同步的那些，也會從leader去同步狀態，來保證與leader的一致狀態

zk集群架構圖

zk角色

zk中4種角色的作用：

zk各角色作用

zk寫入流程

數據寫入最終一致性zab算法。leader負責處理寫事務請求，follower負責向leader轉發寫請求，響應leader發出的提議

zk寫入流程

zk選舉

首先聊清楚幾個概念。

一個是服務器的選舉狀態，分為looking，leading，following和observer

looking:尋找leader狀態，處于該狀態需要進入選舉流程

leading:leader狀態，表明當前服務角色為leader

following:跟隨者狀態，leader已經選舉出，表明當前為follower角色

observer:觀察者狀態

事務id：zxid

zxid是64位數字，leader分配，全局唯一且遞增

zk選主流程

首先每個節點發出一個投票，內容是（myid,zxid）,接受來自各個節點的投票，接著進行投票的處理和統計，最后改變服務器的狀態

zk選舉過程

zk數據模型znode

znode是zk特有的數據模型，是zk中數據最小單元，znode上能保存數據，通過掛載子節點形成一個樹狀的層次結構。根由/斜杠開始。

znode層次結構模型

znode節點類型

分為持久節點，臨時節點和順序節點。還可以進行不同節點類型的組合。

znode版本

版本有1.當前數據節點的版本號 2. 當前數據子節點版本號 3.acl權限變更版本號

主要用來通過版本號來實現分布式鎖的一些控制

znode watch機制

znode watch機制也是zk的核心功能之一，是配置管理功能的基石。client端通過注冊watch對象后，只要相應的znode觸發更改，watch管理器就會向客戶端發起回調，可借此機制實現配置管理的分布式更新和同步隊列等場景。

zk watch機制

主要的總結就到這里，后續會分享一些踩過的坑