一言以蔽之：分散式系統的協調者

兩個核心功能

1.管理和儲存資料結點

2.提供對結點的監聽服務

三種角色

分別是Leader、Follower、OBSERVER，沒有leader的時候，所有zk伺服器都處於LOOKING狀態，不處於任何角色。一旦leader選舉成功，各個角色才各自歸位。

Leader：做事務請求的驗證，傳送Proposal，收集ACK，發PING維護Follower和Observer的存活列表，維護session的生命週期，分配事務id；

Follower：接收client的讀寫操作，自己處理讀操作，將寫操作轉發到leader，接收Proposal，參與proposal投票，對leader作出ACK，響應leader傳送的PING請求，檢測leader的存活狀態註冊watch，觸發通知；

Observer：不參與任何投票，leader不會向Observer發Proposal，也不參與leader的選舉，它接收讀寫請求，並轉發寫請求給leader，它的存在並不能增加宕機容忍性，而是提升叢集的非事務處理能力，響應leader傳送的PING請求，檢測leader的存活狀態。

leader選舉

選票格式(proposedLeaderId，proposedZxid，logicalclock，proposedEpoch)

初始選票(自己的serverid，自己的lastZxid，自己的logicalClock，自己的currentEpoch)

說明：Logicalclock是選舉次數，自程序啟動以來經歷的第幾次選舉，為避免因網路過慢導致上輪選舉造成影響，故logicclock要達成一致，以最大的那個優先。

PK規則：先比較epoch，epoch相同的話比較zxid，zxid再相同的話比較serverid，值大的那個獲勝，參與投票的server如果發現接收到的投票比自己大，那麼會更新自己的投票再發送出去。

選舉規則：

1、 所有處於looking狀態的server都向其它所有server傳送投票，初始投票選自己；

2、 接收來自其它server的投票，接收不到就繼續傳送本地投票，如果PK失敗則更新本地投票重新發出；

3、 當收集的投票滿足條件，包括本地投票在內的quorum數量的投票都達成一致，等待200ms無異議時，當接收的投票來自於leadering或者following狀態時還需要判斷leader是否處於leadering狀態，以避免建立連線不成重新進入looking狀態；

4、 Follower和leader進入各自的角色，leader啟動sync埠，follower向leader建立連線，follower向leader註冊自己，leader發現follower不足夠會重新進入選舉階段。

故障恢復

一個有2N+1個例項組成的zookeeper叢集，最大能允許N個例項出現故障，超過N個就會造成服務不可用。那什麼情況下會使得叢集進入leader選舉狀態呢？

1、leader出現故障：當leader出現故障時所有的 Follower會進入LOOKING狀態重新進行投票選舉；

2、當叢集中有超過N個例項出現故障，這時leader將接收不到足夠quorum數量的PING響應，這時leader 關閉同步埠，斷開所有的learner連線，使得整個叢集都進入LOOKING狀態

3、當選舉成功leader角色和Follower角色都已經建立之後，如果在Follower註冊、Follower與leader建立連線、同步資料成功的個數，不足quorum數量，都會導致重新進入LOOKING狀態重新進行leader選舉。

4、learner和leader之間連線是BIO的，learner一直做阻塞讀和阻塞寫的迴圈，一旦發現讀超時則退回到LOOKING狀態重新尋找leader

初始化和資料同步

Leader

1、 對於leader，啟動同步埠，為每個learner分配一股learnerHandler和Sender執行緒；

2、 等待超過叢集機器半數的follower註冊進入forwarding列表，等待超過機器半數的follower接收到同步資料，完成資料同步；

3、 開啟對外服務，啟動處理事務的processor。

Follower

1、 對於follower，建立與leader同步埠的連線；

2、 同步epoch，向leader註冊自己，完成資料同步；

3、 啟動處理事務的processor。

執行緒模型

WorkerReceiver[myid=1] 用於leader選舉

將多個recvWorker收到的投票匯總起來，自身處於looking狀態提供給quorumPeer進行投票判斷，自身處於learner和leader狀態發出自己的投票交給workerSender(用於告訴重新加入的節點leader是誰)

WorkerSender[myid=1] 用於leader選舉

負責將要發出的投票新增到各個serverid對應的傳送佇列中(每個serverid一個佇列)

SendWorker：2 用於leader選舉

將server2對應的佇列資料依次傳送給server2

RecvWorker：2 用於leader選舉

接收server2過來的投票，以佇列方傳送給workerReceiver執行緒

QuorumPeer[myid=1]

用於選舉發送投票訊息尋找leader，Follower用於初始化資料同步，向leader註冊自己，Leader用於初始化監控資料同步完成，Follower在訊息廣播用作接收leader過來的packet、返回ping，Leader在訊息廣播用作發ping並心跳檢查，啟動zookeeperserver，開啟對外服務。

資料結構

ZooKeeper所提供的服務主要是通過：資料結構+原語+watcher機制

資料結構：Znode

原語：關於該資料結構的一些操作

Wathcer：通知機制 客戶端可以在節點上設定watch，我們稱之為監視器。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操作。當watch被觸發時，ZooKeeper將會向客戶端傳送且僅傳送一條通知，因為watch只能被觸發一次，這樣可以減少網路流量。

controller_epoch:最後更新leader和isr的controller代

leader:leader副本的id

version:版本id

leader_epoch:leader副本的代

示例如下：