上一篇文章我們詳細介紹了mapreduce計算框架，此時你已經瞭解hadoop集羣的數據處理方式，接下來我們講解
分佈式的，開源的，應用於分佈式應用的協作服務的--Zookeeper。
衆所周知，分佈式的系統協作服務很難有讓人滿意的產品。這些協作服務產品很容易陷入一些諸如競爭選擇條件或者死鎖的陷阱中。那Zookeeper又是怎麼解決這個問題的呢？
Zookeeper提供了一些簡單的操作，使得分佈式應用可以基於這些接口實現諸如同步、配置維護和分集羣或者命名的服務。Zookeeper很容易編程接入，它使用了一個和文件樹結構相似的數據模型。可以使用Java或者C來進行編程接入。它的目的就是將分佈式服務不再需要由於協作衝突而另外實現協作服務。
本篇內容：
1) Zookeeper數據模型
2) Zookeeper訪問控制
3) Zookeeper應用場景
1. Zookeeper數據模型
ZooKeeper擁有一個層次的命名空間，這個和標準的文件系統非常相似
從圖中我們可以看出ZooKeeper的數據模型，在結構上和標準文件系統的非常相似，都是採用這種樹形層次結構，ZooKeeper樹中的每個節點被稱爲—Znode。和文件系統的目錄樹一樣，ZooKeeper樹中的每個節點可以擁有子節點。但也有不同之處：
1) 引用方式:
Zonde通過路徑引用，如同Unix中的文件路徑。路徑必須是絕對的，因此他們必須由斜槓字符來開頭。除此以外，他們必須是唯一的，也就是說每一個路徑只有一個表示，因此這些路徑不能改變。在ZooKeeper中，路徑由Unicode字符串組成，並且有一些限制。字符串"/zookeeper"用以保存管理信息，比如關鍵配額信息。
2) Znode結構
ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特點。既像文件一樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄一樣可以作爲路徑標識的一部分。圖中的每個節點稱爲一個Znode。 每個Znode由3部分組成:
l stat：此爲狀態信息, 描述該Znode的版本, 權限等信息
l data：與該Znode關聯的數據
l children：該Znode下的子節點
ZooKeeper雖然可以關聯一些數據，但並沒有被設計爲常規的數據庫或者大數據存儲，相反的是，它用來管理調度數據，比如分佈式應用中的配置文件信息、狀態信息、彙集位置等等。這些數據的共同特性就是它們都是很小的數據，通常以KB爲大小單位。ZooKeeper的服務器和客戶端都被設計爲嚴格檢查並限制每個Znode的數據大小至多1M，但常規使用中應該遠小於此值。
3) 數據訪問
ZooKeeper中的每個節點存儲的數據要被原子性的操作。也就是說讀操作將獲取與節點相關的所有數據，寫操作也將替換掉節點的所有數據。另外，每一個節點都擁有自己的ACL(訪問控制列表)，這個列表規定了用戶的權限，即限定了特定用戶對目標節點可以執行的操作。
4) 節點類型
Persistent Nodes：永久有效地節點,除非client顯式的刪除,否則一直存在。
Ephemeral Nodes：臨時節點,僅在創建該節點client保持連接期間有效,一旦連接丟失,zookeeper會自動刪除該節點。
Sequence Nodes：順序節點,client申請創建該節點時, ZooKeeper會自動在節點路徑末尾添加遞增序號,這種類型是實現分佈式鎖,分佈式queue等特殊功能的關鍵。
5) 監控
客戶端可以在節點上設置watch，我們稱之爲監視器。當節點狀態發生改變時(Znode的增、刪、改)將會觸發watch所對應的操作。當watch被觸發時，ZooKeeper將會向客戶端發送且僅發送一條通知，因爲watch只能被觸發一次，這樣可以減少網絡流量。
ZooKeeper可以爲所有的讀操作設置watch，這些讀操作包括：exists()、getChildren()及getData()。watch事件是一次性的觸發器，當watch的對象狀態發生改變時，將會觸發此對象上watch所對應的事件。watch事件將被異步地發送給客戶端，並且ZooKeeper爲watch機制提供了有序的一致性保證。理論上，客戶端接收watch事件的時間要快於其看到watch對象狀態變化的時間。
2. Zookeeper訪問控制
傳統的文件系統中，ACL分爲兩個維度，一個是屬組，一個是權限，子目錄/文件默認繼承父目錄的ACL。而在Zookeeper中，node的ACL是沒有繼承關係的，是獨立控制的。Zookeeper的ACL，可以從三個維度來理解：一是scheme; 二是user; 三是permission，通常表示爲scheme:id:permissions, 下面從這三個方面分別來介紹：
1) scheme: scheme對應於採用哪種方案來進行權限管理，zookeeper實現了一個pluggable的ACL方案，可以通過擴展scheme，來擴展ACL的機制。
模式 | 描述 |
World | 它下面只有一個id, 叫anyone, world:anyone代表任何人，zookeeper中對所有人有權限的結點就是屬於world:anyone的 |
Auth | 已經被認證的用戶 |
Digest | 通過username：password字符串的MD5編碼認證用戶 |
Host | 匹配主機名後綴，如，host:corp.com匹配host:host1.corp.com, host:host2.corp.com，但不能匹配host:host1.store.com |
IP | 通過IP識別用戶，表達式格式爲 addr/bits |
2) User：與scheme是緊密相關的，具體的情況在上面介紹scheme的過程都已介紹，這裏不再贅述。
3) permission: zookeeper目前支持下面一些權限：
權限 | 描述 | 備註 |
Create | 有創建子節點的權限 | |
Read | 有讀取節點數據和子節點列表的權限 | |
Write | 有修改節點數據的權限 | 無創建和刪除子節點的權限 |
Delete | 有刪除子節點的權限 | |
Admin | 有設置節點權限的權限 |
3. Zookeeper應用場景
1) 數據發佈與訂閱（配置中心）
發佈與訂閱模型，即所謂的配置中心，顧名思義就是發佈者將數據發佈到ZK節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，服務式服務框架的服務地址列表等就非常適合使用。
2) 分佈式鎖服務
分佈式鎖，這個主要得益於ZooKeeper爲我們保證了數據的強一致性。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。
3) 分佈式隊列
隊列方面，簡單地講有兩種，一種是常規的先進先出隊列，另一種是要等到隊列成員聚齊之後的才統一按序執行。對於第一種先進先出隊列，和分佈式鎖服務中的控制時序場景基本原理一致，這裏不再贅述。 第二種隊列其實是在FIFO隊列的基礎上作了一個增強。
通常可以在 /queue 這個znode下預先建立一個/queue/num 節點，並且賦值爲n（或者直接給/queue賦值n），表示隊列大小，之後每次有隊列成員加入後，就判斷下是否已經到達隊列大小，決定是否可以開始執行了。這種用法的典型場景是，分佈式環境中，一個大任務Task A，需要在很多子任務完成（或條件就緒）情況下才能進行。
這個時候，凡是其中一個子任務完成（就緒），那麼就去 /taskList 下建立自己的臨時時序節點（CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。
此時你已經學會了安裝hadoop集羣，瞭解了HDFS文件系統，MapReduce計算框架和Zookeeper協作服務（Zookeeper數據模型、訪問控制、應用場景），下一篇文章會繼續介紹高可靠的分佈式存儲系統--HBase 。
此時，你已經掌握了hadoop的半壁江山。
如何用4個月學會Hadoop開發並找到年薪25萬工作？
免費分享一套17年最新Hadoop大數據教程和100道Hadoop大數據必會面試題。
因爲鏈接經常被和諧，需要的朋友請加微信 ganshiyun666 來獲取最新下載鏈接，註明“51CTO”
教程已幫助300+人成功轉型Hadoop開發，90%起薪超過20K，工資比之前翻了一倍。
百度Hadoop核心架構師親自錄製
內容包括0基礎入門、Hadoop生態系統、真實商業項目實戰3大部分。其中商業案例可以讓你接觸真實的生產環境，訓練自己的開發能力。
