ZooKeeper運維經驗

ZooKeeper 是分布式環境下非常重要的一個中間件，可以完成動態配置推送、分布式 Leader 選舉、分布式鎖等功能。在運維 AliExpress ZooKeeper 服務的一年多來，積累如下經驗：

1. 集群數量

3臺起，如果是虛擬機，必須分散在不同的宿主機上，以實現容災的目的。如果長遠來看（如2-3年）需求會持續增長，可以直接部署5臺。ZooKeeper集群擴容是比較麻煩的事情，因此寧可前期稍微浪費一點。

2. 客戶端配置域名而不是 IP

如果有一天你的 ZooKeeper 集群需要做機房遷移，或者其中幾個節點機器掛了，需要更換。讓你的用戶更新 ZooKeeper 服務器配置不是件輕松的事情，因此一開始就配置好域名，到時候更新 DNS 即可。

3. 開啟 autopurge.snapRetainCount

ZooKeeper 默認不會自動清理 tx log，所以總會有一天你會收到磁盤報警（如果你有磁盤監控的話）。開啟自動清理機制后，就不用擔心了，我的配置如下：

autopurge.snapRetainCount=500
autopurge.purgeInterval=24

4. 擴容

如果你可以接受停止服務半個小時，那基本隨意玩了，但在比較嚴肅的環境下，還是不能停服務的。我的做法是這樣的：

0. 有節點 A, B, C 處于服務狀態

server.3=192.168.12.1:2888:3888
server.4=192.168.12.2:2888:3888
server.5=192.168.12.3:2888:3888

1. 加入節點 D，配置如下：

server.3=192.168.12.1:2888:3888
server.4=192.168.12.2:2888:3888
server.5=192.168.12.3:2888:3888
server.6=192.168.12.4:2888:3888
server.7=192.168.12.5:2888:3888

用 4 字命令檢查，保證該節點同步完畢集群數據，處于 Follower 狀態：

?  ~  echo srvr | nc 192.168.12.4 2181
Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
Latency min/avg/max: 0/0/13432
Received: ***
Sent: ***
Connections: ***
Outstanding: 0
Zxid: 0x***
Mode: follower
Node count: ***

需要注意的是，這一步加入的節點的 id，必須大于集群中原有的節點的 id，例如 6 > 3,4,5，我也不知道為什么需要這樣。

2. 同上一步一樣，加入節點 E

3. 更新 A B C 的配置如 D 和 E，并依此重啟

5. 機房遷移

例如要把服務從 X 機房的 A B C 遷移到 Y 機房的 A’ B’ C’。做法是首先把集群擴容成包含6個節點的集群；然后修改域名指向讓用戶的連接都轉到 A’ B’ C’；最后更新集群配置，把 A B C 從集群摘除。

6. 跨機房容災

由于 ZooKeeper 天生不喜歡偶數（怕腦裂），因此有條件的就三機房部署，但機房之間的網絡條件得是類似局域網的條件，否則性能就堪憂了。

雙機房做自動容災基本不可能，加入手動步驟是可以的，和 DB 一樣，短時間不可用，立刻啟用另外一個機房，平時保證數據同步。

三機房部署，如果一個機房離的比較遠，網絡延遲較高怎么辦？可以 3 + 3 + 1 部署，1 就放在那個網絡延遲較高的地方，確保 leader 在 3 + 3 這兩個機房中間，那么平時的性能就能保證了。怎么保證 leader 不到 1 呢？目前能想到的辦法就是如果發現就重啟它。