以下基於小白理解，如果有錯誤，請指正：
1、約定
Leader:領導者 Follower:跟隨者 oberserver:觀察者
CAP理論：
2、原理
zk基礎數據結構是DataTree（先不研究底層數據結構），核心思想就是基於Zab協議（Leader選舉）+ 二段式分佈式事務。
1、Leader選舉 ： 客戶端發送了一個請求，zk集羣裏所有節點啓動，進入Leader選舉（a、比較各個節點裏的事務id(zxid)，最大的就是Leader；如果各個節點裏的zxid一致的情況，則比較serverid（myid），最大的就是Leader）。
2 、ACK ：當從Follower裏選舉出Leader後，Leader將會將請求轉化爲全局唯一的事務請求（二段式事務開啓），然後將請求廣播給所有Follwer，等待響應（ACK）。
3、Commit ： 只有當Leader得到超過半數Follower的響應情況下，纔會提交事務，同時將通知所有的Follower提交事務。
3、開發中遇到的問題
當往已經選舉出Leader的zk集羣裏動態添加一個節點，此時整個集羣是不會重新進入Leader選舉的，得重啓進入恢復模式。
Leader選舉選舉發生在（Zab協議中恢復模式）：
1、集羣啓動
2、Leader掛掉
3、Follower掛掉後，Leader發現已經沒有過半的Follower投票給自己，此時整個zk集羣宕機，不能對外提供服務。
4、zk腦裂（split-brain）
當因爲整個zk集羣在選舉過程中通信出現問題，而分裂爲多個zk集羣，此時各個zk集羣會各自選舉出自己的Leader，一旦通信恢復，這個集羣將會出現多個Leader。
解決方法：Leader的過半選舉已經解決了這個問題，只有超過過半機器存活的情況下，纔會進行選舉。
當整個zk集羣腦裂成兩個zk集羣，因爲兩個集羣裏的節點都不會超過原先過半機器存活，所以這兩個zk集羣實際是不會進行選舉的。
實際上啥都不用做，別用太老的zk版本就好了。
大佬分析博客，在下佩服：