3.1 選舉機制
（1）半數機制（Paxos 協議）：集羣中半數以上機器存活，集羣可用。所以 zookeeper適合裝在奇數臺機器上。
（2）Zookeeper 雖然在配置文件中並沒有指定 master 和 slave。但是，zookeeper 工作時，是有一個節點爲 leader，其他則爲 follower，Leader 是通過內部的選舉機制臨時產生的。
（3）以一個簡單的例子來說明整個選舉的過程。
假設有五臺服務器組成的 zookeeper 集羣，它們的 id 從 1-5，同時它們都是最新啓動的，也就是沒有歷史數據，在存放數據量這一點上，都是一樣的。假設這些服務器依序啓動，來看看會發生什麼。
1）服務器 1 啓動，此時只有它一臺服務器啓動了，它發出去的報沒有任何響應，所以它的選舉狀態一直是 LOOKING 狀態。
2）服務器 2 啓動，它與最開始啓動的服務器 1 進行通信，互相交換自己的選舉結果，由於兩者都沒有歷史數據，所以 id 值較大的服務器 2 勝出，但是由於沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是 3)，所以服務器 1、2 還是繼續保持LOOKING 狀態。
3）服務器 3 啓動，根據前面的理論分析，服務器 3 成爲服務器 1、2、3 中的老大，而與上面不同的是，此時有三臺服務器選舉了它，所以它成爲了這次選舉的 leader。
4）服務器 4 啓動，根據前面的分析，理論上服務器 4 應該是服務器 1、2、3、4 中最大的，但是由於前面已經有半數以上的服務器選舉了服務器 3，所以它只能接收當小弟的命了。
5）服務器 5 啓動，同 4 一樣當小弟。
3.2 節點類型
（1）Znode 有兩種類型：
短暫（ephemeral）：客戶端和服務器端斷開連接後，創建的節點自己刪除
持久（persistent）：客戶端和服務器端斷開連接後，創建的節點不刪除
（2）Znode 有四種形式的目錄節點（默認是 persistent ）
1）持久化目錄節點（PERSISTENT）
客戶端與 zookeeper 斷開連接後，該節點依舊存在。
2）持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）
客戶端與 zookeeper 斷開連接後，該節點依舊存在，只是 Zookeeper 給該節點名稱進行順序編號。
3）臨時目錄節點（EPHEMERAL）
客戶端與 zookeeper 斷開連接後，該節點被刪除。
4）臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）
客戶端與 zookeeper 斷開連接後，該節點被刪除，只是 Zookeeper 給該節點名稱進行順序編號。
（3）創建 znode 時設置順序標識，znode 名稱後會附加一個值，順序號是一個單調遞增的計數器，由父節點維護
（4）在分佈式系統中，順序號可以被用於爲所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序
3.3 stat 結構體
1）czxid- 引起這個 znode 創建的 zxid，創建節點的事務的 zxid
每次修改 ZooKeeper 狀態都會收到一個 zxid 形式的時間戳，也就是 ZooKeeper 事務 ID。
事務 ID 是 ZooKeeper 中所有修改總的次序。每個修改都有唯一的 zxid，如果 zxid1 小於 zxid2，那麼 zxid1 在 zxid2 之前發生。
2）ctime - znode 被創建的毫秒數(從 1970 年開始)
3）mzxid - znode 最後更新的 zxid
4）mtime - znode 最後修改的毫秒數(從 1970 年開始)
5）pZxid-znode 最後更新的子節點 zxid
6）cversion - znode 子節點變化號，znode 子節點修改次數
7）dataversion - znode 數據變化號
8）aclVersion - znode 訪問控制列表的變化號
9）ephemeralOwner- 如果是臨時節點，這個是 znode 擁有者的 session id。如果不是臨時節點則是 0。
10）dataLength- znode 的數據長度
11）numChildren - znode 子節點數量
3.4 監聽器原理
3.5 寫數據流程
