關於Zookeeper叢集搭建節點數量為什麼是2n+1個問題

語言: CN / TW / HK

我們之前學習zookeeper叢集節點搭建時一直都是搭建叢集數為2n+1,不管是自己搭建還是公司搭建都是2n+1,至於為什麼是2n+1一直都是一個模糊的概念,今天我重點學習了一下zookeeper翻閱了大量的資料大概理解了一下,現將其整理記錄下來。

首先我們要先理解一下zookeeper的選舉機制

得到的票數/叢集的總數 > 50%就成leader(這句話很關鍵)
在這裡插入圖片描述

  1. 當啟動了130,130就會投自己一票 此時的到的總票數 1/3=30%
  2. 啟動129:
    129與130進行新一輪投票
    129 投自己一票 1/3
    130 投自己一票 1/3


  3. pk投票
    pk規則(選舉的規則)
    3.1. 對比事物id(zxid)誰大就該投誰
    假如出現事物id相同
    3.2. 比較伺服器id誰大(myid),就改投誰。130=3 129=2
    130勝出,129改投130
    130 票數 2/3 = 66% > 50% leader





  4. 128啟動時同理所以130必定當選leader

所以這個時候建議伺服器效能比較好,設定他的id值大一些

當我們瞭解了zookeeper選舉機制後就能來講為什麼叢集需要2n+1個
1、防止由腦裂問題造成的叢集不可用。

關於腦裂首先我們來講一下什麼是腦裂
在"雙機熱備"高可用(HA)系統中,當聯絡兩個節點的"心跳線"斷開時(即兩個節點斷開聯絡時),本來為一個整體、動作協調的HA系統,就分裂成為兩個獨立的節點(即兩個獨立的個體)。由於相互失去了聯絡,都以為是對方出了故障,兩個節點上的HA軟體像"裂腦人"一樣,“本能"地爭搶"共享資源”、爭起"應用服務"。就會發生嚴重後果:
1)或者共享資源被瓜分、兩邊"服務"都起不來了;
2)或者兩邊"服務"都起來了,但同時讀寫"共享儲存",導致資料損壞(常見如資料庫輪詢著的聯機日誌出錯)。


兩個節點相互爭搶共享資源,結果會導致系統混亂,資料損壞。對於無狀態服務的HA,無所謂腦裂不腦裂,但對有狀態服務(比如MySQL)的HA,必須要嚴格防止腦裂
[但有些生產環境下的系統按照無狀態服務HA的那一套去配置有狀態服務,結果就可想而知]
首先,什麼是腦裂?叢集的腦裂通常是發生在節點之間通訊不可達的情況下,叢集會分裂成不同的小叢集,小叢集各自選出自己的master節點,導致原有的叢集出現多個master節點的情況,這就是腦裂。

腦裂導致的問題

引起資料的不完整性:叢集中節點(在腦裂期間)同時訪問同一共享資源,而且沒有機制去協調控制的話,那麼就存在資料的不完整性的可能。
服務異常:對外提供的服務出現異常。

現在我們來說一下現在我們來說一下Zookeeper 叢集中的"腦裂"場景說明

對於一個叢集,想要提高這個叢集的可用性,通常會採用多機房部署,比如現在有一個由6臺zkServer所組成的一個叢集,部署在了兩個機房:

在這裡插入圖片描述

正常情況下,此叢集只會有一個Leader,那麼如果機房之間的網路斷了之後,兩個機房內各自的zkServer還是可以相互通訊的,如果不考慮過半機制,那麼就會出現每個機房內部根據選舉都將選出一個Leader。這就是資訊不可達問題

在這裡插入圖片描述

這就相當於本來是同一個叢集的,被分成了不同的兩個叢集,兩個叢集都根據選舉出現了兩個leader,這就是腦裂現象。對於這種情況,其實也可以看出來,原本應該是統一的一個叢集對外提供服務的,現在變成了兩個叢集同時對外提供服務,如果過了一會,斷了的網路突然聯通了,那麼就會出現問題,兩個叢集剛剛都對外提供服務了,兩個機房中誰才是那個leader ,資料該由誰去解決,資料衝突問題怎麼解決。

在叢集中單機房中也會出現腦裂問題

我們從上述簡介中可以知道,假設一個叢集、動作協調的節點A和節點B,節點A和B之間通過heartBeat來檢查對方的存活狀態,負責協調保證整個叢集服務的可用性。正常情況下,如果節點A通過心跳檢測不到B的存在的時候,就會接管B的資源,同理節點B檢查不到B的存活狀態的時候也會接管A的資源。如果出現網路故障,就會導致A和B同時檢查不到對方的存活狀態認為對方出現異常,這個時候就會導致A接管B的資源,B也會接管A的資源。也會出現多個leader的情況

原本是統一的一個叢集對外提供服務的,現在變成了兩個叢集同時對外提供服務,兩個叢集都對外提供服務了,這就是腦裂導致的資訊不一致。
在這裡插入圖片描述

下面舉例說一下為什麼採用奇數臺節點,就可以防止由於腦裂造成的服務不可用:

(1) 假如zookeeper叢集有 5個節點,分別放在了不同的機房假設機房中放的個數不同(這樣也模模擬出了 同一機房發生腦裂的問題),現在網路突然波動,發生了腦裂,腦裂成了A、B兩個小叢集:

 第一種情況    A機房 : 1個節點 ,B 機房:4個節點 

 第二種情況    A機房 : 2個節點, B機房 :3個節點  

可以看出,上面這兩種情況下當網路恢復時,A、B中總會有一個小叢集滿足 可用節點數量 > 總節點數量/2。所以zookeeper叢集仍然能夠選舉出leader , 仍然能對外提供服務,並且能整合資料,只不過是有一部分節點失效了而已。

(2) 假如zookeeper叢集有4個節點,同樣發生腦裂,腦裂成了A、B兩個小叢集:

 第一種情況    A機房 : 1個節點 ,B 機房:3個節點 

 第二種情況    A機房 : 2個節點, B機房 :2個節點  

可以看出,情況1 是滿足選舉條件的,與(1)中的例子相同。 但是情況2 就不同了,因為A和B都是2個節點,都不滿足 可用節點數量 >總節點數量/2 的選舉條件, 所以此時zookeeper就徹底不能提供服務了。

在同一個機房中也是一樣的,在奇數個伺服器中,不管腦裂成什麼情況個數不同的叢集,只要是叢集多的推選出leader票數必定大於1/2。

所以綜合上面兩個例子可以看出: 在節點數量是奇數個的情況下, zookeeper叢集總能對外提供服務(即使損失了一部分節點);如果節點數量是偶數個,會存在zookeeper叢集不能用的可能性(腦裂成兩個均等的子叢集的時候)。

在生產環境中,如果zookeeper叢集不能提供服務,那將是致命的 , 所以zookeeper叢集的節點數一般採用奇數個。

2、在容錯能力相同的情況下,奇數臺更節省資源。

(1) 假如zookeeper叢集1 ,有3個節點,3/2=1.5 , 即zookeeper想要正常對外提供服務(即leader選舉成功),至少需要2個節點是正常的。換句話說,3個節點的zookeeper叢集,允許有一個節點宕機。

(2) 假如zookeeper叢集2,有4個節點,4/2=2 ,
即zookeeper想要正常對外提供服務(即leader選舉成功),至少需要3個節點是正常的。換句話說,4個節點的zookeeper叢集,也允許有一個節點宕機。

那麼問題就來了, 叢集1與叢集2都有
允許1個節點宕機的容錯能力,但是叢集2比叢集1多了1個節點。在相同容錯能力的情況下,本著節約資源的原則,zookeeper叢集的節點數維持奇數個更好一些。

3.確保事務能夠順利進行

先看圖再分析

在這裡插入圖片描述

對於zookeeper的 create, setData, delete 等有寫操作的請求,則需要統一轉發給leader 處理, leader
需要決定編號、執行操作,這個過程稱為一個事務。ZAB的事務2pc, 3pc(TCC)

舉個例子寫操作時leader寫資料,傳送給叢集中的其他服務進行寫的操作。其他伺服器寫完要返回結果給leader成功或者是失敗,如果超過50%寫成功了,leader就認為這次寫操作成,返回給客戶端操作成功。如果收到的成功率沒有超過50%,認為操作失敗,傳送請求讓所有叢集中的其他服務進行回滾操作(2pc協議)

根據上述描述我們可以清楚的了,假設我們搭建的zookeeper節點是6臺伺服器的話在進行,在進行事務操作時只有2臺收到了成功,這個時候成功的zookeeper伺服器一共有三臺(包括leader自己)那麼此時3/6=50% 的這個時候就沒辦法判斷是否成功
當節點是奇數時就可以準確的得知是否操作成功。
假設有7臺伺服器,在進行操作時有3臺伺服器讀取成功,這個時候一共有四臺伺服器讀取成功4/7>50%當只有2臺成功時3/7<50%,那麼就可以很簡單的判斷出寫操作是否成功

擴充套件知識內容

1.zookeeper核心

Zookeeper的核心是原子廣播,這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式,它們分別是恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者 崩潰後,Zab就進入了恢復模式,當領導者被選舉出來,且大多數Server完成了和leader的狀態同步以後,恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。

• 為了保證事務的順序一致性,zookeeper採用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64位的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選出來,它都會有一個新的epoch,標識當前屬於那個leader的統治時期。低32位用於遞增計數。

2、Zookeeper 的讀寫機制

» Zookeeper是一個由多個server組成的叢集   
» 一個leader,多個follower   
»每個server儲存一份資料副本   
» 全域性資料一致   
» 分散式讀寫   
» 更新請求轉發,由leader實施




3、Zookeeper 的保證

» 更新請求順序進行,來自同一個client的更新請求按其傳送順序依次執行
» 資料更新原子性,一次資料更新要麼成功,要麼失敗   
» 全域性唯一資料檢視,client無論連線到哪個server,資料檢視都是一致的
» 實時性,在一定事件範圍內,client能讀到最新資料


4、Zookeeper節點資料操作流程

1.在Client向Follwer發出一個寫的請求
2.Follwer把請求傳送給Leader
3.Leader接收到以後開始發起投票並通知Follwer進行投票
4.Follwer把投票結果傳送給Leader
5.Leader將結果彙總後如果需要寫入,則開始寫入同時把寫入操作通知給Leader,然後commit;
6.Follwer把請求結果返回給Client