1 背景
在大型互聯網場景中，數據庫的高可用性顯得尤為重要，為了保證穩定性，一般需要采用強化的架構模式，以保證數據層能夠提供持續有效的穩定支撐。
2 高可用架構的基本演進過程
2.1 基本的數據庫架構
每個服務對應一個存儲服務實例（基本是數據庫單實例模式），使用 IP+Port 進行連接和調用，這就是大家常見的數據庫直連。
用戶計算服務（svc） 配置IP+端口指向數據庫實例地址，進行訪問和操作。
2.1 Scale Up + Scale Out 模式
互聯網場景下，理論上訪問量和數據量都是不斷膨脹的過程。隨着數據量的增大，數據庫一般要進行縱向（Scale Up）和 橫向（Scale Out） 的拆分，
分庫分表之后可能會將數據拆分到不同的數據庫實例，甚至不同的IDC上，這樣可以 降低數據量，提高執行性能的目的。詳細參考筆者這篇《MySQL全面瓦解28：分庫分表》。
如上圖，庫表拆分之后，使用不同的條件可以路由到不同的IP，這樣來實現業務上的數據隔離，這種條件可以是用戶的角色，業務的類別，
甚至直接對數據取模或者hash，只要確保鏈接到對應的數據庫上即可。這邊舉個例子：（value % 2 == 0） = condition1，（value % 2 == 1） = condition2
。
2.3 主從或主主 + Keepalived 架構
以上只是解決了數據庫大容量的問題，將數據庫的風險降低，性能提升。並沒有實質的解決可用性問題，如果其中一個數據庫實例出現故障，
依然會造成大面積的不可用。
在互聯網架構中，比較常見的一種方式就是，使用 雙主或者主從同步 + keepalived + vip的模式來保證存儲層的好可用性：
如上圖，兩個庫（主主或者主從）使用相同的虛擬IP，當主庫掛掉的時候，虛ip自動轉移到另一個主庫（或者轉移到從庫上，並將從庫切為主庫），這個切換過程對業務應該是透明無感的，也不會造成使用上的異常，以此保證數據庫的高可用性。
2.4 分片分庫模式下的高可用性
可以繼續從2.3演化出分片分庫模式下的高可用架構，如下：
如果數據庫繼續膨脹，流量繼續擴展，還可以繼續擴容，找到最恰當的分片模式。
2.5 其他常見的高可用模式
2.5.1 MHA
MHA（Master High Avaliable） 是一款 MySQL 開源高可用程序，MHA 在監測到主實例無響應后，會自動將同步最靠前（即數據偏移量最少）的 Slave 提升為 Master，然后其他所有的 Slave 重新指向新 Master。架構模式如下：
2.5.2 PXC
PXC（Percona XtraDB Cluster）是一種開源的 MySQL 高可用解決方案。它將 Percona Server、Percona XtraBackup 與 Galera 庫集成在一起，以實現多主復制的 MySQL 集群。
缺點是只支持InnoDB引擎模式，且多主數據同步必然會有性能損耗、同步延遲和數據差異風險。
另外，這種多主同步模式具有典型的木桶效應，系統的吞吐被最差的節點左右。
架構如下：
2.5.3 MGR/InnoDB Cluster
MySQL 5.7 退出了高可用的的模式 MGR（MySQL Group Replication），他具備了多節點數據寫入和強一致性的特點，這一點跟與 PXC 相似。同時采用Group Communication System（GCS協議）進行數據同步來保證消息的原子性。
MGC需要使用到InnoDB Cluster模式，才能實現真正的高可用，高可用架構圖參考下面：
備注：圖片來自官網，就不再畫了。
2.6 高可用模式下的平滑擴容
互聯網大流量場景下我們經常會發現存儲層容易出現瓶頸，這個時候就需要擴容。
相對於停服擴容來說，無損、透明、平滑的數據庫擴容才是我們實際追求的目標。
步驟如下：
- 增加數據庫分片3，進行數據架構初始化和數據同步
- 增加數據庫主從配置，將2個庫的數據庫配置，改為3個庫的數據庫配置，並注意舊庫與新庫的映射關系。
- 服務層 reload（重新加載）配置，完成擴容工作。
- 刪除分片之后的冗余數據，必要的話進行數據庫縮容。
- 服務層根據條件映射到不同的數據庫實例中。
3 總結
數據庫存儲層實現可用性有很多種辦法。除了最基本的 主從/主主 + Keepalived 架構 之外，還有 MHA 、 PXC 、MGR/InnoDB Cluster 等，后面我們一一拆解。
實現高可用，意味着后續的遷移、擴容、業務調整，都應該是可以平滑的，對業務無感的。