前言：互聯網業務對 7×24 高可用的剛性需求
傳統行業 9×9×6 或 9×12×5 服務窗口，互聯網電商/遊戲要求全天候在線。資料庫架構必須在設計初期植入容災基因，本文從業務宏觀視角剖析 MySQL 高可用架構演進。
核心架構模式
1. 讀多寫少：經典一主多從 (M-S)
- Master 承擔寫入 + 核心強一致性讀；Slave 承擔海量讀請求。
- 切換邏輯：Master 掛 → 升級 Slave 為新 Master → 掛載其餘 Slave → VIP/域名切換。
- 適用：電商商品瀏覽、訂單查詢、內容型應用。
2. 讀多寫少 + 從庫過多：雙主備用 + 從庫分組 (M-M-S)
- 單 Master 掛載 10+ Slave 成單點壓力大、故障波及面廣。
- 引入 Standby Master (M2) 分攤部分 Slave，故障域隔離。
- 切換：M1 故障 → M2 升主 → M1 下掛 Slave 重新掛載 M2。
- 適用：遊戲高併發讀、社交 Feed 流。
3. 寫多讀少：雙主互備 (M-M)
- 讀寫集中單主，備庫純備援不分攤讀壓。
- 跨 IDC 部署，異地容災核心需求。
- 切換：單向流量切換，極簡。
- 適用：寫入密集型 (日志收集、計費、物聯網數據入庫)。
4. 讀寫均衡：雙主分流 (M-M Read/Write Split)
- M1 承擔寫入 + 部分讀；M2 承擔大部分讀 + 備援寫入。
- 跨 IDC，資料近似實時同步。
- 切換：讀流量切 M2、寫流量切 M2。
5. 同城雙活 / 兩地三中心：極致可用性
- 兩地資料中心距離 < 50km，光纖延遲 < 2ms，支援同步/半同步複寫。
- 應用層雙活：流量同時寫入兩地，資料庫層雙主同步或 Galera 叢集。
- 單點故障、單機房故障、單城市故障全覆蓋。
- 成本高、架構複雜，核心交易系統才投入。
關鍵技術支撐
| 技術 | 作用 |
|---|
| GTID 複寫 | 精確定位主從位點，簡化故障切換 |
| 半同步複寫 (rpl_semi_sync) | 至少一從庫收到 Binlog 才回應 Commit，兼顧效能與零丟失 |
| MHA / Orchestrator | 自動故障偵測、主從切換、拓撲管理 |
| ProxySQL / MaxScale | 讀寫分離、查詢路由、熔斷降級 |
| Galera / Group Replication | 多主同步叢集，強一致、自動成員管理 |
| Binlog 歸檔 + PITR | 邏輯備份補充，防人為誤操作 |
架構選型決策樹
- 業務讀寫比？→ 讀多寫少 / 寫多讀少 / 均衡
- 容忍 RPO/RTO？→ 秒級/分級/小時級
- 預算與運維能力？→ 單主從 / 雙主 / 同城雙活
- 合規要求？→ 異地備份 / 同城雙活 / 兩地三中心
總結
沒有銀彈架構，只有匹配業務階段的架構。從單主從起步，隨業務增長演進至雙主備用、同城雙活，核心始終是：資料不丟、服務不停、切換快、運維可控。
