Zookeeper原理架構
本文純屬個人筆記，通俗易懂，轉載請附上原文鏈接！部分資料摘自網絡，如有雷同，純屬巧合！
Zookeeper到底是什麼！？
學一個東西，不搞明白他是什麼東西，哪還有心情學啊！！
首先，Zookeeper是Apache的一個java項目，屬於Hadoop系統，扮演管理員的角色。
然後看到官網那些專有名詞，實在理解不了。
在Zookeeper的官網上有這麼一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. - 1
那麼我們來仔細研究一下這個東西吧！
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數目一般爲奇數（3、5、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。