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

zookeeper本質(zhì)上就是一個分布式協(xié)調(diào)服務(wù)，用來解決分布式一致性的問題。

本文適合有一定分布式基礎(chǔ)的讀者閱讀。什么叫相關(guān)的基礎(chǔ)呢？起碼你得知道系統(tǒng)架構(gòu)為何從集中式演變成了分布式，分布式有哪些優(yōu)點和問題?；诜植际降膯栴}，適當(dāng)?shù)膶W(xué)習(xí)下CAP，知道分布式面臨了什么的問題以及如何根據(jù)業(yè)務(wù)特點在C（一致性）和A（可用性）之間尋求平衡。之后學(xué)習(xí)下e-bay的架構(gòu)師提出的BASE理論，BASE是CAP中一致性和可用性權(quán)衡的結(jié)果，來源于大規(guī)?；ヂ?lián)網(wǎng)分布式系統(tǒng)的總結(jié)，其核心思想是使服務(wù)在一個基本可用的狀態(tài)下，根據(jù)業(yè)務(wù)的特點使用適當(dāng)?shù)姆绞绞瓜到y(tǒng)達到最終一致性。在對一個分布式系統(tǒng)進行架構(gòu)設(shè)計中，往往會在系統(tǒng)的可用性和一致性做權(quán)衡，了解一下經(jīng)典的分布式一致性協(xié)議也是極好的。比如著名的2pc、3pc、以及paxos協(xié)議，明白各自的優(yōu)缺點。

如果你對上述部分內(nèi)容感到非常陌生，尤其是關(guān)于CPA和BASE的理論知識都不太清楚的話，最好先補一下相關(guān)的基礎(chǔ)，因為這是指導(dǎo)所有分布式架構(gòu)理論的基石。這里推薦一本書可以系統(tǒng)的學(xué)習(xí)分布式理論和zookeeper，本人對于zookeeper的學(xué)習(xí)大部分也是基于此書《從Paxos到Zookeeper分布式一致性原理與實踐》.

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

zookeeper介紹

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

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

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

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

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

數(shù)據(jù)發(fā)布/訂閱
數(shù)據(jù)發(fā)布/訂閱系統(tǒng)，即所謂的配置中心，其實就是發(fā)布者將數(shù)據(jù)發(fā)布到Zookeeper上，供訂閱者進行數(shù)據(jù)訂閱，利用watcher機制進行動態(tài)獲取數(shù)據(jù)的目的，實現(xiàn)分布式架構(gòu)中配置信息的集中管理和數(shù)據(jù)的動態(tài)更新。百度開源的disconf就是典型這種場景的實現(xiàn)。

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

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

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

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

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

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

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

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