高可用性的前提是：保證服務系統能夠持續工作，實現高可用性一般有兩種手段： 一種是透過第三方軟體／元件保證系統的可用性；另一種是軟體／元件自身己具備高可用的技術實現。

高可用性確實是分散式系統一項重要的指標，跟資料一致性，分割槽容錯性組成了分散式系統的CAP原則，本文只針對高可用性分析如下：

高可用性：High Availability，保證分散式系統在較長的時間內能正常響應，持續可用，業界常用幾個9的說法來說明高可用性，比如說5個9，就是99.999%，全年只能停機幾十分鐘而已！

毫無疑問，單點的系統是無論如何也不可能實現高可用的，因為受到單點故障，服務釋出，網路延遲等原因，客戶端總會接收不到響應，即服務不可用！

比如資料庫常用的叢集手段有：

1，主從複製，讀寫分離：不能做到高可用，如果主機掛了，整個系統的寫功能就不能用了！

2，分庫分表：不能做到高可用，分庫分表是把所有的資料分佈到了很多的分庫中，其中一個分庫掛了，這部分資料就沒了！

3，雙主互備：可以做到高可用，雙主機資料一致，能動態切換主庫，其中一臺壞了，另一臺可提供使用！

雙主互備得到的叢集雖然實現了高可用，由於雙機資料一致，限制了整個叢集的容量！

分散式服務的高可用更加的複雜，因為分散式系統對外是一個整體，換句話說分散式的高可用需要保證分散式系統中包括應用系統，資料庫，快取系統，訊息元件等所有服務的高可用性！

高可用性的解決方法一般來說比較單一，包括資料冗餘，故障熔斷，服務轉移！

資料冗餘保證在任何時候最新的資料都不丟失，多份資料冗餘也為後期的資料還原提供基礎！

故障熔斷，服務轉移保證單個服務不可用時，使用熔斷防止服務不可用影響別的服務，並使用最新的健康服務以替換！

針對應用系統的單點，一定要壓測出最大的容納能力，同時可以使用負載均衡的方式搭建叢集，服務還應該設計為冪等的，防止資料一致性問題！

高可用性解決方案貌似除了堆機器，沒有更好的辦法，不知道大家有什麼手段，寫出來讓大家學習學習！

1 一個公式

高可用方案千變萬化，但是萬變不離其宗。高可用核心公式如下：

高可用 = 冗餘 + 自動故障轉移 + 降級 + 隔離

我們來思考一個問題，怎樣保證一個工程系統的穩定性？有以下兩種做法：

思路1：考慮到所有意外情況，針對每一個意外的異常情況分別處理。

思路2：接受無法預料到所有意外情況的現實，把兜底方案做好，保證即使出現極端情況，系統也不會崩潰。

我們仔細分析思路1，會發現這其實是一個悖論。

所謂意外情況，就是意料之外的情況，無法預料的情況。如果被考慮到了，那麼也就不能稱之為意外情況了。

塔勒布在經典著作《反脆弱》一直想告訴我們的是，黑天鵝事件是無法預測的，極端的意外情況是無法預測的，尾部風險雖然機率微小，但是破壞力卻極大。

我們能做的就是保護好系統，讓系統在極端情況下不要崩潰。

冗餘又分冷備份和熱備份。我們以資料庫為例。

冷備份是指定時將資料庫的資料備份，歸檔，供後續查閱和校對。

熱備份最常見的就是主從模式。主從資料實時同步，一來可以做讀寫分離，提高訪問效率，二來當主庫宕機，從庫可以頂上去繼續提供服務。

繼續以資料庫為例。當主庫宕機，肯定不能人工去切換成備庫，這樣對故障處理的響應時間肯定會增加，而應該自動切換為備庫。

這樣的例子還有很多，比如當nginx掛時keepalived能夠探測到會自動的進行故障轉移，Redis中的哨兵機制。

所謂降級策略，就是當系統遇到無法承受的壓力時，選擇暫時關閉一些非關鍵的功能，或者延時提供一些功能，把此刻所有的資源都提供給現在最關鍵的服務。

在秒殺場景中，下訂單就是最核心最關鍵的功能。當系統壓力將要到達臨界值時，可以暫時先關閉一些非核心功能如查詢功能。

還有一種降級策略，當系統依賴的下游服務出現錯誤，甚至下游服務已經完全不可用了，那麼此時就不能再呼叫這個下游服務了，否則可能導致雪崩。所以直接返回兜底方案，把下游服務直接降級。

物理隔離：兩個應用分別部署在不同的物理機、不同的機房，資源不會互相影響。

執行緒隔離：不同的請求進行分類，交給不同的執行緒池處理，當一類請求出現高耗時和異常，不影響另一類請求的訪問。

備前則後寡，備後則前寡，備左則右寡，備右則左寡，無所不備，則無所不寡。

力量集中在前，後面就空虛。力量集中在後，前面就空虛。力量集中在左，右面就空虛。力量集中在右，左面就空虛。力量分散在前後左右，那麼前後左右就都空虛。

不確定性分散在前後左右，無法預測。

我們不可能將精力分散在前後左右，但至少可以做好一點：保護好系統。

提高系統可用性最簡單的方法就是“加資源”，4C16G 變 8C32G，但是單體機器的資源畢竟有限，而分散式架構的實質，就是讓多臺機器，甚至是海量機器，合作完成一件事情，提高分散式系統的高可用性，可以從以下幾個方面入手。

在分散式架構中單點意味著風險，一定要儘可能地避免單點故障。

負載均衡可以將請求平均地分配給每一臺伺服器，能夠利用多臺機器的資源，更重要的是，當一臺機器發生故障時，不會影響整個系統的使用；這裡要注意要有一定的冗餘，否則可能會導致一臺機器發生故障，剩下的機器無法抗住壓力導致整個系統的崩潰。

上面也說到，叢集環境下一臺伺服器的異常可能會導致整個系統的崩潰，如果能做到彈性擴容鎖容的話，可以大大提高系統的高可用性；當流量增大的時候，增加幾臺伺服器，當流量降下去，減少幾臺伺服器，這一切都是自動完成的。

儘管有測試人員進行測試，但是依然很難覆蓋所有的使用場景，為了避免出現生產環境大範圍的故障或BUG，所以我們一般會採用灰度釋出，也就是讓一部分使用者可以用到這個新功能，驗證無誤後再擴大應用範圍，直到所有的應用都更新完成，如果在驗證的過程中發現問題，那麼就快速回滾。

橫向伸縮，是將相同的應用部署多套，或者相同的資料儲存多份，而垂直切分，是將一個大系統切分成多個小系統、微服務，資料分庫分表，以前是一掛全部都掛，現在出現故障，可能只是部分業務功能不可用。

如果系統的使用者量固定，併發量可估且平穩，那麼一切都可控，但是應用如果是面向網際網路使用者的，那麼對於未知的徒增流量就要有應對策略，常用的做法有限流、熔斷、降級；限流只讓部分流量進入系統，拒絕掉多餘的流量保護系統；熔斷就是保險絲，在發生短路的時候自動跳閘，保護系統；降級是當流量徒增，可以限制不重要的系統或服務的訪問量，保護主要業務。

分散式系統發生故障不可怕，錯誤定位困難和恢復時間長才可怕，所以分散式系統需要有完善的監控系統，在系統可能發生故障的時候，及時預警，在真正發生故障後，準確定位故障，方便運維人員修復。

高可用最樸素的意思就是，服務部署在多臺機器上組成一個服務叢集，這樣其中某臺出現了問題，服務還可以繼續對外提供服務，CAP是分散式高可用的必懂定理，如果服務是有狀態的服務，需要考慮服務狀態的一致性。不過現在都是強調強一致性。