Zookeeper概念簡介

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

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

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

Zookeeper作為一個分布式協調服務者，就是為用戶的分布式應用程序提供協調服務

A、zookeeper是為別的分布式程序服務的

B、Zookeeper本身就是一個分布式程序（只要有半數以上節點存活，zk就能正常服務）

C、Zookeeper所提供的服務涵蓋：主從協調、服務器節點動態上下線、統一配置管理、分布式共享鎖、統一名稱服務……

D、雖然說可以提供各種服務，但是zookeeper在底層其實只提供了兩個功能：

    管理(存儲，讀取)用戶程序提交的數據；

    并為用戶程序提供數據節點監聽服務；

Zookeeper常用應用場景 

ZooKeeper是一個高可用的分布式數據管理與系統協調框架?；趯axos算法的實現，使該框架保證了分布式環境中數據的一致性，也正是基于這樣的特性，使得它能夠應用于很多場景。?

數據發布與訂閱

發布與訂閱即所謂的配置管理，顧名思義就是將數據發布到zk節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，地址列表等就非常適合使用。

1. 索引信息和集群中機器節點狀態存放在zk的一些指定節點，供各個客戶端訂閱使用。

2. 系統日志（經過處理后的）存儲，這些日志通常2-3天后被清除。

3. 應用中用到的一些配置信息集中管理，在應用啟動的時候主動來獲取一次，并且在節點上注冊一個Watcher，以后每次配置有更新，實時通知到應用，獲取最新配置信息。

4. 業務邏輯中需要用到的一些全局變量，比如一些消息中間件的消息隊列通常有個offset，這個offset存放在zk上，這樣集群中每個發送者都能知道當前的發送進度。

5. 系統中有些信息需要動態獲取，并且還會存在人工手動去修改這個信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要將這些信息存放到zk節點上即可。

分布通知/協調

ZooKeeper 中特有watcher注冊與異步通知機制，能夠很好的實現分布式環境下不同系統之間的通知與協調，實現對數據變更的實時處理。使用方法通常是不同系統都對 ZK上同一個znode進行注冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那么另一個系統能 夠收到通知，并作出相應處理。

1. 另一種心跳檢測機制：檢測系統和被檢測系統之間并不直接關聯起來，而是通過zk上某個節點關聯，大大減少系統耦合。

2. 另一種系統調度模式：某系統有控制臺和推送系統兩部分組成，控制臺的職責是控制推送系統進行相應的推送工作。管理人員在控制臺作的一些操作，實際上是修改 了ZK上某些節點的狀態，而zk就把這些變化通知給他們注冊Watcher的客戶端，即推送系統，于是，作出相應的推送任務。

3. 另一種工作匯報模式：一些類似于任務分發系統，子任務啟動后，到zk來注冊一個臨時節點，并且定時將自己的進度進行匯報（將進度寫回這個臨時節點），這樣任務管理者就能夠實時知道任務進度。

總之，使用zookeeper來進行分布式通知和協調能夠大大降低系統之間的耦合。

分布式鎖

分布式鎖，這個主要得益于ZooKeeper為我們保證了數據的強一致性，即用戶只要完全相信每時每刻，zk集群中任意節點（一個zk server）上的相同znode的數據是一定是相同的。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。

保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。

控制時序，就是所有視圖來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全局時序了。做法和上面基本類似，只是這里 /distribute_lock 已經預先存在，客戶端在它下面創建臨時有序節點（這個可以通過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節點（/distribute_lock）維持一份sequence,保證子節點創建的時序性，從而也形成了每個客戶端的全局時序。

集群管理

1. 集群機器監控：這通常用于那種對集群中機器狀態，機器在線率有較高要求的場景，能夠快速對集群中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測集群機器是否存活。過去的做法通常是：監控系統通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統匯報“我還活著”。 這種做法可行，但是存在兩個比較明顯的問題：1. 集群中機器有變動的時候，牽連修改的東西比較多。2. 有一定的延時。

利用ZooKeeper有兩個特性，就可以實時另一種集群機器存活性監控系統：a. 客戶端在節點 x 上注冊一個Watcher，那么如果 x 的子節點變化了，會通知該客戶端。b. 創建EPHEMERAL類型的節點，一旦客戶端和服務器的會話結束或過期，那么該節點就會消失。

2. Master選舉則是zookeeper中最為經典的使用場景了。

在分布式環境中，相同的業務應用分布在不同的機器上，有些業務邏輯（例如一些耗時的計算，網絡I/O處理），往往只需要讓整個集群中的某一臺機器進行執行， 其余機器可以共享這個結果，這樣可以大大減少重復勞動，提高性能，于是這個master選舉便是這種場景下的碰到的主要問題。

利用ZooKeeper的強一致性，能夠保證在分布式高并發情況下節點創建的全局唯一性，即：同時有多個客戶端請求創建 /currentMaster 節點，最終一定只有一個客戶端請求能夠創建成功。

Zookeeper集群的角色：  Leader 和  follower  （Observer）

只要集群中有半數以上節點存活，集群就能提供服務

zookeeper集群機制半數機制：

集群中半數以上機器存活，集群可用。

zookeeper適合裝在奇數臺機器上?。?！

zookeeper原理

Zookeeper雖然在配置文件中并沒有指定master和slave

但是，zookeeper工作時，是有一個節點為leader，其他則為follower

Leader是通過內部的選舉機制臨時產生的

zookeeper的選舉機制（全新集群paxos）

以一個簡單的例子來說明整個選舉的過程.

假設有五臺服務器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啟動,來看看會發生什么.

1) 服務器1啟動,此時只有它一臺服務器啟動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態

2) 服務器2啟動,它與最開始啟動的服務器1進行通信,互相交換自己的選舉結果,由于兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由于沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態.

3) 服務器3啟動,根據前面的理論分析,服務器3成為服務器1,2,3中的老大,而與上面不同的是,此時有三臺服務器選舉了它,所以它成為了這次選舉的leader.

4) 服務器4啟動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中較大的,但是由于前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了.

5) 服務器5啟動,同4一樣,當小弟.

非全新集群的選舉機制(數據恢復)

那么，初始化的時候，是按照上述的說明進行選舉的，但是當zookeeper運行了一段時間之后，有機器down掉，重新選舉時，選舉過程就相對復雜了。

需要加入數據id、leader id和邏輯時鐘。

數據id：數據新的id就大，數據每次更新都會更新id。

Leader id：就是我們配置的myid中的值，每個機器一個。

邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值,也就是說:  如果在同一次選舉中,那么這個值應該是一致的 ;  邏輯時鐘值越大,說明這一次選舉leader的進程更新.

選舉的標準就變成：

1、邏輯時鐘小的選舉結果被忽略，重新投票

2、統一邏輯時鐘后，數據id大的勝出

3、數據id相同的情況下，leader id大的勝出

根據這個規則選出leader。