zookeeper初識

ZooKeeper是一個分佈式、開源的分佈式應用協調服務。

設計目標

簡單的數據模型

在ZooKeeper中，分佈式進程之間的相互協調，是經過相似於標準文件系統的層次命名空間的（圖以下）。相似於文件和目錄，每一個組成部分稱之爲znode，znode是zookeeper中的最小數據單位，可是與存儲的文件系統不一樣的是，這些數據是存在於內存的，因此ZooKeeper能夠實現高吞吐量和低延遲。
另一個不一樣的是，節點既能夠有本身的數據，也能夠有本身的子節點，在存儲系統中，是不可能本身既是目錄，仍是文件的。Znode中有一個stat結構，其中包含數據更改、ACL更改和時間戳的版本號，以容許緩存驗證和協調更新。
節點有4種類型：

1. 持久化節點：永久保存在服務器上，除非主動刪除
2. 持久化有序節點：節點的名稱後加入有序的數字，相似自增加id
3. 臨時節點：在會話時間內保持，相似web項目的session
4. 臨時有序節點：臨時節點的名稱後加入有序的數字，相似自增加id

可複製

這個特性，支持他能夠作集羣，只要大多數服務是可用的，那ZooKeeper就是可用的。

客戶端鏈接ZooKeeper服務時，須要知道每一個ZooKeeper的地址。當客戶端鏈接到單個ZooKeeper時，會維護一個TCP鏈接，經過它發送請求、獲取響應、獲取監視事件和發送心跳。若是到服務器的TCP鏈接中斷，客戶端將鏈接到另外一臺服務器。

有序

ZooKeeper用一個數字來標記每一個更新，這個數字反映了全部ZooKeeper事務的順序。

快

數據是存在於內存的，因此ZooKeeper能夠實現高吞吐量和低延遲。

特色

1. 順序一致性：客戶端發起的事務請求，在也會順序的應用在Zookeeper中。
2. 原子性：要麼在全部的Zookeeper中都成功，要麼都失敗，不會有部分紅功，部分失敗的狀況。
3. 單一鏡像：無論連的是哪一個服務器，客戶端讀取的數據是同樣的
4. 可靠性：一旦事務成功提交，那就會保留下來
5. 及時性：客戶端在必定範圍時間內，讀取的數據是同樣的

Watcher

事件監聽器。客戶端能夠在znode上設置監聽，當znode發生變化時，這個監聽就會被移除，而後客戶端就會收到通知。要想不停的監聽，就須要繼續註冊。

ACL

控制節點訪問權限

1. CREATE：建立子節點的權限
2. DELETE：能夠刪除子節點（僅下一級節點）
3. WRITE：更新子節點的權限
4. READ：讀取節點數據及顯示子節點列表
5. ADMIN：設置節點ACL權限