和選舉有關係的例如Redis Cluster、MongoDB Replica set、Zookeeper基本都是3+以上奇數例項節點，例項節點並不是指機器。選舉有效必須條件之一是參與選舉節點超過總數的一半，若為偶數，因為網路等問題斷開剛好1:1,會認為彼此都是活的相當於腦裂,導致紊亂。所以關於選舉的建議都是3+以上奇數，偶數沒意義，還容易導致更為嚴重的故障。

假如你用的是偶數2臺的機器做master叢集。

您的這種設定，會讓你遇到一些痛苦的問題。

如果Node1和Node2之間的網路連線有任何問題，但兩臺主機本身執行良好，則會出現分裂式大腦（腦裂）情況。

從Node1的角度來看，Node2處於關閉狀態，所以它自己可以提升自己作為master。

然而，從Node2的角度來看，Node1處於關閉狀態，因此它自己可以提升自己作為master。

當網路連線突然開始響應時，您有兩個完整的群集彼此連線。

這就是為什麼建議總是使用奇數個master，並用(number of master / 2) + 1 作為選舉生效的選舉數。

建議可以看看paxos 和精簡版的raft。

raft動畫演示地址：

http://thesecretlivesofdata.com/raft/

事實上，在我遇到的分散式系統中，大多數的叢集都使用了奇數臺設定，比如redis，zookeeper，hadoop等等！

為什麼呢？

在叢集設定中通常有一個原則：處於正常服務狀態的機器大於一半，就認為整個叢集是健康的，能維持整個系統的對外正常服務，具備容災能力！

基於這個原則，我們來做如下假設：

①，只有兩臺機：掛掉一臺，叢集就只剩下剛好半數能提供服務！

②，有三臺機：掛掉一臺，還有兩臺，也就是說還能有2/3＞1.5/3，滿足大於半數的要求！

也就是說三臺機器和四臺機器都只能掛機一臺滿足可執行機器大於半數，2n+1和2n+2的能力一樣，那當然是選擇更少成本的2n+1臺機器了！

同樣的五臺六臺也是如此，所以奇數臺的選擇是在保證叢集穩定原則和成本兩者共同作用下得到的最優選擇！

說回redis：

1，要保證容災能力：需要大於兩臺兩臺的機器實現資料備份，如果只有兩臺，那麼無法保證容災！

2，要保證投票機制：當redis主機掛掉的時候，必須透過投票的方式選擇一臺主機，而條件是獲得一半以上的票，如果只有兩臺機器，投票將只有50%！

分享Java相關技術，是我一直在做的事，其中不乏幾百讚的好文，請持續關注。。。