Zookeeper 集群是一個由多個 Zookeeper 服務實例組成的分布式協調服務系統， 通過奇數個節點（通常 3、5、7 個）的協作，提供高可用性、容錯性和數據一致性，適用于分布式環境下的配置管理、命名服務、分布式鎖等場景。以下從架構、核心機制、選舉機制、數據模型、應用場景及部署要點六個方面展開介紹：

一、集群架構：Leader-Follower 模式

• 角色分工：
  • Leader：唯一處理所有寫請求的節點，通過 ZAB 協議（Zookeeper Atomic Broadcast）將數據變更同步至 Follower 節點，確保全局數據一致性。
  • Follower：處理客戶端讀請求，參與 Leader 選舉，并在選舉中投票。當 Leader 故障時，Follower 通過投票選出新 Leader。
  • Observer（可選）：擴展讀取負載，不參與投票，適合高并發讀場景。
• 節點數量：通常為奇數（如 3、5、7），以保證在部分節點故障時仍能通過多數派（quorum）機制維持服務可用性。

tips:后續詳細介紹Follower和Observer的區別和關系

二、核心機制：ZAB 協議

• 原子廣播：確保所有寫操作按順序執行，要么全部成功，要么全部失敗。
• 崩潰恢復：當 Leader 故障時，通過選舉產生新 Leader，并同步最新數據至所有節點，保證最終一致性。
• 數據一致性：每個節點保存相同數據副本，客戶端無論連接哪個節點，讀取的數據均一致。

三、Leader 選舉機制

• 選舉觸發條件：
  • 集群初始化啟動。
  • Leader 節點崩潰或與集群失去連接。
• 選舉規則：
  1. EPOCH 優先：每個 Leader 任期的代號，EPOCH 大的節點直接勝出。
  2. 事務 ID（ZXID）次之：EPOCH 相同時，ZXID 大的節點勝出（ZXID 標識服務器狀態變更，數值越大表示數據越新）。
  3. 服務器 ID（SID）兜底：ZXID 相同時，SID 大的節點勝出（SID 為節點唯一標識，如 server.1、server.2）。
• 選舉過程示例：
  • 假設集群有 5 個節點（SID 1-5），初始時 SID 3 為 Leader。
  • 若 SID 3 和 5 故障，剩余節點啟動選舉，SID 4 發起投票但因票數不足（需半數以上，即 3 票）無法當選。
  • 最終，SID 3 恢復或新節點加入后，通過 ZXID 或 SID 比較選出新 Leader。

四、集群部署要點

1. 環境準備：
   • 至少 3 臺服務器，確保低延遲、高帶寬網絡連接。
   • 安裝 JDK 8+，關閉防火墻或開放 2181（客戶端端口）、2888（Follower 與 Leader 通信）、3888（選舉端口）。
2. 配置文件（zoo.cfg）：

   tickTime=2000          # 心跳間隔（毫秒）
   initLimit=10           # Follower 初始連接 Leader 的超時時間（tickTime 倍數）
   syncLimit=5            # Follower 同步 Leader 數據的超時時間
   dataDir=/data/zookeeper # 數據快照目錄
   clientPort=2181        # 客戶端連接端口
   server.1=192.168.1.1:2888:3888  # 節點 1 配置
   server.2=192.168.1.2:2888:3888  # 節點 2 配置
   server.3=192.168.1.3:2888:3888  # 節點 3 配置
   

3. 節點標識（myid）：
   • 在 dataDir 目錄下創建 myid 文件，內容為節點編號（如 1、2、3），與 zoo.cfg 中的 server.X 對應。
4. 啟動與驗證：
   • 依次啟動各節點：./zkServer.sh start。
   • 檢查狀態：./zkServer.sh status，正常應顯示 1 個 Leader 和多個 Follower。
   • 使用客戶端測試：./zkCli.sh -server 192.168.1.1:2181，執行 ls / 查看根節點。

五、優勢與挑戰

• 優勢：
  • 強一致性：通過 ZAB 協議保證數據最終一致。
  • 高可用性：奇數節點設計容忍部分節點故障。
  • 輕量級：適合高并發讀場景（如配置中心）。
• 挑戰：
  • 寫性能瓶頸：寫操作需同步至多數節點，密集寫入時可能成為瓶頸。
  • 運維復雜：需監控網絡分區、腦裂等問題。
  • 依賴網絡：節點間通信延遲影響性能。