1 背景

在大型互聯(lián)網(wǎng)場景中，數(shù)據(jù)庫的高可用性顯得尤為重要，為了保證穩(wěn)定性，一般需要采用強化的架構(gòu)模式，以保證數(shù)據(jù)層能夠提供持續(xù)有效的穩(wěn)定支撐。

2 高可用架構(gòu)的基本演進過程2.1 基本的數(shù)據(jù)庫架構(gòu)

每個服務(wù)對應一個存儲服務(wù)實例（基本是數(shù)據(jù)庫單實例模式），使用 IP+Port 進行連接和調(diào)用，這就是大家常見的數(shù)據(jù)庫直連。用戶計算服務(wù)（svc） 配置IP+端口指向數(shù)據(jù)庫實例地址，進行訪問和操作。

(資料圖片)

2.1 Scale Up + Scale Out 模式

互聯(lián)網(wǎng)場景下，理論上訪問量和數(shù)據(jù)量都是不斷膨脹的過程。隨著數(shù)據(jù)量的增大，數(shù)據(jù)庫一般要進行縱向（Scale Up）和 橫向（Scale Out） 的拆分，分庫分表之后可能會將數(shù)據(jù)拆分到不同的數(shù)據(jù)庫實例，甚至不同的IDC上，這樣可以 降低數(shù)據(jù)量，提高執(zhí)行性能的目的。詳細參考筆者這篇《MySQL全面瓦解28：分庫分表》。

如上圖，庫表拆分之后，使用不同的條件可以路由到不同的IP，這樣來實現(xiàn)業(yè)務(wù)上的數(shù)據(jù)隔離，這種條件可以是用戶的角色，業(yè)務(wù)的類別，甚至直接對數(shù)據(jù)取模或者hash，只要確保鏈接到對應的數(shù)據(jù)庫上即可。這邊舉個例子：（value % 2 == 0） = condition1，（value % 2 == 1） = condition2。

2.3 主從或主主 + Keepalived 架構(gòu)

以上只是解決了數(shù)據(jù)庫大容量的問題，將數(shù)據(jù)庫的風險降低，性能提升。并沒有實質(zhì)的解決可用性問題，如果其中一個數(shù)據(jù)庫實例出現(xiàn)故障，依然會造成大面積的不可用。在互聯(lián)網(wǎng)架構(gòu)中，比較常見的一種方式就是，使用 雙主或者主從同步 + keepalived + vip的模式來保證存儲層的好可用性：如上圖，兩個庫（主主或者主從）使用相同的虛擬IP，當主庫掛掉的時候，虛ip自動轉(zhuǎn)移到另一個主庫（或者轉(zhuǎn)移到從庫上，并將從庫切為主庫），這個切換過程對業(yè)務(wù)應該是透明無感的，也不會造成使用上的異常，以此保證數(shù)據(jù)庫的高可用性。

2.4 分片分庫模式下的高可用性

可以繼續(xù)從2.3演化出分片分庫模式下的高可用架構(gòu)，如下：如果數(shù)據(jù)庫繼續(xù)膨脹，流量繼續(xù)擴展，還可以繼續(xù)擴容，找到最恰當?shù)姆制Ｊ健?/p>2.5 其他常見的高可用模式2.5.1 MHA

MHA（Master High Avaliable） 是一款 MySQL 開源高可用程序，MHA 在監(jiān)測到主實例無響應后，會自動將同步最靠前（即數(shù)據(jù)偏移量最少）的 Slave 提升為 Master，然后其他所有的 Slave 重新指向新 Master。架構(gòu)模式如下：

2.5.2 PXC

PXC（Percona XtraDB Cluster）是一種開源的 MySQL 高可用解決方案。它將 Percona Server、Percona XtraBackup 與 Galera 庫集成在一起，以實現(xiàn)多主復制的 MySQL 集群。缺點是只支持InnoDB引擎模式，且多主數(shù)據(jù)同步必然會有性能損耗、同步延遲和數(shù)據(jù)差異風險。另外，這種多主同步模式具有典型的木桶效應，系統(tǒng)的吞吐被最差的節(jié)點左右。架構(gòu)如下：

2.5.3 MGR/InnoDB Cluster

MySQL 5.7 退出了高可用的的模式 MGR（MySQL Group Replication），他具備了多節(jié)點數(shù)據(jù)寫入和強一致性的特點，這一點跟與 PXC 相似。同時采用Group Communication System（GCS協(xié)議）進行數(shù)據(jù)同步來保證消息的原子性。MGC需要使用到InnoDB Cluster模式，才能實現(xiàn)真正的高可用，高可用架構(gòu)圖參考下面：備注：圖片來自官網(wǎng)，就不再畫了。

2.6 高可用模式下的平滑擴容

互聯(lián)網(wǎng)大流量場景下我們經(jīng)常會發(fā)現(xiàn)存儲層容易出現(xiàn)瓶頸，這個時候就需要擴容。相對于停服擴容來說，無損、透明、平滑的數(shù)據(jù)庫擴容才是我們實際追求的目標。步驟如下：

增加數(shù)據(jù)庫分片3，進行數(shù)據(jù)架構(gòu)初始化和數(shù)據(jù)同步增加數(shù)據(jù)庫主從配置，將2個庫的數(shù)據(jù)庫配置，改為3個庫的數(shù)據(jù)庫配置，并注意舊庫與新庫的映射關(guān)系。服務(wù)層 reload（重新加載）配置，完成擴容工作。刪除分片之后的冗余數(shù)據(jù)，必要的話進行數(shù)據(jù)庫縮容。服務(wù)層根據(jù)條件映射到不同的數(shù)據(jù)庫實例中。3 總結(jié)

數(shù)據(jù)庫存儲層實現(xiàn)可用性有很多種辦法。除了最基本的 主從/主主 + Keepalived 架構(gòu) 之外，還有 MHA 、 PXC 、MGR/InnoDB Cluster 等，后面我們一一拆解。實現(xiàn)高可用，意味著后續(xù)的遷移、擴容、業(yè)務(wù)調(diào)整，都應該是可以平滑的，對業(yè)務(wù)無感的。

關(guān)鍵詞：