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

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

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

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

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

zookeeper介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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