從擴充套件性開始講起，在zk中存在的角色有leader，follower，observer。
zk是讀寫分離的，所有的寫都會壓到leader上面，讀操作可以在follower上面完成。只有follower才能選擇，observer比follower級別還低。observer只是為了放大查詢能力。
乙個集群中投票選舉的速度由follower決定。
1. 可靠性來自於可以快速恢復，如果leader掛掉之後可以快速恢復，保證集群可用；
2. 對外提供資料的一致性，這裡的一致性是弱一致性，採用的最終一致性。最終一致性過程中，節點是否對外提供服務？
paxos是乙個基於訊息傳遞的一致性演算法，paxos被認為是到目前為止唯一的分布式一致性演算法。paxos有乙個前提：不存在拜占庭將軍問題。也就是假設通訊過程不會被篡改。
zab協議是在paxos保證一致性基礎上設計出來的高可用協議。zab主要用於構建高可用分布式系統，paxos演算法主要用於構建一致性狀態機。zab協議包括兩種基本的模式：崩潰恢復和訊息廣播。
zk通過zab協議來保證分布式系統的最終一致性：
1. zab協議是一種支援崩潰恢復的原子廣播協議，是zk保證資料一致性的核心演算法。
2. 基於zab協議，zk實現了一種主備模型的系統架構來保證集群中各個副本之間資料的一致性。就是指只要一台服務負責處理外部的寫請求，然後將資料同步給其他follower節點。
zk客戶端會隨機的連線到集群中的某乙個節點，如果是讀請求，就直接從當前節點讀取資料；如果是寫請求，那麼節點就會把請求**給leader，leader接收到事務會廣播該事務，只要超過半數節點寫入成功，該事務就會被提交。
1. 確保主節點提交的事務，在從節點也必須提交；
2. 丟棄在主節點上提出但是沒有被提交的事務。
1. 使用乙個單一的程序（leader節點）來接受並處理寫請求，採用zab的原子廣播協議將伺服器資料的狀態變更以事務proposal的形式廣播到所有的副本程序中；
2. 保證乙個全域性的變更序列被順序引用：
3. 當主程序出現異常時，整個集群能夠快速恢復，提供高可用。
zab協議要求每個leader都要經歷三個階段：發現，同步，廣播
1）所有的事務請求必須由乙個全域性唯一的伺服器來協調處理，這樣的伺服器被叫做leader伺服器。其他剩餘的伺服器則是follower伺服器。
2）leader伺服器 負責將乙個客戶端事務請求，轉換成乙個事務proposal，並將該 proposal 分發給集群中所有的 follower 伺服器，也就是向所有 follower 節點傳送資料廣播請求（或資料複製）
3）分發之後leader伺服器需要等待所有follower伺服器的反饋（ack請求），在zab協議中，只要超過半數的follower伺服器進行了正確的反饋後（也就是收到半數以上的follower的ack請求），那麼 leader 就會再次向所有的 follower伺服器傳送 commit 訊息，要求其將上乙個 事務proposal 進行提交。
當整個集群啟動過程中，或者當 leader 伺服器出現網路中弄斷、崩潰退出或重啟等異常時，zab協議就會進入崩潰恢復模式，選舉產生新的leader。
當選舉產生了新的 leader，同時集群中有過半的機器與該 leader 伺服器完成了狀態同步（即資料同步）之後，zab協議就會退出崩潰恢復模式，進入訊息廣播模式。
這時，如果有一台遵守zab協議的伺服器加入集群，因為此時集群中已經存在乙個leader伺服器在廣播訊息，那麼該新加入的伺服器自動進入恢復模式：找到leader伺服器，並且完成資料同步。同步完成後，作為新的follower一起參與到訊息廣播流程中。
當leader出現崩潰退出或者機器重啟，亦或是集群中不存在超過半數的伺服器與leader儲存正常通訊，zab就會再一次進入崩潰恢復，發起新一輪leader選舉並實現資料同步。同步完成後又會進入訊息廣播模式，接收事務請求。
在整個訊息廣播中，leader會將每乙個事務請求轉換成對應的 proposal 來進行廣播，並且在廣播 事務proposal 之前，leader伺服器會首先為這個事務proposal分配乙個全域性單遞增的唯一id，稱之為事務id（即zxid），由於zab協議需要保證每乙個訊息的嚴格的順序關係，因此必須將每乙個proposal按照其zxid的先後順序進行排序和處理。
1. 在zk集群中，資料副本的傳遞策略採用的是訊息廣播模式。資料同步方式類似於二階段提交，但是卻比二階段提交效能更高。二階段提交要求協調者必須等到所有參與者反饋ack確認訊息後，再傳送commit訊息。要求所有的參與者要麼全部成功，要麼全部失敗。但是這種方式會存在嚴重的阻塞問題。
2. 在zab協議中，leader只要等到半數以上的follower成功反饋即可。
訊息廣播流程圖：
訊息廣播步驟：
客戶端發起乙個寫操作請求；
leader 伺服器將客戶端的請求轉化為事務 proposal 提案，同時為每個 proposal 分配乙個全域性的id，即zxid。
leader 伺服器為每個 follower 伺服器分配乙個單獨的佇列，然後將需要廣播的 proposal 依次放到佇列中取，並且根據 fifo 策略進行訊息傳送。
follower 接收到 proposal 後，會首先將其以事務日誌的方式寫入本地磁碟中，寫入成功後向 leader 反饋乙個 ack 響應訊息。
leader 接收到超過半數以上 follower 的 ack 響應訊息後，即認為訊息傳送成功，可以傳送 commit 訊息。
leader 向所有 follower 廣播 commit 訊息，同時自身也會完成事務提交。follower 接收到 commit 訊息後，會將上一條事務提交。
崩潰恢復主要包括兩個部分： leader選舉和資料恢復。
zab協議如何保證資料一致性：
假設兩種異常情況：
1、乙個事務在 leader 上提交了，並且過半的 folower 都響應 ack 了，但是 leader 在 commit 訊息發出之前掛了。
2、假設乙個事務在 leader 提交之後，leader 掛了。
zab協議需要保證選舉出來的leader需要滿足以下條件：
1）新選舉出來的 leader 不能包含未提交的 proposal。即新選舉的 leader 必須都是已經提交了 proposal 的 follower 伺服器節點。
2）新選舉的 leader 節點中含有最大的 zxid。這樣做的好處是可以避免 leader 伺服器檢查 proposal 的提交和丟棄工作。
zab 如何資料同步：
1）完成 leader 選舉後（新的 leader 具有最高的zxid），在正式開始工作之前（接收事務請求，然後提出新的 proposal），leader 伺服器會首先確認事務日誌中的所有的 proposal 是否已經被集群中過半的伺服器 commit。
2）leader 伺服器需要確保所有的 follower 伺服器能夠接收到每一條事務的 proposal ，並且能將所有已經提交的事務 proposal 應用到記憶體資料中。等到 follower 將所有尚未同步的事務 proposal 都從 leader 伺服器上同步過來並且應用到記憶體資料中以後，leader 才會把該 follower 加入到真正可用的 follower 列表中。
zookeeper系列 二 配置檔案說明
zookeeper 這樣的設計其實是有它自身的原因的。通過前面對 zookeeper 的配置可以看出，對 zookeeper 集群進行配置的時候，它的配置文件是完全相同的 對於集群偽分布模式來說，只有很少的部分是不同的 這樣的配置方使得在部署 zookeeper 服務的時候非常地方便。另外，如果伺服...
zookeeper（二）zookeeper單機啟動
其實都不用想單機邏輯肯定非常簡單，畢竟一台伺服器，很多都很好實現。整個流程圖如下 其中箭頭中的數字是呼叫的順序，橫向表示在同乙個方法中，而黃色區域為該方法的注釋。單機啟動的整個體系就是這個展開的。從啟動項就能明白，我們指定了配置檔案啟動，所以肯定是把配置檔案的引數解析出來，然後載入到記憶體中，最後初...
Zookeeper系列 Leader選舉
為了徹底搞懂zk選舉leader的過程，需要在windows本地搭建乙個偽集群出來，通過實際操作，觀察集群的節點的變化。但是在實操過程中，發現windows搭建的一些坑，這記錄下。1.參考此部落格進行搭建，2.依次啟動，啟動後，無法使用zkserver.cmd status命令，無法觀察哪乙個節點是...