【推薦】2019 Java 開發者跳槽指南.pdf(吐血整理) >>> 
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框架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 方式進行入隊和出隊操作。
第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。
第二類，和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。 同步隊列的流程圖：
