Zookeeper-ZAB協議
1.ZAB協議的核心
在一個zk叢集中，只有一個leader節點可以將客戶端的寫請求轉化為事務或提議proposal，leader節點寫完資料庫，
把proposal訊息傳送到leader和follower直接的通訊佇列中去，follower節點處理完leader節點發送的proposal訊息後，
給leader節點返回ACK訊息確認，當leader節點接收到半數以上的follower返回的ACK訊息後，leader節點就向所有的
follower節點發送commit訊息。
2.ZAB協議的兩種模式
1.崩潰恢復模式
2.訊息廣播模式
3.zookeeper 中的ZXID
1.為了保證zookeeper事務的順序一致性，zxid採用的時遞增的事id(zxid)來標識事務
2.zxid有64位組成
---高32位是epoch編號（用來標識leader的週期變化，即每次新選舉出leader，epoch編號自動加1）
---低32位用於遞增計數 （每次新選出leader時，清零）
4.崩潰恢復模式
1.崩潰恢復模式需要解決兩個問題
A：已經被處理的訊息不能丟失-產生的原因如下圖所示
當leader節點在向follower節點發送commit訊息的時候，只有follower1 訊息傳送成功後，leader節點直接崩潰，
還沒有向follower2節點發送commit訊息。
也就是說當zk叢集恢復使用（選出新的leader）後，老leader節點最後提交到follower1節點的訊息不能丟失
B：被丟棄的訊息不能再次出現-客戶端只能重新發一次請求 -產生的原因如下圖所示
當leader節點向所有的follower節點發送commit訊息之前，leader節點直接崩潰，也就是說，
所有的follower節點都沒有同步到leader節點最後崩潰前處理的客戶端請求的資料。
就是說當老leader節點可以使用，加入新的leader領導的叢集中作為follower節點使用的時候，
老leader節點最後處理的客戶端請求需要丟棄
2 .崩潰恢復的解決方案
A：針對第一個問題，選出叢集中擁有最高zxid編號事務proposal機器之一，作為新的leader節點
B：針對第二個問題，當老的leader作為新的follower節點加入叢集時，新的leader把老的leader中所
有舊的epoch號標記的未被提交的事務proposal清除
5.訊息廣播模式
1.訊息廣播模式流程圖
2.訊息廣播模式的步驟
- 客戶端發起一個寫操作請求
- Leader伺服器將客戶端的request請求轉化為事物proposql提案，同時為每個proposal分配一個全域性唯一的ID，即ZXID。
- leader伺服器與每個follower之間都有一個佇列，leader將訊息傳送到該佇列
- follower機器從佇列中取出訊息處理完(寫入本地事物日誌中)畢後，向leader伺服器傳送ACK確認。
- leader伺服器收到半數以上的follower的ACK後，即認為可以傳送commit
- leader向所有的follower伺服器傳送commit訊息。
3. leader節點和每個follower節點之間都有一個佇列進行收發訊息
使用佇列訊息可以做到非同步解耦。leader和follower之間只要往佇列中傳送了訊息即可。
如果使用同步方式容易引起阻塞。效能上要下降很多。
6.ZAB協議的原理-每個leader都要經歷3個階段
1.發現 -即每個ZK叢集必須選舉出一個leader節點；每個leader節點維護一個follower列表，將來客戶端可以和這些節點通訊
2.同步 - 即leader節點負責把本身的資料同步到所有的follower節點上去，做到多副本儲存；follower將佇列中未處理完的
請求消費完成後，寫入本地事物日誌中。
3.廣播 - 即leader可以接受客戶端新的proposal請求，將新的proposal請求廣播給所有的follower
7.zookeeper滿足CAP理論的CP理論
原因：可以從ZAB協議的崩潰恢復模式的第二個問題來回答，即當老的leader節點作為follower節點加入
新的leader領導的叢集中去的時候，新的leader會把老的leader節點中未提交的事務proposal丟棄，
這樣就犧牲了一定的可用性