[[413929]]

本文轉載自微信公眾號「程序新視界」，作者丑胖俠二師兄 。轉載本文請聯系程序新視界公眾號。

目前大多數項目都在往分布式上發(fā)展，一旦系統采用分布式系統，便會引入更多復雜場景和解決方案。比如，當你在系統中使用了Elasticsearch、ZooKeeper集群時，你是否了解過集群的“腦裂”現象?又是否知道它們是如何解決腦裂問題的?

如果這些都還未了解，那么你對分布式的了解過于表象了，推薦你讀一讀這篇文章。

下面就以zookeeper為例，帶大家了解一下分布式系統中的腦裂現象及如何解決。

什么是腦裂?

在Elasticsearch、ZooKeeper這些集群環(huán)境中，有一個共同的特點，就是它們有一個“大腦”。比如，Elasticsearch集群中有Master節(jié)點，ZooKeeper集群中有Leader節(jié)點。

集群中的Master或Leader節(jié)點往往是通過選舉產生的。在網絡正常的情況下，可以順利的選舉出Leader(后續(xù)以Zookeeper命名為例)。但當兩個機房之間的網絡通信出現故障時，選舉機制就有可能在不同的網絡分區(qū)中選出兩個Leader。當網絡恢復時，這兩個Leader該如何處理數據同步?又該聽誰的?這也就出現了“腦裂”現象。

通俗的講，腦裂(split-brain)就是“大腦分裂”，本來一個“大腦”被拆分成兩個或多個。試想，如果一個人有多個大腦，且相互獨立，就會導致人體“手舞足蹈”，“不聽使喚”。

了解了腦裂的基本概念，下面就以zookeeper集群的場景為例，來分析一下腦裂的發(fā)生。

zookeeper集群中的腦裂

我們在使用zookeeper時，很少遇到腦裂現象，是因為zookeeper已經采取了相應的措施來減少或避免腦裂的發(fā)生，這個后面會講到Zookeeper的具體解決方案。現在呢，先假設zookeeper沒有采取這些防止腦裂的措施。在這種情況下，看看腦裂問題是如何發(fā)生的。

現有6臺zkServer服務組成了一個集群，部署在2個機房：

腦裂

正常情況下，該集群只有會有個Leader，當Leader宕掉時，其他5個服務會重新選舉出一個新的Leader。

如果機房1和機房2之間的網絡出現故障，暫時不考慮Zookeeper的過半機制，那么就會出現下圖的情況：

腦裂

也就是說機房2的三臺服務檢測到沒有Leader了，于是開始重新選舉，選舉出一個新Leader來。原本一個集群，被分成了兩個集群，同時出現了兩個“大腦”，這就是所謂的“腦裂”現象。

由于原本的一個集群變成了兩個，都對外提供服務。一段時間之后，兩個集群之間的數據可能會變得不一致了。當網絡恢復時，就面臨著誰當Leader，數據怎么合并，數據沖突怎么解決等問題。

當然，上面的過程只是我們假設Zookeeper不做任何預防腦裂措施時會出現的問題。那么，針對腦裂問題，Zookeeper是如何進行處理的呢?

Zookeeper的過半原則

防止腦裂的措施有多種，Zookeeper默認采用的是“過半原則”。所謂的過半原則就是：在Leader選舉的過程中，如果某臺zkServer獲得了超過半數的選票，則此zkServer就可以成為Leader了。

底層源碼實現如下：

public class QuorumMaj implements QuorumVerifier { 
  
    int half; 
     
    // QuorumMaj構造方法。 
    // 其中，參數n表示集群中zkServer的個數，不包括觀察者節(jié)點 
    public QuorumMaj(int n){ 
        this.half = n/2; 
    } 
 
    // 驗證是否符合過半機制 
    public boolean containsQuorum(Set<Long> set){ 
        // half是在構造方法里賦值的 
        // set.size()表示某臺zkServer獲得的票數 
        return (set.size() > half); 
    } 
} 

上述代碼在構建QuorumMaj對象時，傳入了集群中有效節(jié)點的個數;containsQuorum方法提供了判斷某臺zkServer獲得的票數是否超過半數，其中set.size表示某臺zkServer獲得的票數。

上述代碼核心點兩個：第一，如何計算半數;第二，投票屬于半數的比較。

以上圖6臺服務器為例來進行說明：half = 6 / 2 = 3，也就是說選舉的時候，要成為Leader至少要有4臺機器投票才能夠選舉成功。那么，針對上面2個機房斷網的情況，由于機房1和機房2都只有3臺服務器，根本無法選舉出Leader。這種情況下整個集群將沒有Leader。

腦裂

在沒有Leader的情況下，會導致Zookeeper無法對外提供服務，所以在設計的時候，我們在集群搭建的時候，要避免這種情況的出現。

如果兩個機房的部署請求部署3：3這種狀況，而是3：2，也就是機房1中三臺服務器，機房2中兩臺服務器：

在上述情況下，先計算half = 5 / 2 = 2，也就是需要大于2臺機器才能選舉出Leader。那么此時，對于機房1可以正常選舉出Leader。對于機房2來說，由于只有2臺服務器，則無法選出Leader。此時整個集群只有一個Leader。

對于上圖，顛倒過來也一樣，比如機房1只有2臺服務器，機房2有三臺服務器，當網絡斷開時，選舉情況如下：

Zookeeper集群通過過半機制，達到了要么沒有Leader，要沒只有1個Leader，這樣就避免了腦裂問題。

對于過半機制除了能夠防止腦裂，還可以實現快速的選舉。因為過半機制不需要等待所有zkServer都投了同一個zkServer就可以選舉出一個Leader，所以也叫快速領導者選舉算法。

新舊Leader爭奪

通過過半原則可以防止機房分區(qū)時導致腦裂現象，但還有一種情況就是Leader假死。

假設某個Leader假死，其余的followers選舉出了一個新的Leader。這時，舊的Leader復活并且仍然認為自己是Leader，向其他followers發(fā)出寫請求也是會被拒絕的。

因為ZooKeeper維護了一個叫epoch的變量，每當新Leader產生時，會生成一個epoch標號(標識當前屬于那個Leader的統治時期)，epoch是遞增的，followers如果確認了新的Leader存在，知道其epoch，就會拒絕epoch小于現任leader epoch的所有請求。

那有沒有follower不知道新的Leader存在呢，有可能，但肯定不是大多數，否則新Leader無法產生。ZooKeeper的寫也遵循quorum機制，因此，得不到大多數支持的寫是無效的，舊leader即使各種認為自己是Leader，依然沒有什么作用。

ZooKeeper集群節(jié)點為什么要部署成奇數

上面講了過半原則，由于Zookeeper默認采用的就是這種策略，那就帶來另外一個問題。集群的數量設置為多少合適呢?而我們所看到的Zookeeper節(jié)點數一般都是奇數，這是為什么呢?

首先，只要集群中有過半的機器是正常工作的，那么整個集群就可對外服務。那么我們列舉一些情況，來看看在這些情況下集群的容錯性。

如果有2個節(jié)點，那么只要掛掉1個節(jié)點，集群就不可用了。此時，集群對的容忍度為0;

如果有3個節(jié)點，那么掛掉1個節(jié)點，還有剩下2個正常節(jié)點，超過半數，可以重新選舉，正常服務。此時，集群的容忍度為1;

如果有4個節(jié)點，那么掛掉1個節(jié)點，剩下3個，超過半數，可以重新選舉。但如果再掛掉1個，只剩下2個，就無法正常選舉和服務了。此時，集群的容忍度為1;

依次類推，5個節(jié)點，容忍度為2;6個節(jié)點容忍度同樣為2;

既然3個節(jié)點和4個節(jié)點、5個節(jié)點和6個節(jié)點，也就是2n和2n-1的容忍度是一樣的，都是n-1。那么，為了節(jié)省資源，為了更加高效(更多節(jié)點參與選舉和通信)，為什么不少一個節(jié)點呢?這就是為什么集群要部署成奇數的原因。

解決腦裂的常見方法

上面提到了Zookeeper使用的過半原則，這里再把解決腦裂問題的場景方式總結一下。

方法一，Quorums(法定人數)方式

比如3個節(jié)點的集群，Quorums = 2，也就是說集群可以容忍1個節(jié)點失效，這時候還能選舉出1個lead，集群還可用。比如4個節(jié)點的集群，它的Quorums = 3，Quorums要超過3，相當于集群的容忍度還是1，如果2個節(jié)點失效，那么整個集群還是無效的。這是ZooKeeper防止“腦裂”默認采用的方法。

方法二，添加心跳線

集群中采用多種通信方式，防止一種通信方式失效導致集群中的節(jié)點無法通信。

比如，添加心跳線。原來只有一條心跳線路，此時若斷開，則接收不到心跳報告，判斷對方已經死亡。若有2條心跳線路，一條斷開，另一條仍然能夠接收心跳報告，能保證集群服務正常運行。心跳線路之間也可以 HA(高可用)，這兩條心跳線路之間也可以互相檢測，若一條斷開，則另一條馬上起作用。正常情況下，則不起作用，節(jié)約資源。

方法三，啟動磁盤鎖定方式。

使用磁盤鎖的形式，保證集群中只能有一個Leader獲取磁盤鎖，對外提供服務，避免數據錯亂發(fā)生。但是，也會存在一個問題，若該Leader節(jié)點宕機，則不能主動釋放鎖，那么其他的Follower就永遠獲取不了共享資源。于是有人在HA中設計了"智能"鎖。正在服務的一方只有在發(fā)現心跳線全部斷開(察覺不到對端)時才啟用磁盤鎖。平時就不上鎖了

方法四，仲裁機制方式。

腦裂導致的后果是從節(jié)點不知道該連接哪一臺Leader，此時有一個仲裁方就可以解決此問題。比如提供一個參考的IP地址，心跳機制斷開時，節(jié)點各自ping一下參考IP，如果ping不通，那么表示該節(jié)點網絡已經出現問題，則該節(jié)點需要自行退出爭搶資源，釋放占有的共享資源，將服務的提供功能讓給功能更全面的節(jié)點。

以上方式可以同時使用，可以減少集群中腦裂情況的發(fā)生，但不能完全保證，比如仲裁機制中2臺機器同時宕機，那么此時集群中沒有Leader 可以使用。此時就需要人工干預了。

小結

我們經常在說，我們的系統使用了分布式，但我們真的了解分布式中場景的一些場景和解決方案嗎?通過本文對腦裂場景的分析及解決方案介紹，你學到了嗎?來一起學習吧。