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

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

本篇的內容主要包含以下幾點：

Zookeeper 集群架構

Zookeeper 讀寫機制

ZAB協議

關于Zookeeper 集群的一些其他討論

Zookeeper（讀性能）可伸縮性 和 Observer節點

Zookeeper 與 CAP 理論

Zookeeper 作為 服務注冊中心的局限性

接下來我們來說一說Zookeeper的集群架構。

第一章提過，Zookeeper中，能改變ZooKeeper服務器狀態的操作稱為事務操作。一般包括數據節點創建與刪除、數據內容更新和客戶端會話創建與失效等操作。

Leader 領導者 ：Leader 節點負責Zookeeper集群內部投票的發起和決議（一次事務操作），更新系統的狀態；同時它也能接收并且響應Client端發送的請求。

Learner 學習者

Follower 跟隨者 ： Follower 節點用于接收并且響應Client端的請求，如果是事務操作，會將請求轉發給Leader節點，發起投票，參與集群的內部投票，

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

Client 客戶端

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

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

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

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

來自于Client的讀服務（Read Requst），是直接由對應Server的本地副本來進行服務的。

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

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

全局串行化所有的寫操作

串行化可以把變量包括對象,轉化成連續bytes數據. 你可以將串行化后的變量存在一個文件里或在網絡上傳輸. 然后再反串行化還原為原來的數據。

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

FIFO -先入先出

自定義的原子性消息協議

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

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

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

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

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

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

Zab協議有兩種模式，它們分別是恢復模式和廣播模式。

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

在廣播模式，一次寫請求要經歷以下的步驟

ZooKeeper Server接受到Client的寫請求

寫請求都被轉發給Leader節點

Leader節點先將更新持久化到本地

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

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

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

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

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

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

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

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

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

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

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

分布式領域中存在CAP理論：

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

A：Availability，可用性，系統具有好的響應性能。

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

CAP 定理的含義 -- 阮一峰

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

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

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

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

阿里巴巴為什么不用 ZooKeeper 做服務發現？

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

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

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

[1]

[2] 阿里巴巴為什么不用 ZooKeeper 做服務發現？

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

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