ZAB協議

1、概述
 　　1. Zookeeper Atomic Broadcast - Zookeeper原子廣播協議，是專門爲Zookeeper設計的協議
　　 2. 這套協議在設計過程當中，基於2PC算法來設計，利用PAXOS算法進行了改進
 　　3. 做用：原子廣播和崩潰恢復

2、原子廣播
 　　1. 原子廣播是爲了保證全部節點數據的一致性
 　　2. 原子廣播基於2PC算法進行改進
 　　3. 2PC - 2 Phase Commit - 二階段提交 - 核心思想是「一票否決」：
 　　　　 a. 分發階段：協調者收到請求以後，將請求發送給每個參與者，而後讓參與者將這個請求進行記錄
 　　　　 b. 提交階段：若是每個參與者都記錄成功，而且協調者收到了全部參與者的成功信號，那麼協調者就會要求全部的參與者執行這個請求
 　　　　 c. 停止階段：若是有一個或者多個參與者返回no，或者若是協調者沒有收到參與者的返回信號，也會認爲這個參與者返回的是no，那麼協調者救護認爲這個請求不可執行，那麼協調者就會要求全部的參與者刪除這個請求的記錄
　　 4. 原子廣播過程：

　　 5. 若是某個follower記錄失敗，而又接收到leader要求執行的命令，這個時候follower就會向leader發送請求從新申請這個任務

3、崩潰恢復  　　1. 當集羣中的leader由於某些緣由產生丟失，集羣中會自動選舉出一個新的leader，那麼這個過程就稱之爲崩潰恢復  　　2. 崩潰恢復是爲了不Zookeeper集羣中出現單點故障  　　3. 每選舉出一個leader，就會給leader一個編號，這個編號稱之爲epochid。每個leader都會將epochid發送給每個follower，follower接收到epochid以後存儲在acceptedEpoch中  　　4. 每個follower接收到請求以後，都會先比較epochid  　　5. 在集羣中，Zookeeper的事務id其實是由64位二進制數字組成，其中高32位表示的是epochid，低32位纔是真正的事務id  　　6. 當一個節點從新連入集羣以後，這個節點會拿着本身的事務id和當前集羣中的事務id進行比較，在比較完成以後，leader就會將確實的操做放入一個隊列中發送給這個節點。這個節點在更新過程當中不對外服務