| 方案 | 架構 | 成本 | 優點 | 缺點 | 速度(相對單機) | 適用場景 |
|---|---|---|---|---|---|---|
| 1. MySQL Cluster (NDB) | 共享無架構，數據分片內存 | 極高（大內存、萬兆網、SCI 卡） | 真正冗余、高擴展、易維護 | 隨數據增長內存成本指數級、寫入延遲高 | ~0.1x | 極高可用、強一致、內存級業務 |
| 2. MySQL/GFS-GNBD/HA (Active/Passive) | 共享存儲 + 單活 | 高（共享存儲、多備機） | 高可靠、讀擴展好 | 無寫擴展、無負載均衡、故障切換慢 | ~2x (讀) | 讀密集、高可靠、可接受寫單點 |
| 3. MySQL/DRBD/HA (Active/Passive) | DRBD 複制塊設備 + 單活 | 中高 | 高可靠、成本可控 | 無寫擴展、無負載均衡、切換需秒級 | ~1x | 讀密集、預算有限、需高可靠 |
| 4. Master-Write / Multi-Slave-Read (Active/Active) | 一主多從，讀寫分離 | 中（1主 N從） | 讀負載均衡、讀高可用、擴展性好 | 寫單點、寫無高可用、主掛需人工/腳本切換 | ~1x (寫), Nx (讀) | 讀多寫少、核心業務可容忍寫故障 |
| 5. Standalone (功能分庫) | 多獨立實例，業務隔離 | 低 | 簡單、隔離性好 | 無 HA、無負載均衡、運維碎片化 | 1x | 非核心、測試、微服務各自為戰 |
MySQL 官方建議：DRBD（數據同步）+ Replication（讀擴展）+ Linux Heartbeat（故障切換），實現 Auto-failover，大幅縮短 RTO。
針對方案 4（一主多從）的讀寫分離流量分發，引入硬件負載均衡器解決軟件層單點與性能瓶頸。
+-----------------+
| Barracuda LB440 (HA Pair) |
| VIP: 192.168.1.100 |
+----------+------------------+
|
+------------+------------+
| |
+-----v-----+ +-----v-----+
| MySQL Master (Write) | MySQL Slave 1 (Read) |
| 192.168.1.10:3306 | 192.168.1.11:3306 |
+-----------+ +-----+------+
| |
+-----v-----+ +-----v-----+
| MySQL Slave 2 (Read) | MySQL Slave N (Read) |
| 192.168.1.12:3306 | 192.168.1.13:3306 |
+-----------------------+----------------------+SELECT 1、檢查 Seconds_Behind_Master < 阈值，故障節點自動下線。| 方案 | 組件 | 優點 | 缺點 | 建議場景 |
|---|---|---|---|---|
| ProxySQL | 高性能 MySQL 代理 | 查詢路由/重寫/緩存/熔斷/集群化、開源免費 | 需深度運維、Lua 腳本複雜、單點需自建 HA | 中大型互聯網、有 DBA 團隊 |
| HAProxy + keepalived | 四層代理 + VIP | 穩定、成熟、社區活躍 | 無 MySQL 協議感知、健康檢查弱、無查詢路由 | 傳統企業、預算極低 |
| MaxScale | MariaDB 官方代理 | 讀寫分離、過濾器、Binlog 服務器 | 企業版收費、社區版功能受限 | MariaDB 生態用戶 |
MySQL 架構演進無銀彈，**方案選型 = 業務可用性等級 × 預算 × 團隊運維能力**。
- 核心交易、零容忍停機 → **MySQL Cluster / Galera Cluster + 硬件 LB (Barracuda/F5)**。
- 讀多寫少、成本敏感 → **一主多從 + ProxySQL/HAProxy + Keepalived + MHA/Orchestrator**。
- 非核心、微服務獨立 → **功能分庫 + 輕量代理**。
Barracuda LB440 以**專用硬件性能、HA 快速切換、SSL 卸載、內置安全**解決了方案 4 的讀流量分發單點與性能瓶頸，是「買而不建」的優質選擇。
