摘要：之后服務器等待其他服務器的反饋，一旦超過半數的服務器進行了正確的反饋，那么就會再次向所有的服務器分發消息，要求其將前一個進行提交。協議包括兩種基本的模式，分別是崩潰恢復和消息廣播。

zookeeper本質上就是一個分布式協調服務，用來解決分布式一致性的問題。

本文適合有一定分布式基礎的讀者閱讀。什么叫相關的基礎呢？起碼你得知道系統架構為何從集中式演變成了分布式，分布式有哪些優點和問題。基于分布式的問題，適當的學習下CAP，知道分布式面臨了什么的問題以及如何根據業務特點在C（一致性）和A（可用性）之間尋求平衡。之后學習下e-bay的架構師提出的BASE理論，BASE是CAP中一致性和可用性權衡的結果，來源于大規模互聯網分布式系統的總結，其核心思想是使服務在一個基本可用的狀態下，根據業務的特點使用適當的方式使系統達到最終一致性。在對一個分布式系統進行架構設計中，往往會在系統的可用性和一致性做權衡，了解一下經典的分布式一致性協議也是極好的。比如著名的2pc、3pc、以及paxos協議，明白各自的優缺點。

如果你對上述部分內容感到非常陌生，尤其是關于CPA和BASE的理論知識都不太清楚的話，最好先補一下相關的基礎，因為這是指導所有分布式架構理論的基石。這里推薦一本書可以系統的學習分布式理論和zookeeper，本人對于zookeeper的學習大部分也是基于此書《從Paxos到Zookeeper分布式一致性原理與實踐》.

友情提示：本文是對《從Paxos到Zookeeper分布式一致性原理與實踐》的一個簡單總結，方便作者本人也就是我自己平常翻閱看，快速過一下zookeeper的各個點。如果你讀起來有點吃力，完全不知所云且對zookeeper又有一絲絲興趣，那么老老實實看書吧~。

zookeeper介紹

zookeeper是由hadoop的子項目發展而來，為分布式應用提供了高效且可靠的分布式協調服務，提供了命名服務、配置管理、分布式鎖和Master選舉等分布式的基礎服務。在解決分布式一致性方面，zookeeper沒有直接采用paxos算法，而是采用了ZAB（Zookeeper Atomic Broadcast）的一致性協議。

zookeeper的5個特性
1.順序一致性：從同一個客戶端發送的事務請求，最終將嚴格的按照其發起順序被應用到Zookeeper中去。
2.原子性：所有事務請求的結果在集群中所有機器上的應用情況是一致的，也就是說要么集群內所有的機器都應用了某一事務，要么都沒有應用。
3.單一視圖：無論哪個客戶端連接的zookeeper服務器，其看到的數據模型都是一致的。
4.可靠性：一旦服務器成功應用了某一個事務，那么該事務引起的服務端狀態變更將會被一直保留下來，除非另一個事務又對其進行了變更。
5.實時性：一旦一個事務被成功應用后，zookeeper不能立即保證可以從讀取到事務變更后的最新數據狀態，它只能保證在一定的時間段內，客戶端最終能從服務端上讀取到新的數據狀態。

zookeeper的四個設計目標
1.簡單的數據模型:zookeeper使得分布式系統共享一個樹形結構的名字空間來進行相互協調。樹形結構中最小的數據節點就是ZNODE。總的來說，其數據模型類似于一個文件系統，而ZNODE之間的層級關系，就像文件系統的目錄結構一樣。不過zookeeper選擇將全量數據存儲在內存中，以此來實現提高服務器吞吐、減少延遲的目的。
2.可以構建集群:一個zookeeper集群通常由一組機器組成，一般3~5臺機器就可以組成一個可用的集群。zookeeper集群之間的每臺機器都會在內存中維護當前的服務器狀態，并且每臺機器之間互相保持通信。只要集群中超過一半機器存活，集群就可以正常對外提供服務。zookeeper的客戶端會選擇集群中任意一臺機器共同來創建一個TCP連接，一旦連接斷開后，客戶端會自動連接到集群中的其他機器。
3.順序訪問:對于每一個更改數據狀態的事務請求，zookeeper都會分配一個全局唯一的遞增編號，這個編號反映了所有事務操作的先后順序。
4.高性能:zookeeper將全量數據存儲到內存中，并直接服務于客戶端的所有非事務請求，因此它尤其適用以讀操作為主的應用場景。

zookeeper的基本概念
1.集群角色：最典型的的集群模式就是Master/Slave模式。在這種模式中將處理所有寫操作的機器稱為Master機器，把通過異步復制方式獲取最新數據并提供讀服務的機器稱為Slave機器。而zookeeper沒有選擇這種經典模式，而是引入了Leader、Follower和Observer三種角色。zookeeper通過leader選舉過程選舉集群中的一臺機器為leader服務器，leader服務器為客戶端同時提供讀服務和寫服務，且只有leader可以提供寫服務。Follower和Observer都提供讀服務，唯一的區別在于observer機器不參與leader選舉過程，也不參與寫操作的過半寫成功的策略。因此若在不影響寫性能的情況下提升集群的讀性能增加observer就對了！
2.會話：在講解會話之前，先來了解下客戶端連接。在zookeeper中，一個客戶端連接指的是客戶端月服務器之間的一個TCP長連接。zookeeper對外的服務端口默認是2181，客戶端啟動的時候首先會與服務端建立一個TCP連接，從第一次連接建立開始，客戶端的會話周期就開始了，客戶端通過心跳檢測與服務端保持有效的會話，也可以通過該連接接收來自服務器的watch事件通知
3：數據節點：zookeeper將所有數據存儲在內存中，數據模型是一顆樹（ZNode Tree），由斜杠（/）進行分割的路徑就是一個ZNode，例如/dubbo/provider/com.bin.IUserService,每個ZNode都會保存自己的數據內容，同時還會保存一系列屬性信息。在zookeeper中ZNode分為持久節點和臨時節點兩類。所謂持久節點就是一旦ZNode節點被創建成功了，除非主動進行該ZNode的移除操作，否則這個ZNode將會一直保存在zookeeper集群中。而臨時節點就不一樣了，它的生命周期和客戶端會話綁定，一旦客戶端會話失效，那這個客戶端創建的所有臨時節點都會被移除。另外zookeeper還允許每一個節點增加一個特殊的屬性：SEQUENTIAL，也就是有序性。一旦節點被標記上這個屬性，那么這個節點被創建的時候，zookeeper都會在節點名字后面追加上一個整形數字，這個數字是一個由父節點維護的自增數字。所有節點必為持久節點，換言之只有是持久節點才能有子節點。
4：Watcher：事件監聽器，是zookeeper中一個非常重要的特性。zookeeper允許用戶在指定節點上注冊一些Watcher，并在一些特定事件觸發的時候，zookeeper會通過于客戶端會話的連接將事件通知到注冊的客戶端上去，該機制是zookeeper實現分布式協調服務的重要特性。但需要知道Watcher是一個消耗品，每次使用都須重新注冊，如果你使用的是zookeeper原生客戶端需要注意這點，好在zkclient和curator客戶端會每次幫你重新注冊watcher，幫我們省掉了一些不必要的代碼。

zookeeper的ZAB協議
zookeeper沒有完全采用Paxos算法，而是使用了一種Zookeeper Atomic Broadcast（ZAB,Zookeeper原子消息廣播協議）的協議作為數據一致性的核心算法。ZAB協議的核心是定義了對于那些會改變Zookeeper服務器數據狀態的事務請求的處理方式，即：所有的事務請求必須由一個全局唯一的服務器來處理，這樣的服務器被稱為leader服務器，而余下的服務器則被稱為follower服務器。leader服務器負責將一個客戶端事務請求轉換成一個事務Proposal（提議），并將該Proposal分發給集群中所有的Follwer服務器。之后leader服務器等待其他follower服務器的反饋，一旦超過半數的follwer服務器進行了正確的反饋，那么leader就會再次向所有的follwer服務器分發commit消息，要求其將前一個proposal進行提交。
ZAB協議包括兩種基本的模式，分別是崩潰恢復和消息廣播。當整個服務框架在啟動時，或是當leader服務器出現網絡中斷、崩潰退出與重啟等異常情況時，ZAB協議就會進入恢復模式并選舉新的leader。當選舉完leader之后，同時集群中有過半的機器與該leader服務器完成了狀態同步之后，ZAB就會退出恢復模式，進入消息廣播模式。當有一個新的遵從ZAB協議的服務器加入到集群當中，如果此時已經存在一個leader服務器在負責進行消息廣播，那么新加入的服務器就會自覺地找到leader服務器進行數據同步，然后一起參與到消息廣播流程中去。
上面從概念上簡單介紹了ZAB協議，有對ZAB協議實現細節感興趣的可以去翻看文首推薦的書，亦或是Andr′e Medeiros的論文。

數據發布/訂閱
數據發布/訂閱系統，即所謂的配置中心，其實就是發布者將數據發布到Zookeeper上，供訂閱者進行數據訂閱，利用watcher機制進行動態獲取數據的目的，實現分布式架構中配置信息的集中管理和數據的動態更新。百度開源的disconf就是典型這種場景的實現。

注冊中心
阿里巴巴開源的框架dubbo相信大部分人都多多少少的有些了解，它是一個致力于提供高性能和透明化的遠程服務調用方案和基于服務框架展開的完整SOA服務治理方案。在這，我們主要聊下dubbo中基于zookeeper實現的服務注冊中心。注冊中心是RPC框架中最核心的模塊之一，用于服務的注冊和訂閱。假設現在有一個應用，提供了一個rpc服務com.bin.IBinService。服務提供者在初始化啟動時，會在zookeeper集群中對應的目錄下/dubbo/com.bin.IBinSerivce/providers節點下創建一個子節點，并寫入自己的URL地址，這就代表了IBinService這個服務的一個提供者，若有多個服務提供者，同理zookeeper也會生成多個子節點。服務消費者會在zookeeper的/dubbo/com.bin.IBinSerivce/consumers節點下創建一個臨時節點，并寫入自己的url地址，這就代表了這個服務的一個消費者。dubbo作為一個完成的soa服務治理框架，也提供了集群容錯和軟負載的功能，都是從zookeeper上拉取所有的提供者，根據設置的策略進行。

Master選舉
master選舉是一個在分布式系統中非常常見的應用場景。接下來，我們重點看master選舉的過程。在集群的所有機器中選出一臺機器作為master，針對這個需求，我們可以選擇常見的關系型數據庫的主鍵特性來實現：集群中所有機器向數據庫中插入一條相同主鍵ID的記錄，數據庫會幫助我們保證主鍵的唯一性和沖突檢查，也就是說成功的那臺機器將成為master。但這個方案的致命缺點就是如果當前的master掛了，怎么處理？顯然數據庫沒法通知我們這個事件，我們可以通過zookeeper輕而易舉的做到這一點。利用zookeeper的強一致性，能夠很好地保證在分布式高并發環境下節點的創建一定能夠保證全局唯一性。如果有多個客戶端同時創建同一個節點，那么最終一定只有一個客戶端能夠請求創建成功。利用這個特性，就可以很容易的在分布式環境進行Master選舉了。假如master掛了，如何根據zookeeper進行動態master選舉呢？集群中所有機器都會向zookeeper定時創建一個臨時節點（/master_election/2018/leader），只有一臺機器能夠成功創建這個節點，那么這臺機器就成為了master。同時其他沒有創建成功的機器都會在節點(/master_election/2018)上注冊一個子節點變更的watcher，用于監控當前的master機器是否存活，一旦發現當前的master掛了，那么其余的機器將會進行Master選舉.

分布式鎖
常見的分布式鎖有三種實現方式，基于mysql，redis和zookeeper的。分布式鎖是控制分布式系統之間同步訪問共享資源的一種方式。在通常的java開發編程中，有兩種常見的鎖，分別是synchronized機制和JDK5提供的ReentranLock。zookeeper是使用了一個數據節點來表示為一個鎖。在需要去獲取鎖時，所有的客戶端都會去創建一個節點，比如：/exclusive_lock/lock,zookeeper會保證只有一個客戶端能夠創建成功，，那么就認為該客戶端獲取了鎖。同時其他所有沒有獲得到鎖的客戶端就需要到/exclusive_lock節點下注冊一個子節點變更的watcher監聽，以便實時監聽到lock節點消失，通知其他客戶端去重新創建節點獲得分布式鎖。

常見的應用場景已經講完了，或許你有些迷迷糊糊，覺得太理論了，我想要看代碼。其實基礎理論知識如果懂了，代碼是很簡單的。這里給大家推薦一個好用的客戶端，Netflix公司開源的一套zookeeper客戶端框架：Curator。它是目前全世界范圍內使用最廣泛的zookeeper客戶端。它處理了許多非常底層的細節工作，包括連接重連、反復注冊watcher和各種ZNODE異常，并且它還提供了zookeeper各種應用場景（Recipe，master選舉和共享鎖）的抽象封裝。如果你想看zookeeper本身是怎么實現的，那你就看zookeeper原生客戶端。如果你想要使用zookeeperAPI，那一定首選Curator。

數據模型
zookeeper的視圖結構與unix文件系統非常類似，但他沒有引入傳統文件系統中目錄和文件的概念，而是使用了特有的數據節點ZNode。ZNode是zookeeper中數據最小單元，每個ZNode上都可以保存數據，同時還可以掛載子節點，因此形成了一棵樹。

節點特性
在zookeeper中，每個數據節點都是有生命周期的。總體可分為三類：持久節點（PERSISTENT）,臨時節點（EPHEMERAL）和順序節點（SEQUENTIAL），具體在使用過程中。可以生成四種組合類型：持久節點、持久順序節點、臨時節點、臨時順序節點。
持久節點：zookeeper最常見的節點類型。一旦被創建后，就會一直存在zookeeper服務器上，直到有操作來主動清除這個節點。
持久順序節點：相對于持久節點，它額外的特性表現在順序性上。在zookeeper中，每個父節點都會為它的第一級子節點維護一份順序，用于記錄下節點被創建的先后順序。基于這個特性，在創建子節點的時候，可以設置這個標記，生成的節點名稱就會添加一個數字后綴作為新的節點名。值得注意的是數字后綴的上限是整型的最大值。
臨時節點：它的生命周期和客戶端的會話綁定在一起，也就是說，如果客戶端會話失效，這個節點會被自動清除。zookeeper規定了不能基于臨時節點來創建子節點，也就是子節點只能成為葉子節點。
臨時順序節點：和臨時節點一樣，也是多出了順序的特性。

Watcher
一個典型的發布訂閱系統定義了一種一對多的訂閱關系，能夠讓多個訂閱者同時監聽某一個主題對象，當這個主題對象自身狀態變化時，會通知所有訂閱者，使他們能做出相應的處理。zookeeper中使用了watcher機制來實現這種分布式的通知功能。zookeeper允許客戶端向服務端注冊一個watcher監聽，當服務端的 一些指定事件觸發了這個Watcher，那么就會像指定的客戶端發送一個事件通知來實現分布式的通知功能。整個流程如下圖所示:

服務期間的角色介紹
在zookeeper集群中，分別有leader、follwer和observer三種類型的服務器角色。
leader：它是整個zookeeper集群中工作的核心，它是事務請求的唯一調度和處理者，保證集群事務處理的順序性，同事它也是集群內部各服務器的調度者。
follwer：follwer服務器是zookeeper集群狀態的跟隨者，其主要工作有：處理客戶端非事務請求，轉發事務請求給leader服務器，參與事務請求的proposal的投票，參與leader選舉投票
observer：observer服務器充當了一個觀察者的角色，它會觀察zookeeper最新的集群狀態并同步過來。它的工作原理和follwer基本上是一樣的，對于非事務請求都可以進行獨立的處理，對于非事務請求，會轉發給leader服務器進行處理。和follwer唯一的區別就是，不參與事務請求proposal和leadr選舉的投票。簡單的說，observer只提供非事務服務，用于不影響集群事務處理能力的前提下提升集群地非事務處理能力。