資料複製的好處

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框架Curator對於分散式鎖的實現，但可以自己思考一下如何實現。

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

一個是讀寫鎖，對寫加鎖，保持獨佔，或者叫做排它鎖，獨佔鎖；對讀加鎖，可共享訪問，釋放鎖之後才可進行事務操作，也叫共享鎖

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

　　對於獨佔鎖，我們將 ZooKeeper 上的一個 znode 看作是一把鎖，通過 createznode 的方式來 實現。對於獨佔鎖，所有客戶端都去建立臨時目錄（臨時且節點路徑會加上序號）節點/Locks/write，最終成功建立最小序號/Locks/write節點的那個客戶端即擁有了這把鎖，用完刪除掉自己建立的節點就釋放出鎖，然後下一個序號的節點就可以獲取鎖。對於共享鎖，可以思考如何實現，共享鎖要保證不能和獨佔鎖共存，如果有某個程序持有獨佔鎖，那麼所有的獨佔鎖或共享鎖都不能獲取，如果沒有獨佔鎖被某個程序持有，那麼持有共享鎖的程序都可以併發執行，獨佔鎖必須等待所有共享鎖全部釋放後才能獲取。

對於共享鎖，我有一個實現思路是，全部建立/locks/readwritelock路徑的臨時目錄節點，然後對於寫鎖的節點，執行create /locks/readwritelock write，而讀鎖執行create /locks/readwritelock read，通過序號最小的節點的儲存的字串是read還是write來確定某個執行緒持有鎖實寫鎖還是讀鎖；如果第一個節點是寫鎖，那麼其餘節點對應的所有執行緒都不得持有鎖，得進入執行緒等待狀態。如果是讀鎖，那麼從第一個節點開始遍歷，直到一個請求寫鎖的節點之前的所有節點對應的執行緒都可以獲取讀鎖並且許可權。路徑下儲存的資料不一定是字串，用數字代替也可以。

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

設計鎖時，一定要保證鎖的釋放，所以一般都會將節點設定為臨時節點，保證即使客戶端未釋放鎖（刪除節點）就異常終止，也能讓其他程式獲取到鎖，避免死鎖。

佇列管理

　　兩種型別的佇列：

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

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

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

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

相關推薦