發自簡書
- ZooKeeper定義
- ZooKeeper在產品的位置
- 系統架構
- 關鍵特性介紹
- 與組件的關系
1、Zookeeper定義
Zookeeper 分布式服務框架主要是用來解決分布式應用中經常遇到的一些數據管理問題，提供分布式、高可用性的協調服務能力,在FusionInsight集群中主要用途是保存上層組件的元數據，并保證其主備倒換。
2、ZooKeeper在產品的位置
3、ZooKeeper服務架構
模型
1.分布式地分布在一組機器中
2.所有節點存儲整份數據（在內存也在硬盤）
3.在啟動時候選舉出Leader
4.Leader會做原子廣播到所有其他節
5.嚴格的順序訪問控制6.不會部分讀寫
容災能力
一般情況下，ZooKeeper能夠完成選舉即能夠正常對外提供服務。
ZooKeeper選舉時，當某一個實例獲得了半數以上的票數時，則變為
leader。
對于n個實例的服務，n可能為奇數或偶數
n為奇數時，假定n=2x+1，則成為leader的節點需獲得x+1票，容災能
力為x
n為偶數時，假定n=2x+2，則成為leader的節點需要獲得x+2票（大于一半），容災能力為x。
由此可見，2x+1個節點與2x+2個節點的容災能力相同（3個與4個相同，5
個與6個相同…），而考慮到選舉以及完成寫操作的速度與節點數的相關性，我們建議ZooKeeper部署奇數個節點。
ZooKeeper數據模型
- 分層命名空間
- 每個命名空間的節點都叫做“znode”
- 每個znode被路徑區分（如：/app1）
- znode節點類型– 永久節點和臨時節
點
5.臨時節點不能有子節點
6.每個znode節點有數據，也可以選擇
有子節點 - znode不能被重命名
-
可以給znode增加或者刪除watchers
4、關鍵特性
最終一致性：無論哪個server，對外展示的均是同一個視圖。
實時性：保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或
者服務器失效的信息。
可靠性：一條消息被一個server接收，它將被所有server接受。
等待無關性：慢的或者失效的client不得干預快速的client的請求，使得每
個client都能有效的等待。
原子性：更新只能成功或者失敗，沒有中間狀態。
順序性：客戶端的更新順序與它們被發送的順序相一致。
讀特性
由ZooKeeper的一致性可知，客戶端無論連接哪個server，獲取的均是同一個視圖。所以，讀操作可以在客戶端與任意節點間完成。
寫特性
ACL（訪問控制列表）
ACL可以控制訪問ZooKeeper的節點，只能應用于特定的znode上，而不能應用于該znode的所有子節點上。設置ACL命令為 setAcl /znode scheme:id:perm
Scheme為認證方式， ZooKeeper內置了4種方式：
world 一個單獨的ID，表示任何人都可以訪問
auth 不使用ID，只有認證的用戶可以訪問
digest 使用username:password生成MD5哈希值作為認證ID
IP 使用客戶端主機IP地址來進行認證
Id：用來認證的字段，用來判斷認證信息是否合法，不同的scheme的認證方式不同。
Perm：即permission，通過Acl認證的用戶對該節點可擁有的操作權限
日志增強
Ephemeral node（臨時節點）在session過期之后就會被系統刪除，
在審計日志中添加Ephemeral node被刪除的審計日志，以便了解
當時Ephemeral node的狀態信息。
客戶端常用命令使用
調用ZooKeeper客戶端，執行命令：
sh zkCli.sh –server 172.0.0.1:24002
執行創建節點，設置ACL，查詢ACL，查詢節點值，刪除節點操作。
創建節點：create /node
獲取節點子節點： ls /node
設置Acl：setAcl /node sasl:admin@HADOOP.COM:cdrwa
查詢節點Acl： getAcl /node
創建節點數據: set /node data
獲取節點數據: get /node
刪除節點：delete /node
刪除節點及所有子節點: deleteall /node
5、與組件的關系
ZooKeeper和Storm Nimbus HA的配合關系
Storm Nimbus利用zookeeper來選主。ZooKeeper提供了以下兩種能力：
? 分布式鎖服務多個Nimbus進程都嘗試著去ZooKeeper中寫入一個對應的節點，該節點只能被一個Nimbus進程創建成功，創建成功的Nimbus進程成為主Nimbus。
? 事件偵聽機制--watcher。 備Nimbus在偵聽那個對應的ZooKeeper節點。主Nimbus進程宕掉之后，該節點會被刪除，那么，備Nimbus就可以收到相應的消息。
ZooKeeper和HDFS的配合關系
ZKFC（ZKFailoverController）作為一個ZooKeeper集群的客戶端，用來監控NameNode的狀態信息。ZKFC進程僅在部署了NameNode的節點中存在。HDFS
NameNode的Active和Standby節點均部署有zkfc進程：
? HDFS NameNode的ZKFC連接到ZooKeeper，把主機名等信息保存到ZooKeeper中，即“/hadoop-ha”下的znode目錄里。先創建znode目錄的NameNode節點為主節點，另一個為備節點。HDFS NameNode Standby通過ZooKeeper定時讀取NameNode信息。
? 當主節點進程異常結束時，HDFS NameNode Standby通過ZooKeeper感知“/hadoop-ha”目錄下發生了變化。
ZooKeeper和YARN的配合關系
? 在系統啟動時，ResourceManager會嘗試把選舉信息寫入ZooKeeper，第一個成功把寫入ZooKeeper的ResourceManager被選舉為Active
ResourceManager，另一個為StandbResourceManager。Standby
ResourceManager定時去ZooKeeper監控Active ResourceManager選舉信息。
? Active ResourceManager還會在ZooKeeper中創建Statestore目錄，存儲Application相關信息。當Active ResourceManager產生故障時，Standby ResourceManager會從Statestore目錄獲取Application相關信息，恢復數據并升為Active。
ZooKeeper和HBase的配合關系
? HRegionServer把自己以Ephemeral方式注冊到ZooKeeper中。其中ZooKeeper存儲HBase的如下信息：HBase元數據、HMaster地址。? HMaster通過ZooKeeper隨時感知各個HRegionServer的健康狀況，以便進行控制管理。
? HBase也可以部署多對HMaster類似HDFS NameNode，當HMaster主節點出現故障時，HMaster備用節點會通過ZooKeeper獲取主HMaster存儲的整個HBase集群狀態信息。即通過ZooKeeper實現避免HBase單點故障問題。
思考
1 ZooKeeper在集群中的位置及作用是什么？
2 ZooKeeper節點結構是什么樣子？節點類型有哪些？
3 ZooKeeper為什么建議奇數部署？
4 ZooKeeper一致性的含義是什么？
