高可用性定義為系統持續不間斷地執行其功能的能力，是衡量系統可用性的重要指標之一。這一概念的核心在于實現“無中斷”運行，但這正是其實現過程中的主要挑戰。由于無論硬件還是軟件都難以避免出現故障——硬件可能會遭遇故障和老化，軟件可能存在bug且隨著時間推移變得更加復雜和龐大。此外，外部因素如斷電、自然災害等也可能導致系統服務中斷，這些因素往往不可預測且難以控制。

因此，實現系統的高可用性通常依賴于“冗余”的概念。簡而言之，如果一臺服務器不足以保障服務的持續性，那么就使用兩臺，如果兩臺還不夠，那么就增加到四臺，以此類推。對于可能出現的斷電情況，可以在多個地理位置部署服務器。如果擔心網絡通道的不穩定，可以同時使用多個網絡服務提供商。雖然從表面上看，無論是為了提升性能還是實現高可用性，解決方案似乎都是增加更多的機器，但二者的目的完全不同：提升性能的目的是“擴展”系統的處理能力，而實現高可用性的目的則是通過增加“冗余”單元來確保服務的連續性和穩定性。

計算高可用

這里的“計算”指的是業務的邏輯處理。計算有一個特點就是無論在哪臺機器上進行計算，同樣的算法和輸入數據，產出的結果都是一樣的，所以將計算從一臺機器遷移到另外一臺機器，對業務并沒有什么影響。既然如此，計算高可用的復雜度體現在哪里呢？我以最簡單的單機變雙機為例進行分析。先來看一個單機變雙機的簡單架構示意圖：

圖片

你可能會注意到，提到的雙機架構與我們之前在“高性能”主題中討論的架構非常相似，因此它們的復雜性也有所類似。具體來說：

盡管上述討論的只是一個基礎的雙機架構，我們還可以進一步探討更為復雜的高可用集群架構。與簡單的雙機設置相比，高可用集群在分配算法上更為復雜，配置形式包括但不限于1主3備、2主2備、3主1備、到4主0備等不同組合。選擇哪種配置方案，需根據實際業務需求進行分析和判斷，因為并沒有一種算法能夠絕對勝出。例如，ZooKeeper就采用了1主多備的模式，而Memcached則是采用了全主0備的策略。

存儲高可用

在設計需要數據存儲的系統時，確保存儲的高可用性成為整個系統設計的關鍵和挑戰所在。與計算任務不同，存儲任務的一個基本區別在于數據需要通過網絡線路從一臺機器傳輸到另一臺機器。這種傳輸的速度受到物理限制，即便是在同一個機房內，傳輸速度也可能只有幾毫秒，而跨越不同地域的機房，傳輸延時則可能增至數十甚至上百毫秒。例如，從廣州到北京的機房之間，穩定時的網絡延遲大約是50毫秒，但在不穩定的網絡環境下，延遲可能會增加到1秒甚至更長。

為了解決這一問題，系統設計中通常會加入任務分配器，其選擇依賴于多種因素，包括性能、成本、可維護性和可用性等。任務分配器不僅需要處理與業務服務器之間的連接和交互，還需選取適宜的連接方式，并妥善管理這些連接，如連接的建立、檢測和斷開后的處理策略。

此外，任務分配器還需配備高效的分配算法，如主備、雙主等模式，其中主備模式又可以細分為冷備、溫備和熱備等。盡管對于人類來說，毫秒級的時間差異幾乎感覺不到，但對于追求高可用的系統而言，這種時間差意味著數據的瞬時不一致性，這對系統的整體業務有著根本性的影響。

舉個例子，銀行儲蓄業務中，如果客戶在北京機房存入金額，而此時數據尚未同步至上海機房，當客戶查詢余額時可能會發現新存入的金額未能顯示，造成用戶疑慮，這種體驗對客戶而言極為不佳。他們可能會擔心自己的資金安全，甚至可能導致客戶投訴或報警。即使最終確認問題僅因為數據同步的延遲，對用戶而言，這段經歷的體驗仍是負面的。

圖片

除了物理傳輸速度的限制，網絡線路的可靠性也是一個重要考慮因素。線路可能會遇到中斷、擁堵或異常情況（如數據錯誤、丟失），并且這些問題的修復時間可能長達數小時。以往的事故中，如2015年支付寶因光纜被挖斷而業務受影響超過4小時，2016年中美之間的海底光纜斷裂導致通訊中斷3小時，都是典型例子。這些線路問題意味著數據同步可能會被暫時中斷，從而導致系統在一段時間內數據不一致。

從更廣的視角來看，不論是在正常情況下的傳輸延遲，還是異常狀況下的傳輸中斷，都可能導致系統在某一時間點或時間段內數據不一致，進而引發業務問題。然而，如果不進行數據的冗余備份，又無法保證系統的高可用性。因此，設計存儲高可用系統的挑戰不在于數據的備份本身，而在于如何減少或規避數據不一致對業務的影響。

在分布式系統領域，有一個著名的CAP定理，理論上證明了存儲高可用的復雜性。CAP定理指出，一個分布式系統不可能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三個需求，最多只能滿足其中兩項。這就意味著在架構設計時，需要根據業務需求做出相應的權衡和選擇。

高可用狀態決策

無論是實現計算的高可用還是存儲的高可用，其核心都在于“狀態決策”——系統必須能夠識別當前狀態是正常還是有故障的，并且在檢測到故障時采取措施以保持高可用。然而，如果狀態的決策過程存在誤差或錯誤，那么接下來的所有優化措施都將失去效果和價值。在實際操作中，存在一個根本的挑戰：依賴冗余機制來提高系統可用性的同時，幾乎無法實現絕對準確的狀態決策。接下來，我們將通過分析幾種常用的決策方法來深入探討這一問題。

1.獨裁式

在討論如何確保計算和存儲的高可用性時，我們不得不關注“狀態決策”的重要性——即系統能否正確判斷其當前狀態為正常或異常，并在發現異常時采取相應措施以維持高可用性。問題在于，如果狀態判斷過程本身存在誤差或錯誤，則之后的所有優化和處理措施均會失去其意義。在實踐中，這里面隱藏著一個基本的矛盾：盡管通過增加冗余來提高系統的可用性，但在狀態決策方面卻難以保證其絕對的準確性。為了進一步理解這一挑戰，我們將對幾種主要的決策方式進行詳盡的分析。

圖片

2.協商式

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

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

圖片

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

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

2 臺服務器啟動時都是備機。

2 臺服務器建立連接。

2 臺服務器交換狀態信息。

某 1 臺服務器做出決策，成為主機；另一臺服務器繼續保持備機身份。

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

圖片

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

圖片

為了緩解連接中斷對狀態決策的負面影響，一種方法是增加多條連接，比如使用雙連接或三連接策略。這種做法確實可以減少單一連接故障時對系統狀態判斷的影響，但是，它并不能完全消除問題，而且引入了新的挑戰：當不同連接傳遞的信息出現差異時，系統應該依據哪條連接的信息進行決策呢？實際上，這個問題并沒有一個一刀切的解決方案。選擇任一連接作為決策依據，在某些特定情況下總會遇到困難和挑戰。

圖片

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

3.民主式

民主式決策過程涉及到多個獨立實體通過投票機制共同進行狀態的判斷。這種方式在ZooKeeper集群中選舉領導者時得到了應用。

圖片

通過這種方法，集群中的每個成員都參與到領導者的選舉中，最終根據投票結果決定領導者。

盡管這種決策機制在算法上較為復雜，它自身也帶有一個本質上的問題，即“腦裂”現象。這一術語源自于醫學領域，描述的是左右大腦半球連接斷裂，導致無法互相交換信息，從而分別控制身體做出不同或相互矛盾的行為。在分布式系統中，腦裂指的是原本統一的集群因網絡分割成兩個獨立的子集群，每個子集群都會獨立進行領導者選舉，結果可能出現兩個不同的領導者，類似于一個體系內存在兩個“大腦”。民主式決策指的是多個獨立的個體通過投票的方式來進行狀態決策。例如，ZooKeeper 集。

圖片

在一個理想的分布式系統設置中，通常會有一個節點被選舉為主節點，而其他節點則充當備份角色。假設在一個正常運行的環境里，節點5是主節點，其他節點則作為備份。但當網絡故障導致節點間連接斷開時，可能會出現節點1、2、3形成一個獨立的子集群，而節點4和5形成另一個子集群，這兩個子集群因為連接斷開而無法相互通信。根據民主式決策機制，這兩個子集群可能會分別選舉出自己的主節點，比如節點2和節點5，這樣系統就會同時存在兩個主節點。

這種多主節點的狀態與系統的設計初衷相違背，因為每個主節點都會獨立作出決策，導致系統狀態變得混亂。為了防止這種腦裂現象的發生，采用民主式決策的系統通常實施一項規則：參與投票的節點數必須超過系統總節點數的一半。在上述示例中，由于節點4和節點5組成的子集群總節點數不足系統總數的一半，因此不會進行選舉，從而避免了腦裂問題。然而，這種做法雖然能夠預防腦裂，卻也可能降低系統的整體可用性。例如，如果節點1、2、3的故障并非由腦裂引起，而是真實的故障，這時即便節點4和5仍然健康，系統也無法選舉出新的主節點，相當于整個系統停止服務，盡管有部分節點依然處于正常狀態。