今天我們來聊一下互聯網三高（高并發、高性能、高可用）中的高可用，看完本文相信能解開你關于高可用設計的大部分困惑

前言

高可用（High availability，即 HA）的主要目的是為了保障「業務的連續性」，即在用戶眼里，業務永遠是正常（或者說基本正常）對外提供服務的。高可用主要是針對架構而言，那么要做好高可用，就要首先設計好架構，第一步我們一般會采用分層的思想將一個龐大的 IT 系統拆分成為應用層，中間件，數據存儲層等獨立的層，每一層再拆分成為更細粒度的組件，第二步就是讓每個組件對外提供服務，畢竟每個組件都不是孤立存在的，都需要互相協作，對外提供服務才有意義。

要保證架構的高可用，就要保證架構中所有組件以及其對外暴露服務都要做高可用設計，任何一個組件或其服務沒做高可用，都意味著系統存在風險。

那么這么多組件該怎么做高可用設計呢，其實任何組件要做高可用，都離不開「冗余」和「自動故障轉移」，眾所周知單點是高可用的大敵，所以組件一般是以集群（至少兩臺機器）的形式存在的，這樣只要某臺機器出現問題，集群中的其他機器就可以隨時頂替，這就是「冗余」。簡單計算一下，假設一臺機器的可用性為 90%，則兩臺機器組成的集群可用性為 1-0.1*0.1 = 99%，所以顯然冗余的機器越多，可用性越高。

但光有冗余還不夠，如果機器出現問題，需要人工切換的話也是費時費力，而且容易出錯，所以我們還需要借助第三方工具（即仲裁者）的力量來實現「自動」的故障轉移，以達到實現近實時的故障轉移的目的，近實時的故障轉移才是高可用的主要意義

怎樣的系統可以稱之為高可用呢，業界一般用幾個九來衡量系統的可用性，如下

一般實現兩個 9 很簡單，畢竟每天宕機 14 分鐘已經嚴重影響業務了，這樣的公司遲早歇菜，大廠一般要求 4 個 9，其他要求嚴苛的業務要達到五個九以上，比如如果因為一個電腦的故障導致所有列車停駛，那么就會有數以萬計的人正常生活受到阻礙，這種情況就要求五個九以上

接下來我們就來一起看看架構中的各個組件如何借助「冗余」和「自動故障轉移」來實現高可用。

互聯網架構剖析

目前多數互聯網都會采用微服務架構，常見架構如下:

可以看到架構主要分以下幾層

接入層：主要由 F5 硬件或 LVS 軟件來承載所有的流量入口

反向代理層：Nginx，主要負責根據 url 來分發流量，限流等

網關：主要負責流控，風控，協議轉換等

站點層：主要負責調用會員，促銷等基本服務來裝配 json 等數據并返回給客戶端

基礎 service：其實與站點層都屬于微服務，是平級關系，只不過基礎 service 屬于基礎設施，能被上層的各個業務層 server 調用而已

存儲層：也就是 DB，如 MySQL，Oracle 等，一般由基礎 service 調用返回給站點層

中間件：ZK，ES，Redis，MQ 等，主要起到加速訪問數據等功能，在下文中我們會簡單介紹下各個組件的作用

如前所述，要實現整體架構的高可用，必須要實現每一層組件的高可用，接下來我們就來分別看一下每一層的組件都是如何實現高可用的

接入層&反向代理層

這兩層的高可用都和 keepalived 有關，所以我們結合起來一起看

對外，兩個 LVS 以主備的形式對外提供服務，注意只有 master 在工作（即此時的 VIP 在 master 上生效），另外一個 backup 在 master 宕機之后會接管 master 的工作，那么 backup 怎么知道 master 是否正常呢，答案是通過 keepalived，在主備機器上都裝上 keepalived 軟件，啟動后就會通過心跳檢測彼此的健康狀況，一旦 master 宕機，keepalived 會檢測到，從而 backup 自動轉成 master 對外提供服務，此時 VIP 地址（即圖中的 115.204.94.139）即在 backup 上生效，也就是我們常說的「IP漂移」，通過這樣的方式即解決了 LVS 的高可用。

keepalived 的心跳檢測主要通過發送 ICMP 報文，或者利用 TCP 的端口連接和掃描檢測來檢測的，同樣的，它也可以用來檢測 Nginx 暴露的端口，這樣的話如果某些 Nginx 不正常 Keepalived 也能檢測到并將其從 LVS 能轉發的服務列表中剔出。Nginx也能通過端口檢測服務健康狀態

借用 keepalived 這個第三方工具，同時實現了 LVS 和 Nginx 的高可用，同時在出現故障時也可以將宕機情況發送到對應開發人員的郵箱以讓他們及時收到通知處理，確實很方便，Keepalived 應用廣泛，下文我們會看到它也可以用在 MySQL 上來實現 MySQL 的高可用。

微服務

接下來我們再來看一下「網關」，「站點層」,「基礎服務層」，這三者一般就是我們所說的微服務架構組件，當然這些微服務組件還需要通過一些 RPC 框架如 Dubbo 來支撐才能通信，所以微服務要實現高可用，就意味著 dubbo 這些 RPC 框架也要提供支撐微服務高可用的能力，我們就以 dubbo 為例來看下它是如何實現高可用的

我們先來簡單地看下 dubbo 的基本架構

思路也很簡單，首先是 Provider（服務提供者）向 Registry（注冊中心，如 ZK 或 Nacos 等）注冊服務，然后 Consumer（服務消費者）向注冊中心訂閱和拉取 Provider 服務列表，獲取服務列表后，Consumer 就可以根據其負載均衡策略選擇其中一個 Provider 來向其發出請求，當其中某個 Provider 不可用（下線或者因為 GC 阻塞等）時，會被注冊中心及時監聽（通過心跳機制）到，也會及時推送給 Consumer，這樣 Consumer 就能將其從可用的 Provider 列表中剔除，也就實現了故障的自動轉移，不難看出，注冊中心就起到了類似 keepalived 的作用

中間件

我們再來看下這些中間件如 ZK，Redis 等是如何實現高可用的呢

ZK

上一節微服務中我們提到了注冊中心，那我們就以 ZK（ZooKeeper）為例來看看它的高可用是如何實現的，先來看下它的整體架構圖如下

Zookeeper 中的主要角色如下

Leader: 即領導者，在集群中只有一個 Leader，主要承擔了以下的功能

事務請求的唯一調度和處理者，保證集群事務處理的順序性，所有 Follower 的寫請求都會轉給 Leader 執行，用來保證事務的一致性

集群內部各服務器的調度者：處理好事務請求后，會將數據廣播同步到各個 Follower，統計 Follower 寫入成功的數量，超過半數 Follower 寫入成功，Leader 就會認為寫請求提交成功，通知所有的 Follower commit 這個寫操作，保證事后哪怕是集群崩潰恢復或者重啟，這個寫操作也不會丟失。

Follower:

處理客戶端非事務請求、轉發事務請求給 leader 服務器

參與事物請求 Proposal 的投票（需要半數以上服務器通過才能通知 leader commit 數據; Leader 發起的提案，要求 Follower 投票）

參與 Leader 選舉的投票

畫外音：Zookeeper 3.0 之后新增了一種 Observer 的角色，不過與此處討論的 ZK 高可用關系不是很大，為了簡化問題，所以省略

可以看到由于只有一個 Leader，很顯然，此 Leader 存在單點隱患，那么 ZK 是怎么解決此問題的呢，首先 Follower 與 Leader 會用心跳機制保持連接，如果 Leader 出現問題了（宕機或者因為 FullGC 等原因無法響應），Follower 就無法感知到 Leader 的心跳，就會認為 Leader 出問題了，于是它們就會發起投票選舉，最終在多個 Follower 中選出一個 Leader 來（這里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 協議，它是為 ZK 專門設計的一種支持崩潰恢復的一致性協議），選舉的細節不是本文重點，就不在此詳述了。

除了 ZAB 協議，業界上常用的還有 Paxos，Raft 等協議算法，也可以用在 Leader 選舉上，也就是是在分布式架構中，這些協議算法承擔了“第三者”也就是仲裁者的作用，以承擔故障的自動轉移

Redis

Redis 的高可用需要根據它的部署模式來看看，主要分為「主從模式」和「Cluster 分片模式」兩種

主從模式

先來看一下主從模式，架構如下

主從模式

主從模式即一主多從（一個或者多個從節點），其中主節點主要負責讀和寫，然后會將數據同步到多個從節點上，Client 也可以對多個從節點發起讀請求，這樣可以減輕主節點的壓力，但和 ZK 一樣，由于只有一個主節點，存在單點隱患，所以必須引入第三方仲裁者的機制來判定主節點是否宕機以及在判定主節點宕機后快速選出某個從節點來充當主節點的角色，這個第三方仲裁者在 Redis 中我們一般稱其為「哨兵」（sentinel），當然哨兵進程本身也有可能掛掉，所以為了安全起見，需要部署多個哨兵（即哨兵集群）

哨兵集群

這些哨兵通過 gossip（流言） 協議來接收關于主服務器是否下線的信息，并在判定主節點宕機后使用 Raft 協議來選舉出新的主節點

Cluster 分片集群

主從模式看似完美，但存在以下幾個問題

主節點寫的壓力難以降低：因為只有一個主節點能接收寫請求，如果在高并發的情況下，寫請求如果很高的話可能會把主節點的網卡打滿，造成主節點對外無法服務

主節點的存儲能力受到單機存儲容量的限制：因為不管是主節點還是從節點，存儲的都是全量緩存數據，那么隨著業務量的增長，緩存數據很可能直線上升，直到達到存儲瓶頸

同步風暴：因為數據都是從 master 同步到 slave 的，如果有多個從節點的話，master 節點的壓力會很大

為了解決主從模式的以上問題，分片集群應運而生，所謂分片集群即將數據分片，每一個分片數據由相應的主節點負責讀寫，這樣的話就有多個主節點來分擔寫的壓力，并且每個節點只存儲部分數據，也就解決了單機存儲瓶頸的問題，但需要注意的是每個主節點都存在單點問題，所以需要針對每個主節點做高可用，整體架構如下

原理也很簡單，在 Proxy 收到 client 執行的 redis 的讀寫命令后，首先會對 key 進行計算得出一個值，如果這個值落在相應 master 負責的數值范圍（一般將每個數字稱為槽，Redis 一共有 16384 個槽）之內，那就把這條 redis 命令發給對應的 master 去執行，可以看到每個 master 節點只負責處理一部分的 redis 數據，同時為了避免每個 master 的單點問題，也為其配備了多個從節點以組成集群，當主節點宕機時，集群會通過 Raft 算法來從從節點中選舉出一個主節點

ES

再來看一下 ES 是如何實現高可用的，在 ES 中，數據是以分片（Shard）的形式存在的，如下圖所示，一個節點中索引數據共分為三個分片存儲

但只有一個節點的話，顯然存在和 Redis 的主從架構一樣的單點問題，這個節點掛了，ES 也就掛了，所以顯然需要創建多個節點

一旦創建了多個節點，分片（圖中 P 為主分片，R 為副本分片）的優勢就體現出來了，可以將分片數據分布式存儲到其它節點上，極大提升了數據的水平擴展能力，同時每個節點都能承擔讀寫請求，采用負載均衡的形式避免了單點的讀寫壓力

ES 的寫機制與 Redis 和 MySQL 的主從架構有些差別（后兩者的寫都是直接向 master 節點發起寫請求，而 ES 則不是），所以這里稍微解釋一下 ES 的工作原理

首先說下節點的工作機制，節點（Node）分為主節點（Master Node）和從結點（Slave Node），主節點的主要職責是負責集群層面的相關操作，管理集群變更，如創建或刪除索引，跟蹤哪些節點是集群的一部分，并決定哪些分片分配給相關的節點，主節點也只有一個，一般通過類 Bully 算法來選舉出來，如果主節點不可用了，則其他從節點也可以通過此算法來選舉以實現集群的高可用，任何節點都可以接收讀寫請求以達到負載均衡的目的

再說一下分片的工作原理，分片分為主分片（Primary Shard，即圖中 P0，P1，P2）和副本分片（Replica Shard，即圖中 R0，R1，R2），主分片負責數據的寫操作，所以雖然任何節點可以接收讀寫請求，但如果此節點接收的是寫請求并且沒有寫數據所在的主分片話，此節點會將寫請求調度到主分片所在的節點上，寫入主分片后，主分片再把數據復制到其他節點的副本分片上，以有兩個副本的集群為例，寫操作如下

MQ

ES 利用數據分片來提升高可用和水平擴展能力的思想也應用在其他組件的架構設計上，我們以 MQ 中的 Kafka 為例再來看下數據分片的應用

Kafka 高可用設計，圖片來自《武哥漫談IT》

如上是 Kafka 集群，可以看到每個 Topic 的 Partition 都分布式存儲在其它消息服務器上，這樣一旦某個 Partition 不可用，可以從 follower 中選舉出 leader 繼續服務，不過與 ES 中的數據分片不同的是，follower Partition 屬于冷備，也就是說在正常情況下不會對外服務，只有在 leader 掛掉之后從 follower 中選舉出 leader 后它才能對外提供服務

存儲層

接下來我們再來看一下最后一層，存儲層（DB），這里我們以 MySQL 為例來簡單地討論一下其高可用設計，其實大家如果看完了以上的高可用設計，會發現 MySQL 的高可用也不過如此，思想都是類似的，與 Redis 類似，它也分主從和分片（即我們常說的分庫分表）兩種架構

主從的話與 LVS 類似，一般使用 keepalived 的形式來實現高可用，如下所示

如果 master 宕機了，Keepalived 也會及時發現，于是從庫會升級主庫，并且 VIP 也會“漂移”到原從庫上生效，所以說大家在工程配置的 MySQL 地址一般是 VIP 以保證高可用

數據量大了之后就要分庫分表了，于是就有了多主，就像 Redis 的分片集群一樣，需要針對每個主配備多個從，如下

之前有讀者問分庫分表之后為啥還要做主從，現在我想大家應該都明白了，不是為了解決讀寫性能問題，主要是為了實現高可用

總結

看完了架構層面的高可用設計，相信大家對高可用的核心思想「冗余」和「自動故障轉移」會有更深刻的體會，觀察以上架構中的組件你會發現冗余的主要原因是因為只有一主，為什么不能有多主呢，也不是不可以，但這樣在分布式系統下要保證數據的一致性是非常困難的，尤其是節點多了的話，數據之間的同步更是一大難題，所以多數組件采用一主的形式，然后再在主和多從之間同步，多數組件之所以選擇一主本質上是技術上的 tradeoff

那么做好每個組件的高可用之后是否整個架構就真的可用了呢，非也，這只能說邁出了第一步，在生產上還有很多突發情況會讓我們的系統面臨挑戰，比如

瞬時流量問題：比如我們可能會面臨秒殺帶來的瞬時流量激增導致系統的承載能力被壓垮，這種情況可能影響日常交易等核心鏈路，所以需要做到系統之間的隔離，如單獨為秒殺部署一套獨立的集群

安全問題：比如 DDOS 攻擊，爬蟲頻繁請求甚至刪庫跑路等導致系統拒絕服務

代碼問題：比如代碼 bug 引起內存泄露導致 FullGC 導致系統無法響應等

部署問題：在發布過程中如果貿然中止當前正在運行的服務也是不行的，需要做到優雅停機，平滑發布

第三方問題：比如我們之前的服務依賴第三方系統，第三方可能出問題導致影響我們的核心業務

不可抗力：如機房斷電，所以需要做好容災，異地多活，之前我司業務就由于機房故障導致服務四小時不可用，損失慘重

所以除了做好架構的高可用之外，我們還需要在做好系統隔離，限流，熔斷，風控，降級，對關鍵操作限制操作人權限等措施以保證系統的可用。

這里特別提一下降級，這是為了保證系統可用性采取的常用的措施，簡單舉幾個例子

我們之前對接過一個第三方資金方由于自身原因借款功能出了問題導致無法借款，這種情況為了避免引起用戶恐慌，于是我們在用戶申請第三方借款的時候返回了一個類似「為了提升你的額度，資金方正在系統升級」這樣的文案，避免了客訴

在流媒體領域，當用戶觀看直播出現嚴重卡頓時，很多企業的第一選擇不是查 log 排查問題，而是為用戶自動降碼率。因為比起畫質降低，卡得看不了顯然會讓用戶更痛苦

雙十一零點高峰期，我們把用戶的注冊登錄等非核心功能給停掉了，以保證下單等核心流程的順利

另外我們最好能做到事前防御，在系統出問題前把它扼殺在搖籃里，所以我們需要做單元測試，做全鏈路壓測等來發現問題，還需要針對 CPU，線程數等做好監控，當其達到我們設定的域值時就觸發告警以讓我們及時發現修復問題（我司之前就碰到過一個類似的生產事故復盤大家可以看一下），此外在做好單元測試的前提下，依然有可能因為代碼的潛在 bug 引起線上問題，所以我們需要在關鍵時間（比如雙十一期間）封網（也就是不讓發布代碼）

此外我們還需要在出事后能快速定位問題，快速回滾，這就需要記錄每一次的發布時間，發布人等，這里的發布不僅包括工程的發布，還包括配置中心等的發布

畫外音：上圖是我司的發布記錄，可以看到有代碼變更，回滾等，這樣如果發現有問題的話可以一鍵回滾

最后我們以一張圖來總結一下高可用的常見手段

審核編輯 ：李倩