Zookeeper -------- 概述篇
目錄
1、Zookeeper是什麼
ZooKeeper由雅虎研究院開發，是Google Chubby的開源實現，後來託管到Apache，於2010年11月正式成爲Apache的頂級項目。
ZooKeeper是一個經典的分佈式數據一致性解決方案，致力於爲分佈式應用提供一個高性能、高可用，且具有嚴格順序訪問控制能力的分佈式協調服務。
分佈式應用程序可以基於ZooKeeper實現數據發佈與訂閱、負載均衡、命名服務、分佈式協調與通知、集羣管理、Leader選舉、分佈式鎖、分佈式隊列等功能。
2、Zookeeper有什麼特點
2.1 Zookeeper的目標
（1） 高性能
ZooKeeper將全量數據存儲在內存中，並直接服務於客戶端的所有非事務請求，尤其適用於以讀爲主的應用場景
（2）高可用
ZooKeeper一般以集羣的方式對外提供服務，一般3 ~ 5臺機器就可以組成一個可用的Zookeeper集羣了，每臺機器都會在內存中維護當前的服務器狀態，並且每臺機器之間都相互保持着通信。只要集羣中超過一般的機器都能夠正常工作，那麼整個集羣就能夠正常對外服務。
（3）嚴格順序訪問
對於來自客戶端的每個更新請求，ZooKeeper都會分配一個全局唯一的遞增編號，這個編號反映了所有事務操作的先後順序。
2.2 Zookeeper所擁有的特性
ZooKeeper一般以集羣的方式對外提供服務，一個集羣包含多個節點，每個節點對應一臺ZooKeeper服務器，所有的節點共同對外提供服務，整個集羣環境對分佈式數據一致性提供了全面的支持，具體包括以下五大特性：
（1）原子性
所有請求的響應結果在整個分佈式集羣環境中具備原子性，即要麼整個集羣中所有機器都成功的處理了某個請求，要麼就都沒有處理，絕對不會出現集羣中一部分機器處理了某一個請求，而另一部分機器卻沒有處理的情況。
（2）順序一致性
從同一個客戶端發起的請求，最終將會嚴格按照其發送順序進入ZooKeeper中
（3）單一性
無論客戶端連接到ZooKeeper集羣中哪個服務器，每個客戶端所看到的服務端模型都是一致的，不可能出現兩種不同的數據狀態，因爲ZooKeeper集羣中每臺服務器之間會進行數據同步
（4）可靠性
一旦服務端數據的狀態發送了變化，就會立即存儲起來，除非此時有另一個請求對其進行了變更，否則數據一定是可靠的
（5） 實時性
當某個請求被成功處理後，ZooKeeper僅僅保證在一定的時間段內，客戶端最終一定能從服務端上讀取到最新的數據狀態，即ZooKeeper保證數據的最終一致性。
3、Zookeeper能幹什麼
3.1 提供命名服務
zookeeper的命名服務功能主要是根據指定名字來獲取資源或服務的地址，提供者等信息，利用其znode的特點和watcher機制，將其作爲動態註冊和獲取服務信息的配置中心，統一管理服務名稱和其對應的服務器列表信息，我們能夠近乎實時地感知到後端服務器的狀態(上線、下線、宕機)。
舉例來說，B服務部署在六臺服務器上，存在六個完全不同的ip地址，同時B服務本身提供一個dubbo接口對外，此時有個A服務需要調用此接口，如果提供某一臺服務器的ip，則存在該服務器宕機情況下接口不可用的情況，再切換ip就會影響服務的正常使用。此時，可以使用zookeeper作爲註冊中心，B服務的六臺服務在指定znode下創建子節點，而A服務調用之前先通過指定znode的路徑獲取B服務的任意子節點中的ip信息，然後通過ip訪問。同時zookeeper動態維護這部分節點，定時利用心跳請求檢查B服務的服務器狀態，一旦發現某服務器無反饋，就刪除節點，防止被A服務獲取調用，整個流程如下：
zookeeper命名服務作用
（1）負載均衡
輪詢服務註冊表，儘可能將服務請求均勻分配到所有註冊有效的服務器上。
（2）健康檢查
動態維護服務地址註冊表，利用心跳請求實時監控註冊服務狀態，刪除無效服務節點，維護有效的地址註冊表。
（3）調用監控
通過統計註冊表各個子節點被訪問次數來監控服務調用情況。
（4）動態路由
可以通過配置註冊表參數，在不修改服務代碼的情況下，動態指定服務訪問的機器。
（5）動態配置
註冊表的子節點可以作爲單服務器的配置中心，可以直接修改節點配置而不是修改代碼的方式，動態修改服務運行的部分參數。
3.2 配置管理
把應用配置放置zookeeper上去,保存在 Zookeeper 的某個目錄節點中，然後所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中就行。
大致圖解如下：
3.3 可實現分佈式鎖
基於zookeeper一致性文件系統,實現鎖服務。鎖服務分爲保存獨佔及時序控制兩類。
（1）保存獨佔：將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。用完刪除自己創建的distribute_lock 節點就釋放鎖。
（2）時序控制：基於/distribute_lock鎖，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。
3.4 集羣管理
所謂集羣管理無在乎兩點：是否有機器退出和加入、選舉master。
對於第一點，所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。新機器加入 也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了。
對於第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作爲master就好。
3.5 隊列管理
隊列管理分兩種：FIFO隊列和同步隊列
（1）FIFO隊列
和分佈式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。
（2）同步隊列
3.6 分佈式與數據複製
Zookeeper作爲一個集羣提供一致的數據服務，必然在所有機器間做數據複製。數據複製好處：
（1）容錯：一個節點出錯，不致於讓整個系統停止工作，別的節點可以接管它的工作。
（2）提高系統的擴展能力：把負載分佈到多個節點上，或者增加節點來提高系統的負載能力；
（3）性能提升：讓客戶端本地訪問就近節點,提高用戶訪問速度。
-------------------------------------------------------------------------------------------------------------------------------------------
參考：
https://blog.csdn.net/wzk646795873/article/details/79706627