大廠分佈式面試題分享：ZooKeeper集羣如何實現高可用部署？

Zookeeper 我想你們都不陌生，在不少場合都聽到它的名字。它是 Apache 的一個頂級項目，爲分佈式應用提供一致性高性能協調服務。能夠用來作：配置維護、域名服務、分佈式鎖等。有不少開源組件，尤爲是中間件領域，使用 Zookeeper 做爲配置中心或者註冊中心。它是 Hadoop 和 HBase 的重要組件，是 Kafka 的管理和協調服務，是 Dubbo 等服務框架的註冊中心等。

原理

在介紹高可用部署前，咱們先了解下 Zookeeper 的基本知識，這對充分理解它的高可用部署很是重要。

架構

下圖是 Zookeeper 的架構圖，ZooKeeper 集羣中包含 Leader、Follower 以及 Observer 三個角色：

• Leader：負責進行投票的發起和決議，更新系統狀態，Leader 是由選舉產生;
• Follower： 用於接受客戶端請求並向客戶端返回結果，在選主過程當中參與投票;
• Observer：能夠接受客戶端鏈接，接受讀寫請求，寫請求轉發給 Leader，但 Observer 不參加投票過程，只同步 Leader 的狀態，Observer 的目的是爲了擴展系統，提升讀取速度。

Client 是 Zookeeper 的客戶端，請求發起方。

高可用

Zookeeper 系統中只要集羣中存在超過一半的節點（這裏指的是投票節點即非 Observer 節點）可以正常工做，那麼整個集羣就可以正常對外服務

基於此，若是想搭建一個可以容許 N 臺機器 down 掉的集羣，那麼就要部署一個由 2*N+1 臺服務器構成的 ZooKeeper 集羣。

所以，若是部署了 3 個 Zookeeper 節點（非 Observer），則若是至少有 2個節點可用則整個集羣就可用，意味着 1 個節點故障，不影響 Zookeeper 集羣對外提供服務；若是部署了 5 個節點，意味着 2 個節點同時故障，Zookeeper 集羣依然可以正常對外提供服務。

Zookeeper 集羣部署的節點（非 Observer）數通常爲奇數個

部署的節點數通常爲奇數個，這裏不是說不能爲偶數個。例如若是部署了 4 個節點，這意味着須要 4/2+1 = 3 個節點正常，集羣才能正常對外服務，便可以容忍 1 個節點故障，可是這個部署 3 個節點，其實效果是同樣的，也就是說部署偶數個，從高可用方面來講只是浪費了 1 臺機器而已。

部署

既然只要 Zookeeper 集羣中存在超過一半的節點可以正常工做，集羣就可以正常服務，那 Zookeeper 若是想要 Zookeeper 高可用豈不是很簡單，是否是多部署幾個節點不就行了呢？

多部署節點就高可用了？

多部署節點，貌似確實是可以加強可用性，可是這裏還須要考慮如下兩個問題：

• 多增長節點對性能和寫可用性有影響 增長節點，意味了可以容忍非正常節點數更多，聽起來高可用是更高了。可是，節點數越多意味着 Leader 發出的提案須要更多的節點（半數以上）來接受提案，這必然增長提案 commit 的耗時，也就意味着對寫請求的性能以及可用性影響比較大。所以，對於正常的業務系統來講須要完美的權衡利弊，來調整節點的個數。
• 須要考慮容災需求 部署還得結合容災要求，須要能在機房故障，地區故障時整個 Zookeeper 集羣是否能正常對外提供服務。

機房容災

若是要保證在整個機房出現故障的狀況下，保證 Zookeeper 集羣的高可用，是要對 Zookeeper 作跨機房部署的。

單機房

咱們先看下單機房部署狀況下，下圖是單個機房 5 個節點的部署狀況。在單機房部署的狀況下是不能作到機房容災的，一旦機房出現問題，整個 Zookeeper 集羣就不能對外工做。

單機房部署還需考慮所選的節點應該儘可能不在同一個宿主機，不一樣機櫃，避免多個節點同時出現問題。

同城雙機房

既然單機房作不到機房容災，那雙機房呢？

以下圖在「機房 1」部署 3 個節點，「機房 2」部署 2 個節點，總共 5 個節點的 Zookeeper 集羣，這能作到機房容災嗎？任意一個機房故障，集羣都能正常對外提供工做嗎？

其實，仍是不行的。假如「機房 2」故障，「機房 1」正常，這種狀況下，由於「機房 1」存在 3 個節點，大於半數，所以仍是可以正常工做的；可是，假如「機房 1」故障，那存活節點數只有 2 個，整個集羣是不能正常工做的。

所以，Zookeeper 雙機房部署，是不可以作到機房容災的。

同城三機房

咱們再來看看三機房部署，三機房部署，是可以作到機房容災的。仍是以 5 個節點的集羣爲例：

以下圖，在「機房 1」、「機房 2」同時部署 2 個節點，而「機房 3」 部署 1 個節點。在任意一個機房故障的狀況下，都能知足正常節點數大於半數及以上，因此可以保證機房容災。

異地容災

僅僅作到機房級別的容災，對於通常的業務應該就夠了，不過目前不少公司採用的是兩地三中心模式，螞蟻金服甚至作到了三地五中心。在這種狀況下，咱們的 Zookeeper 集羣應該如何部署呢？

兩地三中心

「兩地三中心」即生產數據中心、同城災備中心、異地災備中心建設方案。這種模式下，兩個城市的三個數據中心互聯互通，若是一個數據中心發生故障或災難，其餘數據中心能夠正常運行並對關鍵業務或所有業務實現接管。

在兩地三中心的的模式下，Zookeeper 集羣的部署有哪些考量呢？

以下圖，通常兩地三中心採用的是下面這種部署方式。在「地區 1」有兩個同城數據中心，「中心 1」和「中心2」，在異地「地區 2」 有一個異地中心「中心 1」。這裏你可能有兩個疑問：

• 爲何投票節點（Follower 和 Leader）都放在「地區 1 中心 1」，而不是按照三機房相似的方案在三個中心都進行部署呢？
• 這裏是由於因爲異地之間的物理距離比較長，網絡傳輸時延比較大，致使集羣的投票節點的決策時間比較長，進而影響寫性能。試想一下，若是兩地選用的是北京和上海兩座城市，走專線網絡延時約 30ms，在寫數據時，須要半數節點贊成提案，一個寫請求才能成功。所以，一次寫成功的時間會比較長。 另外，異地之間的網絡比較複雜，很容易出現集羣從新選舉，致使整個集羣不可用，並且選舉時間會比較長。 所以，通常只在一箇中心內作到三機房部署，其餘中心都是用 Observer 節點，能夠看出，部署上 Zookeeper 集羣沒法作到異地容災的。
• 爲何引入了 Observer 節點？
• Observer 能很好的對 Zookeeper 集羣進行擴展，Observer 能夠提供 Client 讀寫，但不參與投票。所以，Observer 節點對集羣不影響投票耗時，也不影響集羣選舉。另外，加入 Observer 對讀性能是一個很大的提高。

三中心優化

爲了保護集羣，在三個中心都部署上 Observer 節點，而 Client 只與 Observer 機點進行交互，用這種方式能夠下降投票節點的工做負載，下降 Leader 和 Follower 的不穩定性，從而提升整個集羣的穩定性和可用性。

總結

Zookeeper 的高可用在部署上也是有不少考量的，Zookeeper 集羣在部署上能夠作到機房容災，可是作不到異地容災。另外，爲了提高集羣的擴展性和穩定性，能夠引入 Observer 節點，提高讀性能，保護 Leader 與 Follower 節點。

共同進步，學習分享

歡迎你們關注個人公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！