ZAB 協議
ZAB 協議
ZAB 協議是為分布式協調服務（Zookeeper）專門設計的一種支持故障恢復的原子廣播協議。
消息廣播：
- 只允許有一個主進程（leader）接收事務請求並處理。
- 當leader 接收到請求之后，將事務請求轉化為事務提議（proposal） 並將該proposal 分別入隊 （leader 會為每個follower 分別創建一個響應隊列用來保證事務提交的順序）。
- 每個事務proposal 有一個遞增的全局唯一的ID，事務ID（ZXID）
- leader 通過響應隊列將proposal 分發到其他節點之后，等待反饋；follower 接收到proposal 之后寫入本地日志，返回 ack；
- leader 收到一半以上follower 的反饋之后，會向其他節點 發送commit，同時提交事務。
故障恢復：
- 保證已經在leader 機器上提交的事務最終被所有機器提交
- 丟棄只在leader 機器上被提出的事務
為保證以上兩點：
- Leader選舉：選擇ZXID 最大的節點作為Leader。
- 數據同步：leader 為每個follower 創建一個隊列，將沒有被各個follower 提交的事務 proposal填入各個隊列，並分發給follower。follower 事務同步以后，leader會將它加入到真正可用follower 列表中。
ZAB協議中兩種模式：
消息廣播和故障恢復。
當系統啟動或者leader 機器出現故障現象時，進入故障恢復模式並進行leader選舉。選舉產生的leader 會與過半的follower 進行數據同步。同步結束，退出故障恢復模式，進入消息廣播模式；任意一台遵從ZAB協議的機器啟動后，如果檢測到leader 廣播，都會自動進入故障恢復模式與leader 進行數據同步，同步之后，進入消息廣播模式；非leader 接收到客戶端事務請求時，會轉發給leader 處理；
Leader 重新選舉條件：
- leader 宕機或故障
- 與leader 保持連接的機器少於一半
Zookeeper
- zookeeper 為分布式應用提供了一個高效可靠的分布式協調服務；
- 實現依賴於ZAB 協議，實現了一種主備模式的架構來保持集群的數據一致性；
- zookeeper 可以幫助分布式應用以一個共享的樹形的命名空間實現協調；
- zookeeper 將數據全部存儲在內存中並且集群中任意一台機器都可以響應客戶端讀操作，因此它更適合用以讀操作為主的場景； zookeeper 集群節點有三種角色：leader、follower、observer。
- leader：通過選舉產生的集群領導者；提供讀寫服務；
- follower：提供讀服務；參與leader 選舉和寫操作“過半寫成功”策略；
- observer：提供讀服務；不影響集群寫性能的前提下提升集群的讀性能；
- zookeeper 集群節點總數為奇數；
- zookeeper 數據節點類型：持久節點（只能采用刪除操作清除該節點）、臨時節點（其生命周期取決於session 是否失效）、順序節點（子節點順序表，節點名有數字后綴） ；
- zookeeper 每個節點都有 Stat 結構（數據節點的所有狀態信息）
- 最重要的功能：watcher；
- 開源客戶端：zkclient、curator；