互聯網高可用架構探討-有解無憂

高可用指標與問題

高可用，英文單詞High Availability，縮寫HA，它是分布式系統架構設計中一個重要的度量，業界通常用多個9來衡量系統的可用性，如下表：

既然有可用率，有一定會存在不可用的情況，系統宕機一般分為有計劃的和無計劃的，有計劃的如日常維護、系統升級等，無計劃的如設備故障、突發斷電等，我們對此作如下分類：

1.設備故障：機房斷電、硬碟損壞、交換機故障，

2.網路故障：網路帶寬擁堵、網路連接中斷，

3.安全問題：利用系統漏洞進行網路攻擊，

4.性能問題：CPU利用率太高、記憶體不足、磁盤IO過載、資料庫慢SQL，

5.升級維護：由于業務變更或技術改進而引起的系統升級，

6.系統問題：分布式系統中存在服務的依賴而導致資料的不一致性，或是核心服務出現例外，

高可用主要手段

負載均衡

負載均衡（Load Balance），它將作業任務分發到多個作業單元上進行運行，它可以提高網路設備的帶寬，提升網路資料處理能力，增強網路的穩定性，可防止機房斷電、網路設備故障等問題，

負載均衡的實作可分為硬體負載與軟體負載，硬體負載由專門的設備完成專門的任務，這種方式性能較高同時成本也高；軟體負載通過軟體代碼實作，此種方式耗費作業系統資源，性能較低，容易出現BUG，也容易引起安全問題，

負載策略一般有輪詢策略、隨機策略、最小連接策略以及最短回應時間策略，

輪詢策略：講用戶請求輪流分配給服務器，這種演算法比較簡單，

隨機策略：隨機選擇一臺服務器來執行任務，

最小連接策略：把請求分配給活動連接數最小的后端服務器，

最短回應時間策略：將請求分配給平均回應時間最短的服務器，

限流

限流就是避免服務過載，隨著流量的提高，無論負載策略如何高效，系統的某個環節總會過載，就如木桶能裝多少水取決于最短的那塊木板，我們是無法保證系統的每個部分都保持同樣的高吞吐量，因此要考慮如何優雅地提供有損服務，

常用的三種限流演算法：計數器演算法、滑動視窗演算法、漏桶演算法、令牌桶演算法，

計數器演算法：使用計數器在一定周期內累加某個介面的訪問次數，當達到限流閾值時，觸發限流策略，進入下一個周期后，重新開始計數，此演算法較為簡單，但會降低服務器的負載能力，

滑動視窗演算法：將時間周期劃分成更小的周期，按小周期來進行計數，根據時間滑動洗掉過期的小周期，這種演算法使得周期劃分得越小服務器的負載能力越高，

漏桶演算法：將請求直接放入漏桶中，如果當前訪問量超出漏桶的限流值，則把后來的請求予以丟棄，這樣可以最大限度地提高服務器的負載能力，

令牌桶演算法：以（時間周期/限流值）的速度向令牌桶里增加令牌，直到裝滿桶的容量，當請求到達時，分配一個令牌讓其通過，如果沒有獲取到令牌則觸發限流機制，

### 異步呼叫

異步呼叫一般有兩種方式：一種是異步回呼，一種是訊息佇列，訊息佇列方式也算是限流的一種手段，可以讓請求一個一個地被處理，避免并發太高而引起的應用無法及時處理，這種方式相對與限流來講，是一種無損的解決方案，但這種方案僅適用于非實時回應的業務，

### 超時重試與冪等設計

很多文章把超時重試與冪等設計分開來討論，但我卻認為它們是相輔相成，密切相關的，在設計超時重試時，一定要考慮冪等設計

超時重試機制：由于服務器宕機、網路延時、服務器執行緒死鎖等原因，導致應用程式無法先限定時間內對服務呼叫方進行回應，因此當發生呼叫超時后，應用程式可根據調度策略進行重試，被呼叫的服務沒有及時回應，可能會存在兩種情況，一是服務內部發生例外，導致執行失敗，沒有回傳任何訊息；一是執行的服務耗時太長，沒有及時回應，但實際已經執行成功，所以針對第二種情況要做冪等設計，

冪等設計：多次相同引數的請求對系統造成的作業都是相同的，常見的冪等方案有：MCVV多版本并發、唯一索引、token機制、悲觀鎖、狀態機冪等、只讀操作等，