ZooKeeper 是什么？為什么要造這個輪子？

想象一下，在一個大型分布式系統(tǒng)里，成百上千臺服務(wù)器協(xié)同工作。這時候，會涌現(xiàn)出一大堆“雞毛蒜皮”的協(xié)調(diào)問題：

• 配置管理 (Configuration Management) ：某個配置項變了，如何讓所有機器都收到最新的配置？
• 服務(wù)發(fā)現(xiàn) (Service Discovery) ：系統(tǒng)中誰是主服務(wù)器（Leader）？哪些工作節(jié)點（Worker）還活著？新上線的服務(wù)，它的地址和端口是什么？
• 分布式鎖 (Distributed Lock) ：多個進程要搶占同一個關(guān)鍵資源，怎么保證同一時間只有一個能拿到？
• 組成員管理 (Group Membership) ：如何維護一個集群中所有在線成員的列表？

為每個問題都專門開發(fā)一套高可用的服務(wù)，不僅費時費力，而且很容易出錯。ZooKeeper 的目標，就是提供一個通用的、高性能的“協(xié)調(diào)內(nèi)核”。它本身不直接提供復(fù)雜的分布式鎖或領(lǐng)導(dǎo)者選舉等功能，而是提供一套足夠基礎(chǔ)、足夠強大的 API，讓開發(fā)者可以在它的基礎(chǔ)上，像搭積木一樣輕松構(gòu)建出自己需要的、更復(fù)雜的協(xié)調(diào)“原語”（Primitives）。

它的設(shè)計哲學(xué)是“大道至簡”：服務(wù)器端只做最核心、最簡單的事，從而保證高性能和高可靠性，而將復(fù)雜性留給客戶端去實現(xiàn)。

核心設(shè)計：像文件系統(tǒng)一樣簡單

ZooKeeper 對外暴露的接口非常像一個精簡版的文件系統(tǒng)。它的核心數(shù)據(jù)模型是一個樹狀的層級命名空間，由許多被稱為 數(shù)據(jù)節(jié)點 (znodes) 的單元組成。

/
├── app1
│   ├── p_1  (ephemeral)
│   ├── p_2  (ephemeral)
│   └── p_3  (ephemeral)
└── app2
    ├── config
    └── lock
        ├── write-0000000001
        └── read-0000000002

每個 znode 都可以存儲少量數(shù)據(jù)（默認不超過 1MB），通常是用于協(xié)調(diào)的元數(shù)據(jù)，比如狀態(tài)信息、配置參數(shù)或者節(jié)點地址。

Znode 有幾種非常關(guān)鍵的類型：

• 常規(guī)節(jié)點 (Regular) ：需要客戶端顯式地創(chuàng)建和刪除。
• 臨時節(jié)點 (Ephemeral) ：這種節(jié)點的生命周期與創(chuàng)建它的客戶端 會話 (session) 綁定。當客戶端與 ZooKeeper 的連接斷開，會話超時結(jié)束后，這個臨時節(jié)點就會被自動刪除。這個特性是實現(xiàn)服務(wù)發(fā)現(xiàn)和故障檢測的利器。
• 順序節(jié)點 (Sequential) ：創(chuàng)建時，ZooKeeper 會在節(jié)點路徑后面自動追加一個單調(diào)遞增的數(shù)字序號。比如，在 /app2/lock/ 下創(chuàng)建一個名為 write- 的順序節(jié)點，可能會得到 write-0000000001、write-0000000002 這樣的路徑。這個特性對于實現(xiàn)分布式鎖和隊列至關(guān)重要，可以有效避免“羊群效應(yīng)”。

核心機制：Watch 事件通知

如果客戶端想知道某個 znode（比如存儲著主節(jié)點地址的 znode）有沒有變化，難道要不停地去輪詢（Polling）讀取嗎？這顯然效率低下，而且會給 ZooKeeper 服務(wù)帶來巨大壓力。

為此，ZooKeeper 引入了 監(jiān)視 (Watch) 機制?？蛻舳嗽谧x取一個 znode 時，可以設(shè)置一個 watch 標志。當這個 znode 發(fā)生變化（被修改、被刪除，或者它的子節(jié)點列表發(fā)生變化）時，ZooKeeper 就會向該客戶端發(fā)送一個一次性的通知?？蛻舳耸盏酵ㄖ螅椭雷约罕镜鼐彺娴臄?shù)據(jù)已經(jīng)“過時”了，需要重新來拉取最新數(shù)據(jù)。

這個設(shè)計非常巧妙，它是一種事件驅(qū)動的機制，類似于緩存失效通知，避免了無效的輪詢，大大提升了效率。

API 和保證：ZooKeeper 的契約

ZooKeeper 提供了一套簡潔的 API，核心包括：

• create(path, data, flags): 創(chuàng)建一個 znode 。
• delete(path, version): 刪除一個 znode，version 參數(shù)用于實現(xiàn)樂觀鎖（CAS）。
• exists(path, watch): 檢查 znode 是否存在，并可以設(shè)置 watch 。
• getData(path, watch): 獲取 znode 的數(shù)據(jù)和元數(shù)據(jù)，并可以設(shè)置 watch 。
• setData(path, data, version): 更新 znode 的數(shù)據(jù)，同樣有 version 檢查。
• getChildren(path, watch): 獲取子節(jié)點列表，并可以設(shè)置 watch 。
• sync(path): 強制后續(xù)的讀操作能看到此 sync 調(diào)用之前的所有更新。

在這些 API 背后，ZooKeeper 提供了兩條黃金保證：

1. 線性化寫入 (Linearizable Writes) ：所有會改變 ZooKeeper 狀態(tài)的寫操作，其執(zhí)行順序是全局一致、可串行化的，并且尊重操作的實際發(fā)生順序。簡單說，就是寫操作絕不會亂序。這是通過一個類似 Raft 的原子廣播協(xié)議 Zab 來實現(xiàn)的。
2. FIFO 客戶端順序 (FIFO Client Order) ：來自同一個客戶端的所有請求，會被嚴格按照它們發(fā)送的順序來執(zhí)行。這讓異步操作變得簡單可靠。比如，客戶端可以先發(fā)一堆寫請求去修改配置，最后發(fā)一個創(chuàng)建 "ready" 節(jié)點的請求，ZooKeeper 保證 "ready" 節(jié)點一定是在所有配置修改完成后才出現(xiàn)的。

為什么讀操作不保證線性一致性？

這里有一個關(guān)鍵的設(shè)計取舍。如果讀操作也要求線性一致性（即必須讀到最新的數(shù)據(jù)），那么所有讀請求都得交給 Leader 處理，或者需要一個復(fù)雜的讀協(xié)議，這樣就無法通過增加服務(wù)器來擴展讀性能。

ZooKeeper 的目標應(yīng)用場景通常是“讀多寫少”。為了極大地提升讀的吞吐量，ZooKeeper 允許每個服務(wù)器副本（Follower）直接用自己的本地內(nèi)存數(shù)據(jù)庫來響應(yīng)讀請求。但這樣一來，副本的數(shù)據(jù)可能暫時落后于 Leader ，導(dǎo)致客戶端可能會讀到 陳舊數(shù)據(jù) (stale data) 。

這聽起來很危險，但 ZooKeeper 認為對于協(xié)調(diào)服務(wù)來說，這種“最終一致”的讀是可以接受的。并且，它提供了 sync() 這個“后悔藥”，如果某個讀操作確實需要最新數(shù)據(jù)，可以在讀之前調(diào)用一次 sync() 。sync() 會強制當前客戶端連接的服務(wù)器與 Leader 同步，確保后續(xù)的讀能看到最新的狀態(tài)。

生產(chǎn)實踐：用 ZooKeeper 搭建協(xié)調(diào)原語

有了 znode、watch 和強大的順序保證，我們就可以構(gòu)建各種上層應(yīng)用了。

動態(tài)配置管理

這是最簡單的用法。將配置信息存放在一個 znode /app/config 中。所有應(yīng)用進程啟動時讀取這個 znode 的數(shù)據(jù)，并設(shè)置一個 watch 。當配置需要變更時，管理員只需修改這個 znode 的內(nèi)容。所有設(shè)置了 watch 的進程都會收到通知，然后重新讀取配置，實現(xiàn)動態(tài)更新。

服務(wù)發(fā)現(xiàn)與組成員管理

利用臨時節(jié)點可以完美實現(xiàn)這個功能。假設(shè)有一個服務(wù)集群，每個服務(wù)實例啟動時，都在一個公共的 znode /service/members 下創(chuàng)建一個代表自己的臨時節(jié)點，比如 /service/members/instance-1 。節(jié)點的數(shù)據(jù)可以存放該實例的 IP 和端口。

• 成員發(fā)現(xiàn) ：其他客戶端只需 getChildren("/service/members", watch=true)，就能獲取當前所有在線服務(wù)的列表。
• 故障檢測 ：如果某個服務(wù)實例崩潰或網(wǎng)絡(luò)斷開，它與 ZooKeeper 的會話會超時，其對應(yīng)的臨時節(jié)點會被自動刪除。監(jiān)聽 /service/members 的其他客戶端會收到子節(jié)點變化的通知，從而知道有成員下線了。

分布式鎖（避免羊群效應(yīng)）

一個簡單的鎖可以通過 create("/lock", EPHEMERAL) 來實現(xiàn)，誰創(chuàng)建成功誰就獲得鎖。但這會導(dǎo)致 羊群效應(yīng) (herd effect) ：一旦鎖釋放，所有等待的客戶端會同時被喚醒，然后蜂擁而上嘗試創(chuàng)建節(jié)點，造成瞬間的網(wǎng)絡(luò)風暴，而最終只有一個能成功。

更優(yōu)雅的做法是利用順序節(jié)點：

獲取鎖 (Acquire)

1. 在鎖目錄 /lock 下，創(chuàng)建一個 臨時順序節(jié)點 ，比如得到 /lock/lock-0000000002 。
2. 獲取 /lock 下的所有子節(jié)點，并排序。
3. 判斷自己創(chuàng)建的節(jié)點是不是序號最小的。如果是，則成功獲得鎖。
4. 如果不是，就找到比自己序號小一位的節(jié)點（比如 lock-0000000001），并對它設(shè)置 exists(watch=true) 。
5. 然后等待，直到收到 watch 通知。
6. 收到通知后，回到第 2 步，重新檢查自己是不是最小的。

釋放鎖 (Release)

• 客戶端完成任務(wù)后，只需刪除自己創(chuàng)建的那個臨時節(jié)點即可。如果客戶端崩潰，節(jié)點也會自動刪除。

這個方案中，鎖的釋放只會喚醒隊列中的下一個等待者，完美避免了羊群效應(yīng)。

領(lǐng)導(dǎo)者選舉

領(lǐng)導(dǎo)者選舉和分布式鎖非常相似，通常獲勝的進程會把自己的信息寫入一個約定的 znode，其他進程 watch 這個 znode 來感知 Leader 的變化和存活狀態(tài)。

實際應(yīng)用與常見問題

ZooKeeper 是許多著名開源項目的基石，比如：

• Apache Kafka ：用它來存儲 Broker 和 Consumer 的元數(shù)據(jù)，進行領(lǐng)導(dǎo)者選舉等。
• Apache Hadoop/HDFS ：用于 NameNode 的高可用方案，選舉 Active NameNode。
• Apache HBase ：用于確保集群中只有一個 Master，并存儲 Region Server 的狀態(tài)。

常見問題與解決方案：

• 問：客戶端斷線重連到另一個服務(wù)器，會不會讀到“倒退”的數(shù)據(jù)？

答：不會?？蛻舳藭捴袝涗浰娺^的最新事務(wù) ID，即 zxid 。當它重連到一個新服務(wù)器時，新服務(wù)器會檢查客戶端的 zxid。如果服務(wù)器自己的狀態(tài)比客戶端的還舊，它會拒絕建立會話，直到它從 Leader 那里同步到足夠新的狀態(tài)為止。

• 問：如何處理“羊群效應(yīng)”？

• 答：如上文所述，使用順序節(jié)點和只 watch 前一個節(jié)點的策略來實現(xiàn)有序、無驚群的鎖。

• 問：會話超時時間應(yīng)該設(shè)多長？

• 答：這是一個權(quán)衡。太短，網(wǎng)絡(luò)抖動可能導(dǎo)致節(jié)點被誤判為“死亡”，造成服務(wù)頻繁切換。太長，節(jié)點真的宕機后，系統(tǒng)需要更長時間才能發(fā)現(xiàn)并恢復(fù)?？蛻舳藥焱ǔ诔瑫r時間的 1/3 時發(fā)送心跳，在 2/3 時間內(nèi)沒收到響應(yīng)時就嘗試連接新服務(wù)器，以增加魯棒性。

• 問：ZooKeeper 性能如何？

• 答：讀性能極高，并且可以通過增加服務(wù)器數(shù)量來水平擴展。寫性能會隨著服務(wù)器增多而略有下降，因為 Leader 需要將寫入請求同步給大多數(shù) Follower 。但在現(xiàn)代硬件上，一個小型集群處理數(shù)萬的寫入 QPS 也是可能的。

總而言之，ZooKeeper 通過提供一個看似簡單、實則經(jīng)過深思熟慮的數(shù)據(jù)模型和 API，成功地將分布式協(xié)調(diào)中那些最棘手、最普遍的問題抽象出來，用一個可靠、高性能的“內(nèi)核”予以解決。它讓應(yīng)用開發(fā)者可以更專注于業(yè)務(wù)邏輯，而不是陷入分布式共識的泥潭。