接著，我們聊聊復雜度的第二個要求高可用。

參考維基百科，先來看看高可用的定義。

系統無中斷地執行其功能的能力，代表系統的可用性程度，是進行系統設計時的準則之一。

這個定義的關鍵在于“ 無中斷”，但恰好難點也在“無中斷”上面，因為無論是單個硬件還是單個軟件，都不可能做到無中斷，硬件會出故障，軟件會有bug；硬件會逐漸老化，軟件會越來越復雜和龐大……

除了硬件和軟件本質上無法做到“無中斷”，外部環境導致的不可用更加不可避免、不受控制。例如，斷電、水災、地震，這些事故或者災難也會導致系統不可用，而且影響程度更加嚴重，更加難以預測和規避。

高可用性是指系統在沒有中斷的情況下能夠持續執行其功能的能力，是進行系統設計時的重要準則之一。然而，要實現無中斷是非常困難的，因為單個硬件或軟件都有可能出現故障或錯誤，且硬件隨著時間的推移會逐漸老化，軟件也會變得越來越復雜和龐大。此外，外部環境因素如斷電、水災、地震等災難也可能導致系統不可用，而且其影響程度更加嚴重，更難以預測和規避。

因此，實現高可用性的方案是通過增加冗余性來提高系統的可用性。簡單來說，就是增加更多的機器或部署多個機房來解決單點故障問題。這樣做的目的是為了增強系統的冗余性，從而實現高可用性。需要注意的是，實現高性能和高可用性都需要增加機器，但它們的目的不同，前者是為了“擴展”處理性能，而后者是為了“冗余”處理單元。

雖然通過冗余增強了系統的可用性，但同時也帶來了復雜性。因此，在實際應用中需要根據不同的場景逐一分析，采取不同的高可用方案。

計算高可用

在這里，“計算”指的是業務邏輯處理。與計算相關的高可用性的復雜性在于，無論在哪臺機器上執行計算，只要算法和輸入數據相同，計算結果就應該是相同的。因此，將計算從一臺機器轉移到另一臺機器，對業務邏輯沒有任何影響。

以最簡單的單機變雙機架構為例，我們可以看到以下幾個方面的復雜性：先來看一個單機變雙機的簡單架構示意圖。

你可能會發現，這個雙機的架構圖和上期“高性能”講到的雙機架構圖是一樣的，因此復雜度也是類似的，具體表現為：

• 需要增加任務分配器，選擇合適的任務分配器也是一個復雜的過程，需要考慮各種因素，例如性能、成本、可維護性和可用性等等。

• 任務分配器與真正的業務服務器之間需要進行連接和交互。因此，需要選擇合適的連接方式，并且對連接進行管理。例如，建立連接、檢測連接、處理連接中斷等等。

• 任務分配器需要增加分配算法。常見的雙機算法有主備、主主，主備方案又可以細分為冷備、溫備、熱備等等。

上面這個示意圖只是簡單的雙機架構，我們再看一個復雜一點的高可用集群架構。

上面這個示意圖只是一個簡單的雙機架構，而復雜度會隨著集群的規模和結構的變化而增加。例如，上圖展示了一個更為復雜的高可用集群架構。這種情況下，分配算法的選擇更加復雜，可以是1主3備、2主2備、3主1備、4主0備等等。具體應該采用哪種方式，需要根據實際業務需求進行分析和判斷，不存在一種算法一定比其他算法更優。例如，ZooKeeper采用的是1主多備，而Memcached則采用全主0備。

存儲高可用

對于需要存儲數據的系統來說，整個系統的高可用設計的關鍵點和難點在于“存儲高可用”。與計算相比，存儲有一個本質的不同點：將數據從一臺機器搬到另一臺機器需要經過線路傳輸。線路傳輸的速度是毫秒級別，同一機房內部可以做到幾毫秒，但分布在不同地方的機房，傳輸耗時需要幾十甚至上百毫秒。例如，從廣州機房到北京機房，穩定情況下ping延時大約是50ms，不穩定情況下可能達到1秒甚至更長。

雖然對人類來說，毫秒幾乎沒有什么感覺，但對于高可用系統來說，這是本質的不同之處。這意味著在某個時間點上，整個系統中的數據肯定是不一致的。按照“數據 + 邏輯 = 業務”這個公式來看，數據不一致即使邏輯一致，最終的業務表現也會不同。以銀行儲蓄業務為例，假設用戶的數據存在北京機房，用戶存入1萬塊錢，然后查詢時被路由到了上海機房，而北京機房的數據沒有同步到上海機房。用戶會發現他的余額并沒有增加1萬塊。想象一下，此時用戶肯定會感到不安，會懷疑自己的錢被盜了，趕緊打客服電話投訴，甚至可能打110報警。即使最終發現只是因為傳輸延遲導致的問題，從用戶的角度來看，這個過程的體驗肯定很不好。

除了物理傳輸速度限制，傳輸線路本身也可能出現可用性問題。傳輸線路可能會中斷、擁塞、異常（如錯包、丟包），并且線路故障的恢復時間通常較長，可能持續幾分鐘甚至幾小時。例如，2015年支付寶因為光纜被挖斷，業務受到了超過4個小時的影響；2016年中美海底光纜中斷3小時等。線路中斷意味著存儲無法同步，這段時間內整個系統的數據將不一致。

綜合考慮，在正常情況下的傳輸延遲和異常情況下的傳輸中斷都會導致系統在某個時間點或時間段內的數據不一致，從而影響業務。然而，如果完全不做冗余，整個系統的高可用性就無法保證。因此，存儲高可用的難點不在于如何備份數據，而在于如何減少或規避數據不一致對業務造成的影響。

在分布式系統領域，有一個著名的CAP定理，從理論上證明了存儲高可用的復雜度。也就是說，存儲高可用不可能同時滿足“一致性、可用性、分區容錯性”，最多只能滿足其中兩個。因此，在架構設計時，需要根據實際業務需求進行取舍。

高可用狀態決策

無論是計算高可用還是存儲高可用，其基礎都是“狀態決策”，即系統需要能夠判斷當前的狀態是正常還是異常，如果出現異常就需要采取行動來保證高可用。如果狀態決策本身存在錯誤或偏差，那么后續的任何行動和處理都將失去意義和價值。然而，在具體實踐中，存在一個本質的矛盾：通過冗余實現的高可用系統，狀態決策本質上不可能做到完全正確。以下是對幾種常見的決策方式的詳細分析：

1.獨裁式

獨裁式決策指的是存在一個獨立的決策主體，我們稱之為“決策者”，其負責收集信息并做出決策。所有冗余的個體，我們稱之為“上報者”，將狀態信息發送給決策者。

獨裁式的決策方式不會出現決策混亂的問題，因為只有一個決策者，但問題也正是在于只有一個決策者。當決策者本身故障時，整個系統就無法實現準確的狀態決策。如果決策者本身又做一套狀態決策，那就陷入一個遞歸的死循環了。

2.協商式

協商式決策指的是兩個獨立的個體通過交流信息，然后根據規則進行決策， 最常用的協商式決策就是主備決策。

這個架構的基本協商規則可以設計成：

• 2臺服務器啟動時都是備機。
• 2臺服務器建立連接。
• 2臺服務器交換狀態信息。
• 某1臺服務器做出決策，成為主機；另一臺服務器繼續保持備機身份。

協商式決策的架構不復雜，規則也不復雜，其難點在于，如果兩者的信息交換出現問題（比如主備連接中斷），此時狀態決策應該怎么做。

• 如果備機在連接中斷的情況下認為主機故障，那么備機需要升級為主機，但實際上此時主機并沒有故障，那么系統就出現了兩個主機，這與設計初衷（1主1備）是不符合的。

• 如果備機在連接中斷的情況下不認為主機故障，則此時如果主機真的發生故障，那么系統就沒有主機了，這同樣與設計初衷（1主1備）是不符合的。

• 如果為了規避連接中斷對狀態決策帶來的影響，可以增加更多的連接。例如，雙連接、三連接。這樣雖然能夠降低連接中斷對狀態帶來的影響（注意：只能降低，不能徹底解決），但同時又引入了這幾條連接之間信息取舍的問題，即如果不同連接傳遞的信息不同，應該以哪個連接為準？實際上這也是一個無解的答案，無論以哪個連接為準，在特定場景下都可能存在問題。

綜合分析，協商式狀態決策在某些場景總是存在一些問題的。

3.民主式

民主式決策指的是多個獨立的個體通過投票的方式來進行狀態決策。例如，ZooKeeper集群在選舉leader時就是采用這種方式。

民主式決策和協商式決策比較類似，其基礎都是獨立的個體之間交換信息，每個個體做出自己的決策，然后按照“ 多數取勝”的規則來確定最終的狀態。不同點在于民主式決策比協商式決策要復雜得多，ZooKeeper的選舉算法ZAB，絕大部分人都看得云里霧里，更不用說用代碼來實現這套算法了。

除了算法復雜，民主式決策還有一個固有的缺陷：腦裂。這個詞來源于醫學，指人體左右大腦半球的連接被切斷后，左右腦因為無法交換信息，導致各自做出決策，然后身體受到兩個大腦分別控制，會做出各種奇怪的動作。例如：當一個腦裂患者更衣時，他有時會一只手將褲子拉起，另一只手卻將褲子往下脫。腦裂的根本原因是，原來統一的集群因為連接中斷，造成了兩個獨立分隔的子集群，每個子集群單獨進行選舉，于是選出了2個主機，相當于人體有兩個大腦了。

從圖中可以看到，正常狀態的時候，節點5作為主節點，其他節點作為備節點；當連接發生故障時，節點1、節點2、節點3形成了一個子集群，節點4、節點5形成了另外一個子集群，這兩個子集群的連接已經中斷，無法進行信息交換。按照民主決策的規則和算法，兩個子集群分別選出了節點2和節點5作為主節點，此時整個系統就出現了兩個主節點。這個狀態違背了系統設計的初衷，兩個主節點會各自做出自己的決策，整個系統的狀態就混亂了。

為了解決腦裂問題，民主式決策的系統一般都采用“投票節點數必須超過系統總節點數一半”規則來處理。如圖中那種情況，節點4和節點5形成的子集群總節點數只有2個，沒有達到總節點數5個的一半，因此這個子集群不會進行選舉。這種方式雖然解決了腦裂問題，但同時降低了系統整體的可用性，即如果系統不是因為腦裂問題導致投票節點數過少，而真的是因為節點故障（例如，節點1、節點2、節點3真的發生了故障），此時系統也不會選出主節點，整個系統就相當于宕機了，盡管此時還有節點4和節點5是正常的。

綜合分析，無論采取什么樣的方案，狀態決策都不可能做到任何場景下都沒有問題，但完全不做高可用方案又會產生更大的問題，如何選取適合系統的高可用方案，也是一個復雜的分析、判斷和選擇的過程。

小結

綜上所述，我向你分析了復雜度之高可用，分析了計算高可用和存儲高可用兩個場景，給出了幾種高可用狀態決策方式，希望對你有幫助