Zookeeper
一個通用的無單點問題的分佈式協調框架，以便讓開發人員將精力集中在處理業務邏輯上。
①Zookeeper 可以被用作註冊中心。
②Zookeeper 是 Hadoop 生態系統的一員；
③構建 Zookeeper 集羣的時候，使用的服務器最好是奇數臺。
ZooKeeper 是一個典型的分佈式數據一致性解決方案，分佈式應用程序可以基於 ZooKeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、分佈式鎖和分佈式隊列等功能。
Zookeeper 一個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心。
爲什麼最好使用奇數臺服務器構成 ZooKeeper 集羣？
我們知道在Zookeeper中 Leader 選舉算法採用了Zab協議。Zab核心思想是當多數 Server 寫成功，則任務數據寫成功。
①如果有3個Server，則最多允許1個Server 掛掉。
②如果有4個Server，則同樣最多允許1個Server掛掉。
既然3個或者4個Server，同樣最多允許1個Server掛掉，那麼它們的可靠性是一樣的，所以選擇奇數個ZooKeeper Server即可，這裏選擇3個Server。
重要概念總結
ZooKeeper 本身就是一個分佈式程序（只要半數以上節點存活，ZooKeeper 就能正常服務）。
爲了保證高可用，最好是以集羣形態來部署 ZooKeeper，這樣只要集羣中大部分機器是可用的（能夠容忍一定的機器故障），那麼 ZooKeeper 本身仍然是可用的。
ZooKeeper 將數據保存在內存中，這也就保證了 高吞吐量和低延遲（但是內存限制了能夠存儲的容量不太大，此限制也是保持znode中存儲的數據量較小的進一步原因）。
ZooKeeper 是高性能的。 在“讀”多於“寫”的應用程序中尤其地高性能，因爲“寫”會導致所有的服務器間同步狀態。（“讀”多於“寫”是協調服務的典型場景。）
ZooKeeper有臨時節點的概念。 當創建臨時節點的客戶端會話一直保持活動，瞬時節點就一直存在。而當會話終結時，瞬時節點被刪除。持久節點是指一旦這個ZNode被創建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。
ZooKeeper 底層其實只提供了兩個功能：①管理（存儲、讀取）用戶程序提交的數據；②爲用戶程序提交數據節點監聽服務
2 會話（Session）
在 ZooKeeper 中，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接。
。通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話，也能夠向Zookeeper服務器發送請求並接受響應，同時還能夠通過該連接接收來自服務器的Watch事件通知。
在爲客戶端創建會話之前，服務端首先會爲每個客戶端都分配一個sessionID。由於 sessionID 是 Zookeeper 會話的一個重要標識，許多與會話相關的運行機制都是基於這個 sessionID 的，因此，無論是哪臺服務器爲客戶端分配的 sessionID，都務必保證全局唯一。
3 數據節點（Znode）
在談到分佈式的時候，我們通常說的“節點"是指組成集羣的每一臺機器。然而，在Zookeeper中，“節點"分爲兩類，第一類同樣是指構成集羣的機器，我們稱之爲機器節點；第二類則是指數據模型中的數據單元，我們稱之爲數據節點一一ZNode。
在Zookeeper中，node可以分爲持久節點和臨時節點兩類。所謂持久節點是指一旦這個ZNode被創建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。而臨時節點就不一樣了，它的生命週期和客戶端會話綁定，一旦客戶端會話失效，那麼這個客戶端創建的所有臨時節點都會被移除
znode具有原子性操作，每個znode的數據將被原子性地讀寫，讀操作會讀取與znode相關的所有數據，寫操作會一次性替換所有數據。
ZooKeeper命名空間中的Znode，兼具文件和目錄兩種特點。既像文件一樣維護着數據、元信息、ACL、時間戳等數據結構，又像目錄一樣可以作爲路徑標識的一部分，並可以具有子znode。用戶對znode具有增、刪、改、查等操作（權限允許的情況下）。
Zonde由路徑標註，ZooKeeper中被表示成有反斜槓分割的Unicode字符串，如同Unix中的文件路徑。路徑必須是絕對的，因此他們必須由反斜槓來字符開頭。
5 Watcher
Watcher（事件監聽器），是Zookeeper中的一個很重要的特性。Zookeeper允許用戶在指定節點上註冊一些Watcher，並且在一些特定事件觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實現分佈式協調服務的重要特性。
ZooKeeper 特點
順序一致性,原子性,單一系統映像 ,可靠性
3 順序訪問
對於來自客戶端的每個更新請求，ZooKeeper 都會分配一個全局唯一的遞增編號，這個編號反應了所有事務操作的先後順序，應用程序可以使用 ZooKeeper 這個特性來實現更高層次的同步原語。這個編號也叫做時間戳——zxid
致使ZooKeeper節點狀態改變的每一個操作都將使節點接收到一個zxid格式的時間戳，並且這個時間戳全局有序。
對節點的每一個操作都將致使這個節點的版本號增加。每個節點維護着三個版本號，他們分別爲：
version 節點數據版本號,cversion 子節點版本號,aversion 節點所擁有的ACL版本號
五 ZooKeeper 集羣角色介紹（角色有兩種Leader和Learner，Learner角色又分爲Observer和Follower）
在 ZooKeeper 中沒有選擇傳統的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。
ZooKeeper 集羣中的所有機器通過一個 Leader 選舉過程來選定一臺稱爲 “Leader” 的機器，Leader 既可以爲客戶端提供寫服務又能提供讀服務。除了 Leader 外，Follower 和 Observer 都只能提供讀服務。Follower 和 Observer 唯一的區別在於 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機器可以在不影響寫性能的情況下提升集羣的讀性能。
leader（領導者）：負責進行投票的發起和決議，更新系統狀態
follower（跟隨者）：用於接收客戶請求並向客戶端返回結果，在選主過程中參與投票
observer（觀察者）：接收客戶端連接，將寫請求轉發給leaser節點，但observer不參與投票過程，只同步leader的狀態。目的是爲了擴展系統，提高讀取速度。
2 ZAB 協議介紹
ZAB 協議是爲分佈式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分佈式數據一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集羣中各個副本之間的數據一致性。
ZAB 協議兩種基本的模式：崩潰恢復和消息廣播
狀態同步是指數據同步，用來保證集羣中存在過半的機器能夠和Leader服務器的數據狀態保持一致。
當集羣中已經有過半的Follower服務器完成了和Leader服務器的狀態同步，那麼整個服務框架就可以進人消息廣播模式了
ZooKeeper設計成只允許唯一的一個Leader服務器來進行事務請求的處理。Leader服務器在接收到客戶端的事務請求後，會生成對應的事務提案併發起一輪廣播協議；而如果集羣中的其他機器接收到客戶端的事務請求，那麼這些非Leader服務器會首先將這個事務請求轉發給Leader服務器。
ZooKeeper是一個分佈式小文件系統，並且被設計爲高可用性。
1.通過選舉算法和集羣複製可以避免單點故障
2.由於是文件系統，所以即使所有的ZooKeeper節點全部掛掉，數據也不會丟失，重啓服務器之後，數據即可恢復。
3.ZooKeeper的節點更新是原子的，也就是說更新不是成功就是失敗。通過版本號，ZooKeeper實現了更新的樂觀鎖,當版本號不相符時，則表示待更新的節點已經被其他客戶端提前更新了，而當前的整個更新操作將全部失敗。
4.用來保證數據在ZK集羣之間的數據的事務性一致。其中ZooKeeper提供通用的分佈式鎖服務，用以協調分佈式應用。
應用
Hadoop，使用Zookeeper的事件處理確保整個集羣只有一個NameNode，存儲配置信息等.
HBase，使用Zookeeper的事件處理確保整個集羣只有一個HMaster，察覺HRegionServer聯機和宕(dàng)機，存儲訪問控制列表等。
主要用來解決分佈式應用中經常遇到的數據管理問題，如集羣管理、統一命名服務、分佈式配置管理、分佈式消息隊列、分佈式鎖、分佈式協調等。
1 ZooKeeper節點Znode
ZooKeeper目錄樹中每一個節點對應一個Znode。每個Znode維護着一個屬性結構，它包含着版本號(dataVersion)，時間戳(ctime,mtime)等狀態信息。ZooKeeper正是使用節點的這些特性來實現它的某些特定功能。每當Znode的數據改變時，他相應的版本號將會增加。每當客戶端檢索數據時，它將同時檢索數據的版本號。並且如果一個客戶端執行了某個節點的更新或刪除操作，他也必須提供要被操作的數據版本號。如果所提供的數據版本號與實際不匹配，那麼這個操作將會失敗。
2.watch觸發器
watch事件包括了事件所涉及的Znode的路徑，因此對於NodeCreated和NodeDeleted事件來說，根據路徑就可以簡單區分出是哪個Znode被創建或是被刪除了。爲了查詢在NodeChildrenChanged事件後哪個子節點被改變了，需要再次調用getChildren來獲得新的children列表。同樣的，爲了查詢NodeDeletedChanged事件後產生的新數據，需要調用getData。在兩種情況下，Znode可能在獲取watch事件或執行讀操作這兩種狀態下切換，在寫應用程序時，必須記住這一點。
ZooKeeper的執行
如果機器中的小部分出故障了，那麼至少有一臺機器將會恢復到最新狀態，其他的則保存這副本，直到最終達到最新狀態。
（1）階段1：領導者選舉：在大部分的跟隨者與他們的領導者同步了狀態以後，這個階段纔算完成。
（2）階段2：原子廣播：所有的寫操作請求被傳送給領導者，並通過廣播將更新信息告訴跟隨者。當大部分跟隨者執行了修改之後，領導者就提交更新操作，客戶端將得到更新成功的迴應。未獲得一致性的協議被設計爲原子的，因此無論修改失敗與否，他都分兩階段提交。
如果領導者出故障了，剩下的機器將會再次進行領導者選舉，並在新領導被選出前繼續執行任務。如果在不久後老的領導者恢復了，那麼它將以跟隨者的身份繼續運行。領導者選舉非常快，由發佈的結果所知，大約是200毫秒，因此在選舉時性能不會明顯減慢。
所有在ensemble中的機器在更新它們內存中的Znode樹之前會先將更新信息寫入磁盤。讀操作請求可由任何機器服務，同時，由於他們只涉及內存查找，因此非常快
Zookeeper通過複製來實現高可用性，只要集合體中半數以上的機器處於可用狀態，它就能夠保證服務繼續
爲什麼一定要超過半數呢？這跟Zookeeper的複製策略有關：zookeeper確保對znode 樹的每一個修改都會被複制到集合體中超過半數的機器上。
ZooKeeper中的組成員關係
·理解ZooKeeper的一種方法就是將其看作一個具有高可用性的文件系統。但這個文件系統中沒有文件和目錄，而是統一使用“節點”(node)的概念，稱爲znode。znode既可以作爲保存數據的容器（如同文件），也可以作爲保存其他znode的容器（如同目錄）。所有的znode構成一個層次化的命名空間。一種自然的建立組成員列表的方式就是利用這種層次結構，創建一個以組名爲節點名的znode作爲父節點，然後以組成員名（服務器名）爲節點名來創建作爲子節點的znode。