4.ZAB算法核心流程

<zookeeper> 客戶端服務端通信源碼太復雜了，之前看選舉相關的源碼，沒有大的收獲，所以現在不準備看這部分源碼了，以後有時間再補上。上篇選舉流程已經提到客戶端和服務端通信，服務端通過CnxnChannelHandler處理。 本篇主要總結zookeeper如何保證數據壹致性的。

4.Follower收到commit消息，commit自己的內存數據

1.事務 Proposal具有壹個全局遞增的唯壹 ID，稱為事務 ID（ZXID），ZAB 協議需要保證事務的順序，因此必須將每壹個事務按照 ZXID 進行先後排序然後處理，主要通過消息隊列 實現。

2.只能是 Leader 服務器接受寫請求，即使是 Follower 服務器 接受到客戶端的寫請求，也會轉發到 Leader 服務器進行處理，Follower只能處理讀請求。

ZAB 定義了 2 個原則：

同時：

1.低 32 位可以看作是壹個簡單的遞增的計數器，針對客戶端的每壹個事務請求，Leader 都會產生壹個新的事務 Proposal 並對該計數器進行 + 1 操作。

2.高 32 位則代表了 Leader 服務器上取出本地日誌中最大事務 Proposal 的 ZXID，並從該 ZXID 中解析出對應的 epoch 值(leader 選舉周期)，當壹輪新的選舉結束後，會對這個值加壹，並且事務id又從0開始自增.