Zookeeper集群節點數量為什麼是奇數個

2021-09-12 18:53:58 字數 1830 閱讀 8601

無論是公司的生產環境,還是自己搭建的測試環境,zookeeper集群的節點個數都是奇數個。至於為什麼要是奇數個,以前只是模糊的知道是為了滿足選舉需要,並不知道詳細的原因。最近重點學習zookeeper,了解到其中的原理,現將其整理記錄下來。

首先需要明確zookeeper選舉的規則:leader選舉,要求 可用節點數量 > 總節點數量/2 。注意 是 > , 不是 ≥。

如果不這樣限制,在集群出現腦裂的時候,可能會出現多個子集群同時服務的情況(即子集群各組選舉出自己的leader),

這樣對整個zookeeper集群來說是紊亂的。

換句話說,如果遵守上述規則進行選舉,即使出現腦裂,集群最多也只能回出現乙個子集群可以提供服務的情況(能滿足節點數量》 總結點數量/2

的子集群最多隻會有乙個)。所以要限制 可用節點數量 > 集群總結點數量/2 。

採用奇數個的節點主要是出於兩方面的考慮:

1、防止由腦裂造成的集群不可用。

首先,什麼是腦裂?集群的腦裂通常是發生在節點之間通訊不可達的情況下,集群會**成不同的小集群,小集群各自選出自己的master節點,導致原有的集群出現多個master節點的情況,這就是腦裂。

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

(1) 假如zookeeper集群有 5 個節點,發生了腦裂,腦裂成了a、b兩個小集群:

(a) a : 1個節點 ,b :4個節點 , 或 a、b互換

(b) a : 2個節點, b :3個節點 , 或 a、b互換

可以看出,上面這兩種情況下,a、b中總會有乙個小集群滿足 可用節點數量 > 總節點數量/2 。所以zookeeper集群仍然能夠選舉出leader , 仍然能對外提供服務,只不過是有一部分節點失效了而已。

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

(a) a:1個節點 ,  b:3個節點,   或 a、b互換 

(b) a:2個節點 , b:2個節點

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

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

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

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

leader選舉,要求 可用節點數量 > 總節點數量/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集群的節點數維持奇數個更好一些。

--------------------- !

Zookeeper集群節點數量為什麼要奇數個

防腦裂 zookeeper的選舉策略也是需要半數以上的節點同意才能當選leader,如果是偶數節點可能導致票數相同的情況 在節點數量是奇數個的情況下,zookeeper集群總能對外提供服務 即使損失了一部分節點 如果節點數量是偶數個,會存在zookeeper集群不能用的可能性 腦裂成兩個均等的子集群...

位元幣節點數量減少14

據bitnodes統計,今年位元幣區塊鏈上的 可達節點 reachable nodes 數量減少了13.95 從11845個到10193個 截至發稿時 同一時間,不可達節點 unreachable nodes 的數量也至少有30 的 reachable nodes指的是既可以傳送又可以接收來自位元幣...

ES中 節點數量,分片數量,副本數量關係配比

副本分片數量 總結一下 建立索引庫的時候,要設計分片數量和副本數量,分片和副本是分布式搜尋引擎的核心。如何指定分片進行增刪改查操作?每個分片儲存多少資料合適?我們的文件存在哪個分片中?為什麼不可以修改主分片數量?一次完整的es查詢流程怎麼流的?節點數量很好說,你要是只有兩三個伺服器,還想啥自行車呢。...