摘要：協(xié)議是為分布式協(xié)調(diào)服務(wù)專門設(shè)計的一種支持崩潰恢復(fù)的一致性協(xié)議，這個機制保證了各個之間的同步。選主是協(xié)議中最為重要和復(fù)雜的過程。以實際效果而言，分區(qū)相當于對通信的時限要求。參考官方文檔阿里巴巴為什么不用做服務(wù)發(fā)現(xiàn)定理的含義阮一峰

同學們，在上一章中，我們主要講了Zookeeper兩種啟動模式以及具體如何搭建。本章內(nèi)容主要講的是集群相關(guān)的原理內(nèi)容，第一章可以當做是Zookeeper原理篇的基礎(chǔ)部分，本章則是Zookeeper原理篇進階部分，有關(guān)于Zookeeper集群的讀寫機制、ZAB協(xié)議的知識解析。

本篇的內(nèi)容主要包含以下幾點：

Zookeeper 集群架構(gòu)

Zookeeper 讀寫機制

ZAB協(xié)議

關(guān)于Zookeeper 集群的一些其他討論

Zookeeper（讀性能）可伸縮性 和 Observer節(jié)點

Zookeeper 與 CAP 理論

Zookeeper 作為 服務(wù)注冊中心的局限性

接下來我們來說一說Zookeeper的集群架構(gòu)。

第一章提過，Zookeeper中，能改變ZooKeeper服務(wù)器狀態(tài)的操作稱為事務(wù)操作。一般包括數(shù)據(jù)節(jié)點創(chuàng)建與刪除、數(shù)據(jù)內(nèi)容更新和客戶端會話創(chuàng)建與失效等操作。

Leader 領(lǐng)導(dǎo)者 ：Leader 節(jié)點負責Zookeeper集群內(nèi)部投票的發(fā)起和決議（一次事務(wù)操作），更新系統(tǒng)的狀態(tài)；同時它也能接收并且響應(yīng)Client端發(fā)送的請求。

Learner 學習者

Follower 跟隨者 ： Follower 節(jié)點用于接收并且響應(yīng)Client端的請求，如果是事務(wù)操作，會將請求轉(zhuǎn)發(fā)給Leader節(jié)點，發(fā)起投票，參與集群的內(nèi)部投票，

Observer 觀察者：Observer 節(jié)點功能和Follower相同，只是Observer 節(jié)點不參與投票過程，只會同步Leader節(jié)點的狀態(tài)。

Client 客戶端

Zookeeper 通過復(fù)制來實現(xiàn)高可用。在上一章提到的集群模式（replicated mode）下，以Leader節(jié)點為準，Zookeeper的ZNode樹上面的每一個修改都會被同步（復(fù)制）到其他的Server 節(jié)點上面。

上面實際上只是一個概念性的簡單敘述，在看完下文的讀寫機制和ZAB協(xié)議的兩種模式之后，你就會對這幾種角色有一個更加深刻的認識。

下圖就是集群模式下一個Zookeeper Server節(jié)點提供讀寫服務(wù)的一個流程。

如上圖所示，每個Zookeeper Server節(jié)點除了包含一個請求處理器來處理請求以外，都會有一個內(nèi)存數(shù)據(jù)庫(ReplicatedDatabase) 用于持久化數(shù)據(jù)。ReplicatedDatabase 包含了整個Data Tree。

來自于Client的讀服務(wù)（Read Requst），是直接由對應(yīng)Server的本地副本來進行服務(wù)的。

至于來自于Client的寫服務(wù)（Write Requst），因為Zookeeper要保證每臺Server的本地副本是一致的（單一系統(tǒng)映像），需要通過一致性協(xié)議（后文提到的ZAB協(xié)議）來處理，成功處理的寫請求（數(shù)據(jù)更新）會先序列化到每個Server節(jié)點的本地磁盤（為了再次啟動的數(shù)據(jù)恢復(fù)）再保存到內(nèi)存數(shù)據(jù)庫中。

集群模式下，Zookeeper使用簡單的同步策略，通過以下三條基本保證來實現(xiàn)數(shù)據(jù)的一致性：

全局串行化所有的寫操作

串行化可以把變量包括對象,轉(zhuǎn)化成連續(xù)bytes數(shù)據(jù). 你可以將串行化后的變量存在一個文件里或在網(wǎng)絡(luò)上傳輸. 然后再反串行化還原為原來的數(shù)據(jù)。

保證同一客戶端的指令被FIFO執(zhí)行（以及消息通知的FIFO）

FIFO -先入先出

自定義的原子性消息協(xié)議

簡單來說，對數(shù)據(jù)的寫請求，都會被轉(zhuǎn)發(fā)到Leader節(jié)點來處理，Leader節(jié)點會對這次的更新發(fā)起投票，并且發(fā)送提議消息給集群中的其他節(jié)點，當半數(shù)以上的Follower節(jié)點將本次修改持久化之后，Leader 節(jié)點會認為這次寫請求處理成功了，提交本次的事務(wù)。

Zookeeper 的核心思想就是，提供一個非鎖機制的Wait Free 的用于分布式系統(tǒng)同步的核心服務(wù)。其核心對于文件、數(shù)據(jù)的讀寫服務(wù)，并不提供加鎖互斥的服務(wù)。

但是由于Zookeeper的每次更新操作都會更新ZNode的版本（詳見第一章），也就是客戶端可以自己基于版本的對比，來實現(xiàn)更新數(shù)據(jù)時的加鎖邏輯。例如下圖。

就像我們更新數(shù)據(jù)庫時，會新增一個version字段，通過更新前后的版本對比來實現(xiàn)樂觀鎖。

終于到了ZAB協(xié)議，講述完ZAB協(xié)議，大家對Zookeeper的一些特性會有更深的體會，對本文的其他內(nèi)容也會有更透徹的理解。

ZAB 協(xié)議是為分布式協(xié)調(diào)服務(wù)ZooKeeper專門設(shè)計的一種支持崩潰恢復(fù)的一致性協(xié)議，這個機制保證了各個server之間的同步。全稱 Zookeeper Atomic Broadcast Protocol - Zookeeper 原子廣播協(xié)議。

Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式和廣播模式。

廣播模式類似于分布式事務(wù)中的 Two-phase commit （兩階段式提交），因為Zookeeper中一次寫操作就是被當做一個事務(wù)，所以這實際上本質(zhì)是相同的。

在廣播模式，一次寫請求要經(jīng)歷以下的步驟

ZooKeeper Server接受到Client的寫請求

寫請求都被轉(zhuǎn)發(fā)給Leader節(jié)點

Leader節(jié)點先將更新持久化到本地

Leader節(jié)點將此次更新提議(propose)給Followers，進入收集選票的流程

Follower節(jié)點接收請求，成功將修改持久化到本地，發(fā)送一個ACK給Leader

Leader接收到半數(shù)以上的ACK時，Leader將廣播commit消息并在本地deliver該消息。

當收到Leader發(fā)來的commit消息時，Follower也會deliver該消息。

廣播協(xié)議在所有的通訊過程中使用TCP的FIFO信道，通過使用該信道，使保持有序性變得非常的容易。通過FIFO信道，消息被有序的deliver。只要收到的消息一被處理，其順序就會被保存下來。

但是這種模式下，如果Leader自身發(fā)生了故障，Zookeeper的集群不就提供不了寫服務(wù)了嗎？這就引入了下面的恢復(fù)模式。

簡單點來說，當集群中的Leader故障或者服務(wù)啟動的時候，ZAB就會進入恢復(fù)模式，其中包括Leader選舉和完成其他Server和Leader之間的狀態(tài)同步。

NOTE：選主是ZAB協(xié)議中最為重要和復(fù)雜的過程。這里面的概念知識較多，放在本章一起講反而不利于理解本章的知識，所以我打算在下一章多帶帶介紹，同學們可以選擇性地食用。

一個集群的可伸縮性即可以引入更多的集群節(jié)點，來提升某種性能。Zookeeper實際上就是提供讀服務(wù)和寫服務(wù)。在最早的時候，Zookeeper是通過引入Follower節(jié)點來提升讀服務(wù)的性能。但是根據(jù)我們之前學習過的讀寫機制和ZAB協(xié)議的內(nèi)容，引入新的Follower節(jié)點，會造成Zookeeper 寫服務(wù)的下降，因為Leader發(fā)起的投票是要半數(shù)以上的Follower節(jié)點響應(yīng)才會成功，你Follower多了，就增加了協(xié)議中投票過程的壓力，可能會拖慢整個投票響應(yīng)的速度。結(jié)果就是，Follower節(jié)點增加，集群的寫操作吞吐會下降。

在這種情況下，Zookeeper 在3.3.3版本之后，在集群架構(gòu)中引入了Observer角色，和Follower唯一的區(qū)別的就是不參與投票不參與選主。這樣既提升了讀性能，又不會影響寫性能。

另外提一句，Zookeeper的寫性能是不能被擴展的，這也是他不適合當做服務(wù)注冊發(fā)現(xiàn)中心的一個原因之一，在服務(wù)發(fā)現(xiàn)和健康監(jiān)測場景下，隨著服務(wù)規(guī)模的增大，無論是應(yīng)用頻繁發(fā)布時的服務(wù)注冊帶來的寫請求，還是刷毫秒級的服務(wù)健康狀態(tài)帶來的寫請求，都會Zookeeper帶來很大的寫壓力，因為它本身的寫性能是無法擴展的。后文引的文章會詳細介紹。

分布式領(lǐng)域中存在CAP理論：

C：Consistency，一致性，數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的。

A：Availability，可用性，系統(tǒng)具有好的響應(yīng)性能。

P：Partition tolerance，分區(qū)容錯性。以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇，也就是說無論任何消息丟失，系統(tǒng)都可用。

CAP 定理的含義 -- 阮一峰

該理論已被證明：任何分布式系統(tǒng)只可同時滿足兩點，無法三者兼顧。 因此，將精力浪費在思考如何設(shè)計能滿足三者的完美系統(tǒng)上是愚鈍的，應(yīng)該根據(jù)應(yīng)用場景進行適當取舍。

根據(jù)我們前面學習過的讀寫機制和ZAB協(xié)議的內(nèi)容，Zookeeper本質(zhì)應(yīng)該是一個偏向CP的分布式系統(tǒng)。因為廣播協(xié)議本質(zhì)上是犧牲了系統(tǒng)的響應(yīng)性能的。另外從它的以下幾個特點也可以看出。也就是在第一章最后提出的幾個特點。

① 順序一致性
從同一個客戶端發(fā)起的事務(wù)請求，最終將會嚴格按照其發(fā)起順序被應(yīng)用到ZooKeeper中。
② 原子性
所有事務(wù)請求的結(jié)果在集群中所有機器上的應(yīng)用情況是一致的，也就是說要么整個集群所有集群都成功應(yīng)用了某一個事務(wù)，要么都沒有應(yīng)用，一定不會出現(xiàn)集群中部分機器應(yīng)用了該事務(wù)，而另外一部分沒有應(yīng)用的情況。
③ 單一視圖
無論客戶端連接的是哪個ZooKeeper服務(wù)器，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。
④ 可靠性
一旦服務(wù)端成功地應(yīng)用了一個事務(wù)，并完成對客戶端的響應(yīng)，那么該事務(wù)所引起的服務(wù)端狀態(tài)變更將會被一直保留下來，除非有另一個事務(wù)又對其進行了變更。

直接引一篇阿里中間件的文章吧，講的比我好。實際在生產(chǎn)情況下，大多數(shù)公司沒有達到像大公司那樣的微服務(wù)量級，Zookeeper是完全能滿足服務(wù)注冊中心的需求的。

阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)？

本章主要介紹了Zookeeper的集群架構(gòu)，詳述了ZK的幾種角色和組件，還介紹了Zookeeper的讀寫機制和最核心的ZAB協(xié)議，最后對其他一些比較雜的知識點統(tǒng)一歸在一起討論了一下。

本章的知識我本人認為信息量還是蠻大的，整理完之后我自己對Zookeeper集群服務(wù)的機制原理有了更深的體會。閱讀時最好能夠結(jié)合第一章的一些基礎(chǔ)概念，這樣更有助于理解，讓知識點前后呼應(yīng)。希望能對你理解Zookeeper起到幫助。

下一章我會詳細介紹本章未介紹的Zookeeper選主過程(Leader Election)。

[1]

[2] 阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)？

[3] https://www.cnblogs.com/sundd...

[4] CAP 定理的含義 -- 阮一峰