極簡介紹Zookeeper，我想跟你聊這些！
大家好，我是冰河~~
從今天開始，我們正式更新【精通Zookeeepr系列】專題內容，首先我們對Zookeeper的基礎內容做下簡單的回顧和總結。本文的總體內容如下。
什么是Zookeeper?
簡單來說，Zookeeper是一個開源的分布式協同服務系統，Zookeeper的設計目標就是把復雜并且容易出錯的分布式協同服務進行封裝，并抽象出一個高效可靠的原語接口，并對外提供一系列簡單的接口為其他服務調用。其他應用只要使用Zookeeper提供的接口，就可以實現各種分布式應用。例如：分布式鎖、分布式選舉，主從切換等等。這些案例我們在實戰內容中會詳細說明。
Zookeeper發展史
Zoookeeper最早是雅虎為了解決內部多個系統之間的協同問題而研發的，后來將其開源并捐贈給了Apache組織。后來Zookeeper在開源界被廣泛使用。這里，我列舉幾個使用了Zookeeper的著名的開源項目。
- Hadoop：使用Zookeeper來提供NameNode的高可用機制。
- HBase：使用Zookeeper來保證整個集群中只有一個Master節點，保存集群中的RegionServer列表，保存hbase:meta表的位置。
- Kafka：使用Zookeeper來對進群中的成員進行管理，并使用Zookeeper提供controller節點的選舉機制。
- Dubbo：使用Zookeeper來實現分布式治理服務的注冊中心。
- SpringCloud：使用Zookeeper來實現微服務注冊中心。
還有很多使用Zookeeper作為分布式協同的開源項目，由于數量比較多，這里就不一一列舉了，小伙伴們可以自行通過網絡查閱。
Zookeeper應用場景
簡單點說，Zookeeper可以應用于以下場景當中。
- 配置管理。
- DNS服務。
- 組成員管理。
- 各種分布式鎖。
- 分布式選舉。
- 數據一致性場景。
但是，需要注意的是：Zookeeper只適合于存儲和協同相關的關鍵數據，不適合用來存儲大數據量的數據。
Zookeeper服務的使用
一般情況下，我們在使用Zookeeper時，是通過Zookeeper庫來連接并使用Zookeeper的，由Zookeeper客戶端負責和Zookeeper集群進行交互。
Zookeeper的數據模型
從本質上講，Zookeeper的數據模型是層次模型，如下所示。
這種層次模型常見于文件系統，而這種層次模型和Key-Value模型是兩種主流的數據模型。Zookeeper使用文件系統模型主要的考慮點如下。
- 文件系統的樹形結構便于表達數據之間的層次關系。
- 文件系統的樹形結構便于為不同的應用分配獨立的命名空間。
在Zookeeper中，層次結構的每個節點叫做znode，它不同于文件系統，每個節點都可以保存數據，而且每個節點都有一個版本號，版本號從0開始遞增計數。
接下來，我們再來看一個Zookeeper節點的具體示例。
例如，上圖中有三個子樹，三個子樹分別應用于app1、app2和app3三個應用。其中app1的子樹實現了一個簡單的組成員協議，也就是每個客戶端進行p創建一個znode在/app1節點下，而且每個進程創建的znode是以/app1/p_1，/app1/p_2，...，/app1/p_n 這種結構依次存放。只要 /app1/p_n 節點存在，就說明Pn進程在正常的運行。
Zookeeper的節點分類
總體來說，Znode節點可以分為以下四類。
一個Znode節點可以是持久性的，也可以是臨時性的。
持久性的Znode：創建節點后即使Zookeeper集群宕機，或者Zookeeper客戶端宕機，節點也不會丟失。
臨時性的Znode：Zookeeper客戶端宕機或者客戶端在指定的超時時間內沒有給Zookeeper集群發送消息，那么這個節點就會消失。
Znode節點也可以是順序性的，所謂的順序性，就是指每個節點會關聯一個唯一的單調遞增整數，這個單調遞增的整數就是Znode節點名稱的后綴，比如：/app1/p_1，/app1/p_2等，由此，Znode又有如下兩種分類：
持久順序性的Znode：除了具備持久性的Znode的特性之外，Znode的名稱還具備順序性。
臨時順序性的Znode：除了具備臨時性的Znode的特性之外，Znode的名稱還具備順序性。
本文轉載自微信公眾號「冰河技術」，可以通過以下二維碼關注。轉載本文請聯系冰河技術公眾號。
