前面介紹了ZooKeeper的一些基本特性， ZooKeeper入門 ,也安裝運作了一個簡單的ZooKeeper的例子。這此主要介紹ZooKeeper内部的一些工作方式理論部分。
與文無關
主要涉及以下：
- ZooKeeper服務的架構
- ZooKeeper的資料模型
- ZooKeeper的節點特性
- ZooKeeper的通路控制
- Watcher(監聽器)
ZooKeeper服務概覽
ZooKeeper是一個複制式的分布式應用，有點像DNS服務或一些中心化的服務。
ZooKeeper服務架構
這是官網給的ZooKeeper服務圖，所有組成ZooKeeper服務的伺服器都互相知曉，它們維護了一個記憶體狀态的鏡像，也包含事務日志，持久存儲的快照等。隻要半數以上的的伺服器是可用的，ZooKeeper服務就是可用的。
順便提一下ZooKeeper的設計目标(Design Goals)
- 簡單
- 複制式的 所有節點互相複制狀态
- 有序的，所有的事務都有時間戳
- 快速 在讀大于寫的時候...
ZooKeeper讀寫圖
ZooKeeper在讀資料的時候可以直接從目前節點讀取資料，在寫資料的時候需要将寫請求轉發到Leader節點上。
ZooKeeper資料模型
ZooKeeper的各個伺服器節點共同維護一個可以注冊資料的層級結構，類似于Unix的檔案系統。資料注冊的位置也稱為
znode
。
Znode圖
注意：
- 資料節點一般以位元組形式存儲，節點存儲的資料大小最大不超過1MB。協作的資料一般不會太大。最好讓資料遠小于1MB會好些。
- ZooKeeper無法識别相對路徑。 znode的路徑必須是絕對路徑
- 每個Znode除了存儲資料以外，還有維護一些狀态資訊。
Znode 特性
Znode類型
ZooKeeper主要有兩種節點類型，也可以說是三種。持久節點，臨時節點。第三個是順序節點，順序節點也可以說是剛才那兩種節點。 持久節點和順序節點都可以是順序節點。
注意節點的類型是在建立的時候就設定好的。
- 持久節點。ZooKeeper中最常見的一種節點類型，建立之後一直存在伺服器上，知道有删除操作來主動清楚這個節點
- 臨時節點，與用戶端會話綁定在一起。 用戶端會話失效，節點自動清理。(網絡突然壞掉不算會話失效)
- 順序節點，在節點建立的時候，ZooKeeper自動給節點名配置設定一個序列号。例如/path/to/znode-0000000001，一般是10位數字，序号之外的位以0填充。
節點狀态
每一個Znode都有對應的stat結構，和檔案系統類似。stat狀态主要包含下面的資訊：
- cZxid. 節點被建立時候的事務ID
- mZxid 節點最後一次被修改時候的事務ID
- pZxid 該節點的子節點最後一次被修改時的事務ID。子節點删除或添加才會影響pZxid
- ctime 節點被建立的時間
- mtime 節點被修改的世界
- dataVersion 這個節點資料改變的次數
- cversion 子節點被改變的次數
- aclVersion 節點的ACL(通路控制清單被改變的次數)
- ephemeralOwner 建立該臨時節點的 session ID。如果是持久節點，設定為0
- dataLength 資料内容長度
- numChildren 目前節點子節點的個數
可以使用
ls2
和
stat
指令檢視ZooKeeper節點下的資訊。
指令示範
ZooKeeper的通路控制(ACL)
ZooKeeper的資料模型提供了ACL來控制znode節點的通路。如果一個用戶端符合ACL控制，那麼就可以對其進行通路，否則将無法操作。
Zookeeper支援可配置的認證機制。它利用一個三元組來定義用戶端的通路權限：
(scheme:expression, perms) 。其中：
- Schema 代表權限控制模式，分别為
- World 任何人
- Auth 不需要ID
- Digest 使用者名和密碼方式的認證
- IP Address IP位址方式的認證
- perms(權限)，ZooKeeper支援如下權限
- CREATE: 建立子節點
- READ： 擷取子節點與自身節點的資料資訊
- WRITE：在Znode節點上寫資料
- DELETE：删除子節點
- ADMIN：設定ACL權限
貼上如下圖，在下次使用ZooKeeper的時候更明白，這次我們主要說明一些ZooKeeper理論方面的知識，具體程式設計的實作下次再說。
ACL圖
權限模式和授權對象的關系：
- IP: 通常是IP位址或是IP端，例如"192.168.1.2"或"192.168.1.1/24"
- Degist: 自定義，通常是"username:BASE64(SHA-1(username:password))"
- World：隻有一個ID，“anyone”
- Super: 與Degist模式一緻
- Znode的Acl隻是針對某個節點，不會作用到它的子節點上
- 任何連接配接到ZooKeeper的用戶端都可以使用exist操作，exist是不需要權限的。
ZooKeeper的Watcher
ZooKeeper中引入了Watcher機制來實作分布式通知功能，ZooKeeper允許用戶端像服務端注冊一個Watcher監聽，當服務端的一些指定事件觸發了這個Watcher，那麼就會向指定用戶端發送一個事件通知來實作分布式的通知功能。
有如下的Watcher事件類型可能出現：
- NodeChildrenChanged: zNode的子節點建立或删除的時候
- NodeCreated: 新的Znode節點被建立的時候
- NodeDataChanged: Znode節點的資料改變了的時候
- NodeDeleted: Znode節點被删除的時候。
關于Watcher内部實作機制，下次可以通過分析其源碼進行更詳細的說明
最後
這次主要介紹了一些ZooKeeper内部的基本概念，理論部分較多，若無理論的基礎實施接下來的操作也不太友善。
接下來我會寫下：
- ZooKeeper 用戶端程式設計
- ZooKeeper Watcher監聽器原理分析
參考
- 《從Paxos到ZooKeeper-分布式一緻性原理與實踐》
- 《Apache ZooKeeper Essential》
- ZooKeeper Overview