Zookeeper到底是什么??？
學一個東西，不搞明白他是什么東西，哪還有心情學?。?！
首先，Zookeeper是Apache的一個java項目，屬于Hadoop系統(tǒng)，扮演管理員的角色。
然后看到官網(wǎng)那些專有名詞，實在理解不了。
在Zookeeper的官網(wǎng)上有這么一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
那么我們來仔細研究一下這個東西吧！
Zookeeper能干嘛？！
1. 配置管理
這個好理解。分布式系統(tǒng)都有好多機器，比如我在搭建hadoop的HDFS的時候，需要在一個主機器上（Master節(jié)點）配置好HDFS需要的各種配置文件，然后通過scp命令把這些配置文件拷貝到其他節(jié)點上，這樣各個機器拿到的配置信息是一致的，才能成功運行起來HDFS服務。Zookeeper提供了這樣的一種服務：一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。這樣就省去手動拷貝配置了，還保證了可靠和一致性。
[圖片上傳失敗...(image-25da55-1546759100694)]
2. 名字服務
這個可以簡單理解為一個電話薄，電話號碼不好記，但是人名好記，要打誰的電話，直接查人名就好了。
分布式環(huán)境下，經(jīng)常需要對應用/服務進行統(tǒng)一命名，便于識別不同服務；
?類似于域名與ip之間對應關系，域名容易記??；
?通過名稱來獲取資源或服務的地址，提供者等信息
3. 分布式鎖
碰到分布二字貌似就難理解了，其實很簡單。單機程序的各個進程需要對互斥資源進行訪問時需要加鎖，那分布式程序分布在各個主機上的進程對互斥資源進行訪問時也需要加鎖。很多分布式系統(tǒng)有多個可服務的窗口，但是在某個時刻只讓一個服務去干活，當這臺服務出問題的時候鎖釋放，立即fail over到另外的服務。這在很多分布式系統(tǒng)中都是這么做，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。舉個通俗點的例子，比如銀行取錢，有多個窗口，但是呢對你來說，只能有一個窗口對你服務，如果正在對你服務的窗口的柜員突然有急事走了，那咋辦？找大堂經(jīng)理（zookeeper）!大堂經(jīng)理指定另外的一個窗口繼續(xù)為你服務！
4. 集群管理
在分布式的集群中，經(jīng)常會由于各種原因，比如硬件故障，軟件故障，網(wǎng)絡問題，有些節(jié)點會進進出出。有新的節(jié)點加入進來，也有老的節(jié)點退出集群。這個時候，集群中有些機器（比如Master節(jié)點）需要感知到這種變化，然后根據(jù)這種變化做出對應的決策。我已經(jīng)知道HDFS中namenode是通過datanode的心跳機制來實現(xiàn)上述感知的，那么我們可以先假設Zookeeper其實也是實現(xiàn)了類似心跳機制的功能吧！
Zookeeper的特點
1 最終一致性：為客戶端展示同一視圖，這是zookeeper最重要的功能。
2 可靠性：如果消息被到一臺服務器接受，那么它將被所有的服務器接受。
3 實時性：Zookeeper不能保證兩個客戶端能同時得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應該在讀數(shù)據(jù)之前調用sync()接口。
4 等待無關（wait-free）：慢的或者失效的client不干預快速的client的請求。
5 原子性：更新只能成功或者失敗，沒有中間狀態(tài)。
6 順序性：所有Server，同一消息發(fā)布順序一致。
用到Zookeeper的系統(tǒng)
HDFS中的HA方案
YARN的HA方案
HBase：必須依賴Zookeeper，保存了Regionserver的心跳信息，和其他的一些關鍵信息。
Flume：負載均衡，單點故障
Zookpeeper的基本架構
[圖片上傳失敗...(image-93577a-1546759100694)]
1 每個Server在內存中存儲了一份數(shù)據(jù)；
2 Zookeeper啟動時，將從實例中選舉一個leader（Paxos協(xié)議）；
3 Leader負責處理數(shù)據(jù)更新等操作（Zab協(xié)議）；
4 一個更新操作成功，當且僅當大多數(shù)Server在內存中成功修改
數(shù)據(jù)。
[圖片上傳失敗...(image-238ca8-1546759100694)]
Zookpeeper Server 節(jié)點的數(shù)目
Zookeeper Server數(shù)目一般為奇數(shù)
Leader選舉算法采用了Paxos協(xié)議；Paxos核心思想：當多數(shù)Server寫成功，則任務數(shù)據(jù)寫
成功。也就是說：
如果有3個Server，則兩個寫成功即可；
如果有4或5個Server，則三個寫成功即可。
Server數(shù)目一般為奇數(shù)（3、5、7）
如果有3個Server，則最多允許1個Server掛掉；
如果有4個Server，則同樣最多允許1個Server掛掉
既然如此，為啥要用4個Server？
Observer節(jié)點
3.3.0 以后 版本新增角色Observer
增加原因：
Zookeeper需保證高可用和強一致性；
當集群節(jié)點數(shù)目逐漸增大為了支持更多的客戶端，需要增加更多Server，然而Server增多，投票階段延遲增大，影響性能。為了權衡伸縮性和高吞吐率，引入Observer：
Observer不參與投票；
Observers接受客戶端的連接，并將寫請求轉發(fā)給leader節(jié)點；
加入更多Observer節(jié)點，提高伸縮性，同時不影響吞吐率。
Zookeeper寫流程：
[圖片上傳失敗...(image-aed45a-1546759100693)]
客戶端首先和一個Server或者Observe（可以認為是一個Server的代理）通信，發(fā)起寫請求，然后Server將寫請求轉發(fā)給Leader，Leader再將寫請求轉發(fā)給其他Server，Server在接收到寫請求后寫入數(shù)據(jù)并相應Leader，Leader在接收到大多數(shù)寫成功回應后，認為數(shù)據(jù)寫成功，相應Client。
Zookeeper數(shù)據(jù)模型
[圖片上傳失敗...(image-bf3d40-1546759100693)]
zookeeper采用層次化的目錄結構，命名符合常規(guī)文件系統(tǒng)規(guī)范；
每個目錄在zookeeper中叫做znode,并且其有一個唯一的路徑標識；
Znode可以包含數(shù)據(jù)和子znode（ephemeral類型的節(jié)點不能有子znode）；
Znode中的數(shù)據(jù)可以有多個版本，比如某一個znode下存有多個數(shù)據(jù)版本，那么查詢這個路徑下的數(shù)據(jù)需帶上版本；
客戶端應用可以在znode上設置監(jiān)視器（Watcher）
znode不支持部分讀寫，而是一次性完整讀寫
Znode有兩種類型，短暫的（ephemeral）和持久的（persistent）；
Znode的類型在創(chuàng)建時確定并且之后不能再修改；
ephemeralzn ode的客戶端會話結束時，zookeeper會將該ephemeral znode刪除，ephemeralzn ode不可以有子節(jié)點；
persistent znode不依賴于客戶端會話，只有當客戶端明確要刪除該persistent znode時才會被刪除；
Znode有四種形式的目錄節(jié)點，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、PHEMERAL_SEQUENTIAL。
