大家好，這里是架構資源棧！點擊上方關注，添加“星標”，一起學習大廠前沿架構！
引言
在分布式系統中，服務注冊、配置管理、分布式鎖、選舉等場景都需要一個高可用、一致性強的協調服務。Apache ZooKeeper 憑借其輕量級、易用性和強一致性，成為業界主要選擇之一。本文將從原理層面剖析 ZooKeeper，給出 Java 快速上手示例，并與同類產品（etcd、Consul、Eureka）進行對比，為架構選型提供參考。
一、ZooKeeper 簡介
-
定位：分布式協調服務，提供命名（Naming）、同步（Synchronization）、配置管理（Configuration）、組管理（Group Management）等基本原語。
-
優勢：
- 讀性能優越：針對讀多寫少場景優化
- 強一致性：采用 Zab（ZooKeeper Atomic Broadcast）協議保障寫操作原子廣播
- Watch 機制：基于事件通知的異步設計
二、ZooKeeper 核心原理
1. 數據模型 —— ZNode 樹
- 以類文件系統的樹狀結構存儲數據，稱為 ZNode
- 每個 ZNode 可以存儲少量的元數據和數據（默認 1MB 以內）
- 支持持久節點（Persistent）和臨時節點（Ephemeral），及順序變體
/
├── /app
│ ├── /app/config (持久節點)
│ └── /app/lock_0001 (臨時順序)
└── /services├── /services/svcA (臨時節點)└── /services/svcB (臨時節點)
2. 集群架構與選舉
-
角色：每個節點啟動時會在集群中選舉產生一個 Leader，其余為 Follower；也可配置 Observer（只讀，不參與選舉）
-
讀寫分離：
- 讀請求：可由任意節點（Follower/Observer）處理
- 寫請求：必須先提交給 Leader，由 Leader 通知 Follower 過半達成一致后應用并回復客戶端
3. Zab 協議（Atomic Broadcast）
- Proposal：Leader 接收寫請求并生成提案（Proposal）
- Sync：Leader 將 Proposal 發送給所有 Follower
- Ack：Follower 收到 Proposal 后返回確認
- Commit：Leader 收到多數 Ack 后發送 Commit，所有節點應用并完成事務
4. 會話與 Watch
- Session：客戶端與集群建立會話，ZK 用心跳維持，有超時機制
- Watch：客戶端可在 ZNode 上注冊 Watch，節點數據/子節點變化時觸發一次性事件通知
三、ZooKeeper 快速入門示例（Java）
import org.apache.zookeeper.*;
import org.apache.zookeeper.data.Stat;import java.util.concurrent.CountDownLatch;public class ZkDemo {private static final String CONNECT_ADDR = "zk1:2181,zk2:2181,zk3:2181";private static final int SESSION_TIMEOUT = 5000;private ZooKeeper zk;private CountDownLatch connectedSignal = new CountDownLatch(1);public void connect() throws Exception {zk = new ZooKeeper(CONNECT_ADDR, SESSION_TIMEOUT, event -> {if (event.getState() == Watcher.Event.KeeperState.SyncConnected) {connectedSignal.countDown();}});connectedSignal.await();}// 創建持久節點public String createPersistent(String path, byte[] data) throws KeeperException, InterruptedException {return zk.create(path, data, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);}// 讀取數據并注冊 Watchpublic byte[] getData(String path, Watcher watcher) throws KeeperException, InterruptedException {Stat stat = zk.exists(path, true);if (stat != null) {return zk.getData(path, watcher, stat);}return null;}// 更新數據public void updateData(String path, byte[] data) throws KeeperException, InterruptedException {Stat stat = zk.exists(path, false);if (stat != null) {zk.setData(path, data, stat.getVersion());}}// 關閉連接public void close() throws InterruptedException {zk.close();}public static void main(String[] args) throws Exception {ZkDemo demo = new ZkDemo();demo.connect();String path = demo.createPersistent("/app/config", "v1".getBytes());System.out.println("節點創建: " + path);byte[] data = demo.getData("/app/config", event ->System.out.println("節點變更: " + event));System.out.println("讀取數據: " + new String(data));demo.updateData("/app/config", "v2".getBytes());demo.close();}
}
四、與同類產品對比
| 特性 | ZooKeeper | etcd | Consul | Eureka |
|---|---|---|---|---|
| 一致性 | 強一致性（CP） | 強一致性（CP，基于 Raft） | 可配（默認 CP） | 弱一致性（AP，基于自選復制） |
| 讀寫性能 | 讀快、寫次之 | 寫優、讀優 | 性能均衡 | 適中 |
| Watch機制 | 一次性 Watch，需重置 | 支持 Watch/WatchStream，可持續監聽 | 支持 KV Watch | 不支持，需客戶端輪詢 |
| 數據模型 | 樹形層級（類文件系統） | 鍵值對（扁平） | KV + 服務健康檢查 | 服務注冊中心 |
| 客戶端生態 | 原生 Java/C、眾多三方 | Go/Kotlin/Java/C# 等，多語種支持 | Go/Java/Python/Node.js 等 | Java 生態為主 |
| 高可用方案 | 集群模式，Observer 可擴展讀 | 集群模式，普通節點+Learner | Cluster + WAN Federation | 集群模式，PeerAwareInstance |
| 典型場景 | 分布式鎖、配置管理、選舉、Naming | 配置管理、服務發現、Leader 選舉 | 服務發現、健康檢查、Multi-Datacenter | 服務發現、負載均衡 |
對比總結
- 一致性與性能：若追求強一致性、讀多寫少場景，首選 ZooKeeper；寫密集場景可考慮 etcd。
- 生態與易用性：Consul 提供內置健康檢查、Multi-DC 支持，適合作為全棧服務發現與健康監控；Eureka 更偏向 Java 微服務生態（Spring Cloud）。
- Watch 能力：持續監聽場景下，etcd 和 Consul 更靈活；ZooKeeper 則需客戶端自行重置 Watch。
結語
Apache ZooKeeper 以其成熟的協調原語、強一致性和穩定的社區，仍是分布式系統核心組件的首選。但在選型時，應結合業務場景、性能特點和運維成本，綜合權衡。希望本文能夠幫助你快速理解 ZooKeeper 原理，并在架構設計中做出更明智的決策。
轉自：https://mp.weixin.qq.com/s/cSTNX6jaOYnkHhSEjz9ILw
