Zookeeper是什么？Zookeeper分布式服務框架的應用場景管理

1、簡介

Zookeeper 分布式服務框架是Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

(相關資料圖)

Zookeeper 作為一個分布式的服務框架，主要用來解決分布式集群中應用系統的一致性問題，它能提供基于類似于文件系統的目錄節點樹方式的數據存儲， Zookeeper 作用主要是用來維護和監控存儲的數據的狀態變化，通過監控這些數據狀態的變化，從而達到基于數據的集群管理

簡單的說，zookeeper = 文件系統 + 通知機制。

2、應用場景

命名服務： 在zookeeper的文件系統里創建一個目錄，即有唯一的path。在我們無法確定上游程序的部署機器時即可與下游程序約定好path，通過path即能互相探索發現。 這個主要是作為分布式命名服務，通過調用zk的create node api，能夠很容易創建一個全局唯一的path，這個path就可以作為一個名稱。

配置管理 現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然后所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應用到系統中就好。

集群管理 所謂集群管理無在乎兩點：是否有機器退出和加入、選舉master。 對于第一點，所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然后監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，于是，所有人都知道：它上船了。 新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount又有了，對于第二點，我們稍微改變一下，所有機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為master就好。

負載均衡 把ZooKeeper作為一個服務的注冊中心，在其中登記每個服務，每臺服務器知道自己是屬于哪個服務，在服務器啟動時，自己向所屬服務進行登記，這樣，一個樹形的服務結構就呈現出來了，根據這樣一個樹形服務結構，RPC服務的消費者可以很輕松的找到它所需求的服務信息。同時在一個service節點下可以注冊多個業務邏輯相同的服務，以實現負載均衡。

zookeeper實現負載均衡其實原理很簡單，zookeeper 的數據存儲類似于liunx的目錄結構。首先建立servers節點，并建立監聽器監視servers子節點的狀態（用于在服務器增添時及時同步當前集群中服務器列表）。

在每個服務器啟動時，在servers節點下建立子節點worker server（可以用服務器地址命名）,并在對應的字節點下存入服務器的相關信息。這樣，我們在zookeeper服務器上可以獲取當前集群中的服務器列表及相關信息，可以自定義一個負載均衡算法，在每個請求過來時從zookeeper服務器中獲取當前集群服務器列表，根據算法選出其中一個服務器來處理請求。

分布式鎖 分布式鎖是控制分布式系統或不同系統之間共同訪問共享資源的一種鎖實現，如果不同的系統或同一個系統的不同主機之間共享了某個資源時，往往需要互斥來防止彼此干擾來保證一致性。

3、zookeeper的基本概念

3.1、角色介紹

ZooKeeper中包含Leader、Follower和Observer三個角色；

通過一次選舉過程，被選舉的機器節點被稱為Leader，Leader機器為客戶端提供讀和寫服務； Follower和Observer是集群中的其他機器節點，唯一的區別就是：Observer不參與Leader的選舉過程。

Leader主要有三個功能：

恢復數據；維持與follower的心跳，接收follower請求并判斷follower的請求消息類型；follower的消息類型主要有PING消息、REQUEST消息、ACK等消息，根據不同的消息類型，進行不同的處理。

系統模型

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的 Server都恢復到一個正確的狀態。

Zk的選舉算法有兩種：

一種是基于basic paxos實現的，另外一種是基于fast paxos算法實現的。

系統默認的選舉算法為fast paxos。

3.2、 Zookeeper的數據節點

Zookeeper維護一個類似文件系統的數據結構：

每個子目錄項如 NameService 都被稱作為 znode，和文件系統一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，唯一的不同在于znode是可以存儲數據的。

有四種類型的znode：

PERSISTENT-持久化目錄節點 客戶端與zookeeper斷開連接后，該節點依舊存在

PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點 客戶端與zookeeper斷開連接后，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號。

EPHEMERAL-臨時目錄節點 客戶端與zookeeper斷開連接后，該節點被刪除

EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點 客戶端與zookeeper斷開連接后，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

3.2.1、Zookeeper的數據同步的特點

最終一致性： client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。

可靠性： 具有簡單、健壯、良好的性能，如果消息被到一臺服務器接受，那么它將被所有的服務器接受。

實時性： Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新信息，或者服務器失效的信息。但由于網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。

原子性： 更新只能成功或者失敗，沒有中間狀態。

3.2.2、Zookeeper的數據廣播

Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。

Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。

當服務啟動或者在領導者崩潰后，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步以后，恢復模式就結束了。

狀態同步保證了leader和Server具有相同的系統狀態。

結束?。。?/p>

行動是自己的，控制好它，你就能任游東西。怕只怕，思想不是自己的，千行萬動，還只是在原地踏步。