ZooKeeper與Paxos

ZooKeeper 沒有采用Paxos 協議，採用的是ZAB（ZooKeeper Atomic Broadcast）

• 是一個典型的分佈式數據一致性解決方案
• 分佈式應用能夠基於他實現：
  • 數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master選舉、分佈式鎖、分佈式隊列
• 保證以下分佈式一致性特性：
  • 順序一致性
  • 原子性
    • 不會出現部分機器應用，部分沒有
  • 單一視圖
    • 不管看到的是ZooKeeper哪一個服務器，服務端數據都是一致的
  • 可靠性
  • 實時性
    • 僅僅保證必定時間內，客戶端必定能從服務器端讀到最新數據
• 高可用、高性能、嚴格數據順序管控能力
• 四大設計目標：
  • 簡單的數據模型（樹結構，全量存儲在內存中）
  • 能夠構建集羣
    • 只要集羣中存在一半以上的機器，就能提供正常服務
  • 順序訪問
    • 客戶端每一個更新請求都會配以惟一遞增編號
  • 高性能
    • 全量數據存儲在內存中，尤爲適合以讀爲主的場景

ZooKeeper基本概念

• 集羣角色
  • ZooKeeper沒有沿用 Master/slave 模式，
  • 而是採用Leader、Follower、Observer
    • 選舉產生Leader，Leader 提供讀寫服務
    • Follower、Observer 提供讀，Observer不參與選舉
• 會話
  • 客戶端與服務器端創建的是TCP 長鏈接
  • 心跳檢測保持有效的會話
  • 斷開鏈接後，sessionTimeout 以內，再鏈接上任意服務器，會話依然有效
• 數據節點（Znode）
  • 節點指機器節點
  • Znode能夠分爲持久節點、臨時節點
• 版本
  • 數據節點存儲State數據結構，
  • 包括version（當前版本）、cversion（當前子節點版本）、cversion（ACL版本）
• Watcher（事件監聽器）
  • 容許客戶端在指定節點上註冊特定Watcher，特定事件觸發，服務器會通知感興趣的客戶端
• ACL （權限控制管理）
  • 相似Unix的權限控制

ZAB協議：

• 崩潰恢復模式
• 消息廣播模式
• 爲ZooKeeper專門設計的支持崩潰恢復原子廣播協議
• 只容許惟一的一個Leader 進行事務處理
• 已經有過半數的Follower 服務器與Leader 服務器狀態保持一致，進入消息廣播模式模式
• 消息廣播模式模式下，新加入節點會自動進入崩潰恢復模式，與Leader 同步數據後，進入消息廣播模式
• 進入崩潰模式後，只要集羣中過半的服務器彼此通訊正常就能夠選舉新的Leader 進入廣播模式
  • 也就是說3臺機器，1個Leader，兩個Follower ，其中一個Follower 崩潰了，依然能夠正常工做（Leader本身支持本身）

消息廣播

• 原子廣播協議
• 基於FIFO特性的TCP協議
• Leader 收到半數Proposal 就會提交
• Follower要麼迴應，要麼拋棄Leader
• 每一個Proposal都有全局惟一遞增id

崩潰恢復

基本特性

• 新Leader 選舉，根據全局ZXID（64位的數字）最大的來作新Leader
• ZXID（64位的數字）
  • 低32位每次自增1
  • 高32位表明Leader週期epoch編號；
  • 若是出現新Leader，根據最大ZXID解析出epoch編號再加1，低32位從0開始生成新的ZXID

數據同步

深刻ZAB協議

事務

• 根據事務標識z=<e,c>
  • e表明主進程週期epoch（e）
    • 主進程週期 也叫主進程序列號
  • c表明主進程週期內的事務計數
• 根據e，c大小判斷事務前後
• 提交排序靠後的事務以前的事務一定已經提交

消息廣播和崩潰恢復，進一步細分爲：

• 發現階段
  • 選舉出最大的ZXID做爲新Leader
  • 啓動的時候都是looking狀態
• 同步階段、
• 廣播階段