目錄

正文

回到頂部

ZooKeeper 特點/設計目的

ZooKeeper 作為一個叢集提供資料一致的協調服務，自然，最好的方式就是在整個叢集中的 各服務節點進行資料的複製和同步。

資料複製的好處

1、容錯：一個節點出錯，不至於讓整個叢集無法提供服務

2、擴充套件性：通過增加伺服器節點能提高 ZooKeeper 系統的負載能力，把負載分佈到多個節點上

3、高效能：客戶端可訪問本地 ZooKeeper 節點或者訪問就近的節點，依次提高使用者的訪問速度

設計目的

1、最終一致性：client不論連線到哪個Server，展示給它都是同一個檢視，這是zookeeper最重要的效能。 
2、可靠性：具有簡單、健壯、良好的效能，如果訊息被到一臺伺服器接受，那麼它將被所有的伺服器接受。 
3、實時性：Zookeeper保證客戶端將在一個時間間隔範圍內獲得伺服器的更新資訊，或者伺服器失效的資訊。但由於網路延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。 
4、等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。 
5、原子性：更新只能成功或者失敗，沒有中間狀態。 
6、順序性：包括全域性有序和偏序兩種：全域性有序是指如果在一臺伺服器上訊息a在訊息b前釋出，則在所有Server上訊息a都將在訊息b前被髮布；偏序是指如果一個訊息b在訊息a後被同一個傳送者釋出，a必將排在b前面。 

回到頂部

ZooKeeper 典型應用場景

命名服務

　　命名服務是分散式系統中較為常見的一類場景，分散式系統中，被命名的實體通常可以是集 群中的機器、提供的服務地址或遠端物件等，通過命名服務，客戶端可以根據指定名字來獲 取資源的實體、服務地址和提供者的資訊。Zookeeper 也可幫助應用系統通過資源引用的方 式來實現對資源的定位和使用，廣義上的命名服務的資源定位都不是真正意義上的實體資源， 在分散式環境中，上層應用僅僅需要一個全域性唯一的名字。Zookeeper 可以實現一套分散式 全域性唯一 ID 的分配機制。

配置管理

　　程式總是需要配置的，如果程式分散部署在多臺機器上，要逐個改變配置就變得困難。現在 把這些配置全部放到 ZooKeeper 上去，儲存在 ZooKeeper 的某個目錄節點中，然後所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 ZooKeeper 的通知，然後從 ZooKeeper 獲取新的配置資訊應用到系統中就好

叢集管理

所謂叢集管理無在乎兩點：是否有機器退出和加入、選舉 master。

　　對於第一點，所有機器約定在父目錄 GroupMembers 下建立臨時目錄節點，然後監聽父目錄 節點的子節點變化訊息。一旦有機器掛掉，該機器與 ZooKeeper 的連線斷開，其所建立的 臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知 道：有兄弟掛了。新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，又多了個新 兄弟。

　　對於第二點，我們稍微改變一下，所有機器建立臨時順序編號目錄節點，每次選取編號最小 的機器作為 master 就好。當然，這只是其中的一種策略而已，選舉策略完全可以由管理員 自己制定。

分散式鎖

有了 ZooKeeper 的一致性檔案系統，鎖的問題變得容易。 鎖服務可以分為兩三類

一個是寫鎖，對寫加鎖，保持獨佔，或者叫做排它鎖，獨佔鎖

一個是讀鎖，對讀加鎖，可共享訪問，釋放鎖之後才可進行事務操作，也叫共享鎖

一個是控制時序，叫時序鎖

　　對於第一類，我們將 ZooKeeper 上的一個 znode 看作是一把鎖，通過 createznode 的方式來 實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了 這把鎖。用完刪除掉自己建立的 distribute_lock 節點就釋放出鎖

　　對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面建立臨時順序編號目錄 節點，和選 master 一樣，編號最小的獲得鎖，用完刪除，依次有序

佇列管理

　　兩種型別的佇列：

　　1、同步佇列：當一個佇列的成員都聚齊時，這個佇列才可用，否則一直等待所有成員到達。

　　2、先進先出佇列：佇列按照 FIFO 方式進行入隊和出隊操作。

　　第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是否是我們要求的數目。

　　第二類，和分散式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。 同步佇列的流程圖：