Zookeeper的基礎知識

1.Zookeeper是什麼？

引用官方的說法：「Zookeeper是一個高性能，分佈式的，開源分佈式應用協調服務。它提供了簡單原始的功能，分佈式應用能夠基於它實現更高級 的服務。它被設計爲易於編程，使用文件系統目錄樹做爲數據模型。服務端跑在java上，提供java和C的客戶端 API」。

zookeeper能夠用來作什麼

集羣服務，統一命名服務，分佈式配置管理，分佈式消息隊列，分佈式鎖，分佈式通知協調等。

2.Zookeeper整體結構

Leader/Follower

ZooKeeper須要在全部的服務（能夠理解爲服務器）中選舉出一個Leader，而後讓這個Leader來負責管理集羣。此時，集羣中的其它服務器則成爲此Leader的Follower。而且，當Leader故障的時候，須要ZooKeeper可以快速地在Follower中選舉出下一個Leader。

Observer

Observer是zk集羣的另外一個角色， observer的行爲在大多數狀況下與follower徹底一致, 可是他們不參加選舉和投票, 而僅僅接受(observing)選舉和投票的結果.

Zookeeper邏輯圖以下：

如上圖所示，假設搭建了一個5臺server的集羣，5臺機器根據選舉算法，選出一個leader，其餘節點就是follower。

選舉好leader後會和每一個server創建長鏈接

修改操做：當某個節點收到修改操做時，就會將請求轉發給leader，leader有處理機制，修改後同步到每個follower。

zookeeper集羣搭建完成就能夠啓動客戶端，客戶端能夠鏈接除leader外的全部節點，創建長鏈接，客戶端任何修改信息都會同步到server上，由leader同步到各個節點

選舉：當leader掛掉後就會選舉一個新的leader，而後再從新創建鏈接。完成一次選舉大概須要200ms。

zookeeper中的概念

ZNode
zookeeper目錄樹中每個節點對應一個Znode。每一個Znode維護着一個屬性結構，它包含着版本號(dataVersion)，時間戳(ctime,mtime)等狀態信息。ZooKeeper正是使用節點的這些特性來實現它的某些特定功能。每當Znode的數據改變時，他相應的版本號將會增長。每當客戶端檢索數據時，它將同時檢索數據的版本號。而且若是一個客戶端執行了某個節點的更新或刪除操做，他也必須提供要被操做的數據版本號。若是所提供的數據版本號與實際不匹配，那麼這個操做將會失敗。

Session
Client與ZooKeeper之間的通訊，須要建立一個Session，這個Session會有一個超時時間。由於ZooKeeper集羣會把Client的Session信息持久化，因此在Session沒超時以前，Client與ZooKeeper Server的鏈接能夠在各個ZooKeeper Server之間透明地移動。

在實際的應用中，若是Client與Server之間的通訊足夠頻繁，Session的維護就不須要其它額外的消息了。不然，ZooKeeper Client會每t/3 ms發一次心跳給Server，若是Client 2t/3 ms沒收到來自Server的心跳回應，就會換到一個新的ZooKeeper Server上。這裏t是用戶配置的Session的超時時間。

Watcher
ZooKeeper支持一種Watch操做，Client能夠在某個ZNode上設置一個Watcher，來Watch該ZNode上的變化。若是該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設置Watcher的Client。

3.Zookeeper數據模型

zookeeper文件系統

zookeeper維護一個相似文件系統的數據結構

Zookeeper表現爲一個分層的文件系統目錄樹結構（不一樣於文件系統的是，節點能夠有本身的數據，而文件系統中的目錄節點只有子節點）。

由根目錄和各個子目錄組成，每個子目錄稱爲znode，znode相似文件夾，可是znode能夠存儲數據

znode分爲4中類型

1.持久化節點

所謂持久節點，是指在節點建立後，就一直存在，直到有刪除操做來主動清除這個節點——不會由於建立該節點的客戶端會話失效而消失。

2.持久化順序節點

這類節點的基本特性和上面的節點類型是一致的。額外的特性是，在ZK中，每一個父節點會爲他的第一級子節點維護一份時序，會記錄每一個子節點建立的前後順序。基於這個特性，在建立子節點的時候，能夠設置這個屬性，那麼在建立節點過程當中，ZK會自動爲給定節點名加上一個數字後綴，做爲新的節點名。這個數字後綴的範圍是整型的最大值。

3.臨時節點

這類節點的基本特性和上面的節點類型是一致的。額外的特性是，在ZK中，每一個父節點會爲他的第一級子節點維護一份時序，會記錄每一個子節點建立的前後順序。基於這個特性，在建立子節點的時候，能夠設置這個屬性，那麼在建立節點過程當中，ZK會自動爲給定節點名加上一個數字後綴，做爲新的節點名。這個數字後綴的範圍是整型的最大值。

4.臨時順序節點

能夠用來實現分佈式鎖

客戶端調用create()方法建立名爲「_locknode_/guid-lock-」的節點，須要注意的是，這裏節點的建立類型須要設置爲EPHEMERAL_SEQUENTIAL。
客戶端調用getChildren(「_locknode_」)方法來獲取全部已經建立的子節點，注意，這裏不註冊任何Watcher。
客戶端獲取到全部子節點path以後，若是發現本身在步驟1中建立的節點序號最小，那麼就認爲這個客戶端得到了鎖。
若是在步驟3中發現本身並不是全部子節點中最小的，說明本身尚未獲取到鎖。此時客戶端須要找到比本身小的那個節點，而後對其調用exist()方法，同時註冊事件監聽。
以後當這個被關注的節點被移除了，客戶端會收到相應的通知。這個時候客戶端須要再次調用getChildren(「_locknode_」)方法來獲取全部已經建立的子節點，確保本身確實是最小的節點了，而後進入步驟3。

通知機制

ZooKeeper支持一種Watch操做，Client能夠在某個ZNode上設置一個Watcher，來Watch該ZNode上的變化。若是該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設置Watcher的Client。須要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，若是想繼續Watch的話，須要客戶端從新設置Watcher。這個跟epoll裏的oneshot模式有點相似。