Zookeeper原理架構

Zookeeper究竟是什麼！？

學一個東西，不搞明白他是什麼東西，哪還有心情學啊！！ 
首先，Zookeeper是Apache的一個java項目，屬於Hadoop系統，扮演管理員的角色。 
而後看到官網那些專有名詞，實在理解不了。

在Zookeeper的官網上有這麼一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

那麼咱們來仔細研究一下這個東西吧！

Zookeeper能幹嗎？！

1. 配置管理

這個好理解。分佈式系統都有好多機器，好比我在搭建hadoop的HDFS的時候，須要在一個主機器上（Master節點）配置好HDFS須要的各類配置文件，而後經過scp命令把這些配置文件拷貝到其餘節點上，這樣各個機器拿到的配置信息是一致的，才能成功運行起來HDFS服務。Zookeeper提供了這樣的一種服務：一種集中管理配置的方法，咱們在這個集中的地方修改了配置，全部對這個配置感興趣的均可以得到變動。這樣就省去手動拷貝配置了，還保證了可靠和一致性。 

2. 名字服務

這個能夠簡單理解爲一個電話薄，電話號碼很差記，可是人名好記，要打誰的電話，直接查人名就行了。 
分佈式環境下，常常須要對應用/服務進行統一命名，便於識別不一樣服務； 
相似於域名與ip之間對應關係，域名容易記住； 
經過名稱來獲取資源或服務的地址，提供者等信息

3. 分佈式鎖

碰到分佈二字貌似就難理解了，其實很簡單。單機程序的各個進程須要對互斥資源進行訪問時須要加鎖，那分佈式程序分佈在各個主機上的進程對互斥資源進行訪問時也須要加鎖。不少分佈式系統有多個可服務的窗口，可是在某個時刻只讓一個服務去幹活，當這臺服務出問題的時候鎖釋放，當即fail over到另外的服務。這在不少分佈式系統中都是這麼作，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。舉個通俗點的例子，好比銀行取錢，有多個窗口，可是呢對你來講，只能有一個窗口對你服務，若是正在對你服務的窗口的櫃員忽然有急事走了，那咋辦？找大堂經理（zookeeper）!大堂經理指定另外的一個窗口繼續爲你服務！

4. 集羣管理

在分佈式的集羣中，常常會因爲各類緣由，好比硬件故障，軟件故障，網絡問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集羣。這個時候，集羣中有些機器（好比Master節點）須要感知到這種變化，而後根據這種變化作出對應的決策。我已經知道HDFS中namenode是經過datanode的心跳機制來實現上述感知的，那麼咱們能夠先假設Zookeeper其實也是實現了相似心跳機制的功能吧！

Zookeeper的特色

1 最終一致性：爲客戶端展現同一視圖，這是zookeeper最重要的功能。 
2 可靠性：若是消息被到一臺服務器接受，那麼它將被全部的服務器接受。 
3 實時性：Zookeeper不能保證兩個客戶端能同時獲得剛更新的數據，若是須要最新數據，應該在讀數據以前調用sync()接口。 
4 等待無關（wait-free）：慢的或者失效的client不干預快速的client的請求。 
5 原子性：更新只能成功或者失敗，沒有中間狀態。 
6 順序性：全部Server，同一消息發佈順序一致。

用到Zookeeper的系統

HDFS中的HA方案 
YARN的HA方案 
HBase：必須依賴Zookeeper，保存了Regionserver的心跳信息，和其餘的一些關鍵信息。 
Flume：負載均衡，單點故障

Zookpeeper的基本架構

 
1 每一個Server在內存中存儲了一份數據； 
2 Zookeeper啓動時，將從實例中選舉一個leader（Paxos協議）； 
3 Leader負責處理數據更新等操做（Zab協議）； 
4 一個更新操做成功，當且僅當大多數Server在內存中成功修改 
數據。 

Zookpeeper Server 節點的數目

Zookeeper Server數目通常爲奇數 
Leader選舉算法採用了Paxos協議；Paxos核心思想：當多數Server寫成功，則任務數據寫 
成功。也就是說： 
若是有3個Server，則兩個寫成功便可； 
若是有4或5個Server，則三個寫成功便可。 
Server數目通常爲奇數（三、五、7） 
若是有3個Server，則最多容許1個Server掛掉； 
若是有4個Server，則一樣最多容許1個Server掛掉 
既然如此，爲啥要用4個Server？

Observer節點

3.3.0 之後 版本新增角色Observer 
增長緣由： 
Zookeeper需保證高可用和強一致性； 
當集羣節點數目逐漸增大爲了支持更多的客戶端，須要增長更多Server，然而Server增多，投票階段延遲增大，影響性能。爲了權衡伸縮性和高吞吐率，引入Observer： 
Observer不參與投票； 
Observers接受客戶端的鏈接，並將寫請求轉發給leader節點； 
加入更多Observer節點，提升伸縮性，同時不影響吞吐率。

Zookeeper寫流程：

 
客戶端首先和一個Server或者Observe（能夠認爲是一個Server的代理）通訊，發起寫請求，而後Server將寫請求轉發給Leader，Leader再將寫請求轉發給其餘Server，Server在接收到寫請求後寫入數據並相應Leader，Leader在接收到大多數寫成功迴應後，認爲數據寫成功，相應Client。

Zookeeper數據模型

 zookeeper採用層次化的目錄結構，命名符合常規文件系統規範； 每一個目錄在zookeeper中叫作znode,而且其有一個惟一的路徑標識； Znode能夠包含數據和子znode（ephemeral類型的節點不能有子znode）； Znode中的數據能夠有多個版本，好比某一個znode下存有多個數據版本，那麼查詢這個路徑下的數據需帶上版本； 客戶端應用能夠在znode上設置監視器（Watcher） znode不支持部分讀寫，而是一次性完整讀寫 Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）； Znode的類型在建立時肯定而且以後不能再修改； ephemeralzn ode的客戶端會話結束時，zookeeper會將該ephemeral znode刪除，ephemeralzn ode不能夠有子節點； persistent znode不依賴於客戶端會話，只有當客戶端明確要刪除該persistent znode時纔會被刪除； Znode有四種形式的目錄節點，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、PHEMERAL_SEQUENTIAL。