MySQL數據庫教程，Mysql高可用設計入門

高可用概念

首先，我們來看一下 wiki 上對高可用（High Availability）的定義：

High availability (HA) is a characteristic of a system which aims to
ensure an agreed level of operational performance, usually uptime, for
a higher than normal period.

從上面的描述來看，高可用（High Availability）是系統所能提供無故障服務的一種能力。 簡單地說就是避免因服務器宕機而造成的服務不可用。

我們都知道，高可用是每個業務系統設計時，開發人員必須考慮的關鍵點。比如你的系統在發生不可用時，業務表現如何？用戶能否容忍你的不可用時長？

而業界度量高可用能力也有統一標準：判斷宕機時間，并以此計算出每年系統可用時間達到幾個 9，來判斷高可用架構是否健壯。具體如下表所示：

通常來說，系統至少要達到 4 個 9（99.99%），也就是每年宕機時間不超過 52.56 分鐘，否則用戶體驗會非常差，感覺系統不穩定。

99.99% = 1 - 52.56 / (3652460)

不過 4 個 9 宕機 52 分鐘對于生產環境的影響還是比較大，但是 5 個 9 對大部分系統來說要求又太高。所以一些云服務商會提出一個 99.995% 的可用性概念，那么系統一年的不可用時長為：

不可用時長 = (1 - 99.995%)36524*60 = 26.28 (分鐘)

即一年最多的影響服務的時間為 26.28 分鐘。

簡單了解“高可用”有多么重要之后，接下來我們就來看一下，怎么設計高可用架構。

高可用架構設計

系統要達到高可用，一定要做好軟硬件的冗余，消除單點故障（SPOF single point of failure）。

冗余是高可用的基礎，通常認為，系統投入硬件資源越多，冗余也就越多，系統可用性也就越高。

除了做好冗余，系統還要做好故障轉移（Failover）的處理。也就是在最短的時間內發現故障，然后把業務切換到冗余的資源上。

在明確上述高可用設計的基本概念后之后，我們來看一下高可用架構設計的類型：無狀態服務高可用設計、數據庫高可用架構設計。

無狀態服務高可用設計

無狀態的服務（如 Nginx ）高可用設計非常簡單，發現問題直接轉移就行，甚至可以通過負載均衡服務，當發現有問題，直接剔除：

上圖中，當第一臺 Ningx 服務器出現問題，導致服務不可用，Load Balance 負載均衡服務發現后，就可以直接把它剔除。

對于上層用戶來說，他只會在幾秒內的訪問出現問題，之后服務就立刻恢復了。無狀態的服務，高可用設計就是這么簡單。

數據庫高可用架構設計

所以，系統高可用設計，真正的難點、痛點不在于無狀態服務的設計，而在于數據庫的高可用設計，這是因為：

數據持久化在數據庫中，是有狀態的服務；

數據庫的容量比較大，Failover 的時間相對無狀態服務會更多；

一些系統，如金融場景的數據庫，會要求數據完全不能丟失，這又增加了高可用實現的難度。

其實從架構角度看，數據庫高可用本身也是業務高可用，所以我們要從業務全流程的角度出發，思考數據庫的高可用設計。

我在這里提供了三種數據庫的高可用架構設計方法，它們不但適用于 MySQL 數據庫，也適用于其他數據庫。

基于數據層的數據庫高可用架構
基于數據層的數據庫高可用架構，就是基于數據同步技術。當主服務器 Master 發生宕機，則故障轉移到從服務器 Slave。

對于 MySQL 數據庫來說，就是基于前面介紹的復制技術。對于 讀寫分離架構，如果主服務器發生宕機，做如下操作就行了：

可以發現，我們原先的 Slave3 從服務器提升為了新主機，然后建立了新的復制拓撲架構，Slave2、Slave3 都連到新 Master 進行數據同步。

為了在故障轉移后對 Service 服務無感知，所以需要引入 VIP（Virtual IP）虛擬 IP 技術，當發生宕機時，VIP 也需要漂移到新的主服務器。

那么這個架構的真正難點在于：

如何保障數據一致性；如何發現主服務器宕機；故障轉移邏輯的處理；

我們可以通過 MySQL 提供的無損復制技術，來保障“數據一致性”。而“發現主服務器宕機”“處理故障轉移邏輯”要由數據庫高可用套件完成

基于業務層的數據庫高可用架構
第二種“基于業務層的數據庫高可用架構設計”則完全基于業務實現，數據庫只是用于存儲數據。

當一臺數據庫主服務器不可用，業務直接寫另一臺數據庫主服務器就可以了。我們來看一下這個架構：

從上圖可以看到，Service 服務寫入 Master1 主服務器失敗后，不用等待故障轉移程序啟用主從切換，而是直接把數據寫入 Master2 主服務器。

這看似是一種非常簡單、粗暴的高可用架構實現方式，但能符合這樣設計的業務卻并不多，因為該設計前提是狀態可修改。

比如電商中的訂單服務，其基本邏輯就是存儲電商業務中每筆訂單信息，核心邏輯就是往表Orders 中插入數據，即：

INSERT INTO Orders(o_orderkey, ... ) VALUES (...)

這里 o_orderkey 是主鍵。為了實現基于業務層的數據庫高可用，可以在主鍵生成過程中加入額外信息，比如服務器編號，這樣訂單的主鍵設計變為了：

PK = 有序UUID-服務器編號

這樣的話，當寫入服務器編號 1 時失敗了，業務層會把訂單的主鍵修改為服務器編號 2，這樣就實現了業務層的高可用，電商中的這種訂單號生成方式也稱為“跳單”。

而當查詢訂單信息時，由于主鍵中包含了服務器編號，那么業務知道該筆訂單存儲在哪臺服務器，就可以非常快速地路由到指定的服務器。

但這樣設計的前提是整個服務的寫入主鍵是可以進行跳單設計，且查詢全部依賴主鍵進行搜索。

看到這里，你是不是覺得非常符合 NoSQL 的 KV 訪問設計呢？別忘了前面介紹的 Memcached Plugin 哦。

融合的高可用架構設計
剛剛“基于業務層的數據庫高可用架構”中，雖然通過跳單設計，可以實現寫入業務的高可用實現。但這時訂單服務的查詢功能會受到極大影響。在上面的例子中，當發生宕機時，服務器編號為 1 的訂單無法查詢。

所以，我給出一種業務和數據層相結合的高可用設計。這個架構可以解決宕機后，查詢服務受限的問題。其架構圖如下所示：

上圖中，將不同編號的訂單根據不同的數據庫進行存放，比如服務器編號為 1 的訂單存放在數據庫 DB1 中，服務器編號為 2 的訂單存放在數據庫 DB2 中。

此外，這里也用到了 MySQL 復制中的部分復制技術，即左上角的主服務器僅將 DB1 中的數據同步到右上角的服務器。同理，右上角的主服務器僅將 DB2 中的數據同步到左上角的服務器。下面的兩臺從服務器不變，依然從原來的 MySQL 實例中同步數據。

這樣做得好處是：

在常態情況下，上面兩臺 MySQL 數據庫是雙活的，都可以有數據的寫入，業務的性能得到極大提升。

訂單數據是完整的，服務器編號為 1 和 2 的數據都在一個 MySQL 實例上。

更重要的是，這樣當發生宕機時，Service 服務的寫入不受到影響，寫入服務器編號為 1 的訂單通過跳單設計寫入 DB2。

同時，對于訂單讀取也不會受到影響，因為數據都是一個實例上，如：

總結

這一講我們學習了系統設計中最為重要的高可用設計，這是業務系統設計中必須考慮的一點。生產環境沒有高可用，是根本無法完成上線工作的。

這一講我建議你反復閱讀，加深自己對于高可用系統設計的理解。因為這些思想不限于 MySQL數據庫，而是適用所有數據庫以及業務系統。

最后，我來總結下今天的內容：

高可用是系統所能提供無故障服務的一種能力，度量單位是幾個 9；
線上系統高可用目標應不低于 99.995%，否則系統頻繁宕機，用戶體驗不好；
高可用實現基礎是：冗余 + 故障轉移；
無狀態服務的高可用設計較為簡單，直接故障轉移或剔除就行；
數據庫作為有狀態的服務，設計比較復雜（冗余通過復制技術實現，故障轉移需要對應的高可用套件）；

數據庫高可用有三大架構設計，請務必牢記這幾種設計。

ps

了解即可 運維的活