作者：disksing
對 Raft 有所瞭解的同學都知道，Raft 一般會使用奇數個節點，比如 3、5、7 等等。這是因爲 Raft 是 一種基於多節點投票選舉機制的共識算法，通俗地說，只有超過半數節點在線才能提供服務。這裏超過半數的意思是 N/2+1（而不是N/2）。舉例來說，3 節點集羣需要 2 個以上節點在線，5 節點集羣需要 3 個以上節點在線，等等。對於偶數節點的集羣，2 節點集羣需要 2 節點同時在線，4 節點集羣需要 3 節點在線，以此類推。實際上不只是 Raft，所有基於 Quorum 的共識算法大體上都是這麼個情況，例如 Paxos，ZooKeeper 什麼的，本文僅以 Raft 爲例討論。
先考察一下爲什麼 Raft 通常推薦使用奇數節點而不是偶數節點。
共識算法要解決的核心問題是什麼呢？是分佈式系統中單個節點的不可靠造成的不可用或者數據丟失。Raft 保存數據冗餘副本來解決這兩個問題，當少數節點發生故障時，剩餘的節點會自動重新進行 leader 選舉（如果需要）並繼續提供服務，而且 log replication 流程也保證了剩下的節點（構成 Quorum）總是包含了故障前成功寫入的最新數據，因此也不會發生數據丟失。
我們對比一下 3 節點的集羣和 4 節點的集羣，Quorum 分別是 2 和 3，它們能容忍的故障節點數都是 1。如果深究的話，從概率上來說 4 節點集羣發生 2 節點同時故障的可能性要更高一些。於是我們發現，相對於 3 節點集羣，4 節點集羣消耗更多的硬件資源，卻換來了更差的可用性，顯然不是個好選擇。
但是！！！
上面說了，Raft 解決的核心問題有兩個，分別是高可用和數據容災。跟奇數節點相比，偶數節點的方案從可用性上看很不划算，但是數據容災方面卻是有優勢的。還是以 4 節點爲例，因爲 Quorum 是 3，寫入數據的時候需要複製到至少 3 個節點纔算寫入成功，假如此時有 2 個節點同時故障，這種情況下雖然不可用了，但是剩餘的兩個節點一定包含有最新的數據，因此沒有發生數據丟失。這一點很容易被忽視，在常見的奇數節點配置下，保證可用和保證數據不丟所容忍的故障節點數是重合的，但是在偶數節點配置下是不一樣的。
根據上面的分析，偶數節點集羣的適用場景是“能容忍一定時間的不可用，但不能容忍數據丟失”，應該有不少嚴肅的金融場景是符合這個描述的，畢竟一段時間不服務也比丟掉數據要強呀。
下面以兩數據中心環境爲例來對比一下。限制條件是任意一個數據中心故障時（比如發生嚴重自然災害），能容忍一定時間的不可用，但不允許發生數據丟失。
如果使用奇數節點集羣配置，兩個數據中心的節點數一定是不對等的，一旦節點數更多的那個數據中心故障，就可能發生數據丟失了。而如果使用偶數節點配置，兩個數據中心的節點數是一樣的，任意一個數據中心故障後，另一個數據中心一定包含有最新數據，我們只需要使用工具改寫 Raft 元信息，讓剩餘數據中心的所有節點組成新的 Raft Group 並使得 Quorum 恰好等於剩餘節點數，Raft 選舉機制將會自動選擇包含有最新數據的節點當 leader 並恢復服務。
題外話：本來想在 etcd 上實踐下這套方案，可惜最後一步 etcd 恢復數據的時候只支持從單一節點恢復，所以無法做到“自動選擇包含有最新數據的節點當 leader 並恢復服務”。我給 etcd 提了個 issue 不過貌似並沒有成功讓他們瞭解到我想幹啥，如果有人看到這裏覺得這事情有搞頭的話，可以幫忙去 issue 下支持一下（https://github.com/etcd-io/etcd/issues/11486 ）。
以上內容轉載自 disksing 個人博客：原文地址 。
討論話題：
Raft 通常需要三數據中心來解決高可用問題，但一些場景下面，用戶只有兩個數據中心，那麼使用 Raft 協議還有意義嗎？
歡迎大家在本篇文章下面踊躍留言，分享你遇到過的“偶數節點 Raft”的案例或者各種“奇葩”問題 以及你的思考～
