1. 引言

在當今的在線數據處理與交易處理（OLTP）業務場景中，數據庫的高可用性與橫向擴展能力是保障業務連續性與性能的關鍵。MyCat作為一個開源的分布式數據庫中間件，通過實現MySQL協議的代理，提供了數據分片、讀寫分離、故障切換等核心功能，是構建高可用、可擴展數據庫集群的重要組件。本文檔（工作筆記0030）旨在記錄基于MyCat構建高可用集群架構的設計要點，并闡述在模擬在線交易業務場景下進行高可用性驗證的具體實踐。

2. MyCat高可用集群架構設計

一個典型的、面向高可用的MyCat分布式數據庫集群架構通常包含以下幾個層次：

2.1 應用接入層
業務應用程序通過標準MySQL驅動連接MyCat服務。為實現高可用，應用端需配置多個MyCat節點地址，并具備連接失敗重試機制，或使用VIP（虛擬IP）結合Keepalived等工具實現訪問入口的自動漂移。

2.2 MyCat中間件層（核心）
這是架構的核心。高可用設計主要在此層實現：

• 多節點部署：至少部署兩個或以上的MyCat服務節點，避免單點故障。
• 狀態同步：確保所有MyCat節點共享相同的配置文件（如schema.xml, rule.xml, server.xml），可通過分布式配置中心（如ZooKeeper、Nacos）或自動化同步工具管理。
• 故障檢測與切換：借助Keepalived或HAProxy實現。常用方案是MyCat + Keepalived：
• 為多個MyCat節點分配一個虛擬IP（VIP）。

• Keepalived運行在主備MyCat節點上，通過心跳機制監控MyCat進程健康狀態。

• 當主節點MyCat服務失效，Keepalived將VIP自動漂移到健康的備用節點，實現客戶端的無感知切換。

2.3 后端數據庫層
- 數據分片集群：數據被水平拆分到多個MySQL分片（Shard）中，每個分片本身也需要高可用。
- 分片高可用：每個分片采用MySQL主從復制（或基于Group Replication的MGR集群）構成一組。MyCat可配置讀寫分離，寫操作發往主庫，讀操作可分發到從庫。
- 故障感知：MyCat需要能夠檢測后端MySQL節點的狀態。通過heartbeat標簽在配置中定義心跳SQL，MyCat定期執行以判斷節點是否存活。

3. 高可用性驗證方案（模擬OLTP業務場景）

驗證目標是確保在MyCat節點或后端數據庫節點發生故障時，整個數據庫服務對前端OLTP業務的影響最小，數據一致性與業務連續性得到保障。

3.1 驗證環境準備
- 部署架構：兩個MyCat節點（MyCat-01, MyCat-02）+ Keepalived，后端為兩組MySQL主從集群（分片db01group, db02group）。
- 模擬業務：開發簡單的模擬OLTP應用，持續執行典型操作：用戶登錄驗證（SELECT）、下單（INSERT）、支付更新（UPDATE）、查詢訂單（JOIN查詢）等。
- 監控工具：監控MyCat日志、MySQL狀態、網絡連接及業務應用錯誤率。

3.2 驗證場景與步驟

場景一：MyCat中間件節點故障
1. 初始狀態：VIP位于MyCat-01（主），模擬業務穩定運行，所有請求通過MyCat-01處理。
2. 故障注入：手動停止MyCat-01的服務進程。
3. 觀察與驗證：
- Keepalived應檢測到MyCat-01失效，并在數秒內將VIP漂移至MyCat-02。

• 模擬業務可能會出現短暫的連接異常（取決于客戶端連接池設置），但應能在超時重試后自動連接到新的VIP（即MyCat-02），業務逐漸恢復。

• 驗證所有業務操作（增刪改查）在恢復后均能正常執行，且數據一致性無誤（如剛提交的訂單不丟失）。

1. 恢復操作：重啟MyCat-01，它應作為備用節點加入，不影響當前流量。

場景二：后端MySQL主庫故障（某個分片）
1. 初始狀態：業務正常運行，例如訂單表數據分布在兩個分片。
2. 故障注入：停止db01_group的主庫（寫庫）。
3. 觀察與驗證：
- MyCat通過心跳檢測應能快速（取決于心跳間隔）標記該主庫為down。

• 對于路由到該故障分片的寫操作，MyCat應能根據配置的switchType（如切換至備庫寫）進行響應。本例中，若配置了主從切換且從庫可寫（需配合半同步等確保數據安全），寫請求應被路由至提升后的新主庫。

• 模擬業務中涉及該分片的操作，在短暫失敗后應能繼續。需重點關注數據一致性，確保故障前已確認的交易在從庫升級后可見。

• 對于其他健康分片的業務應完全無影響。

1. 恢復操作：修復原主庫，以從庫身份重新同步后加入集群。

場景三：網絡分區或腦裂情況
測試Keepalived的優先級、搶占機制及心跳線配置，確保VIP不會出現腦裂。可斷開主節點網絡，觀察VIP切換及恢復后的搶占行為是否符合預期。

4. 關鍵注意事項與優化點

• 心跳配置：合理設置heartbeat語句與間隔，在故障檢測速度和數據庫壓力間取得平衡。
• 超時與重試：業務客戶端和連接池（如Druid, HikariCP）必須配置合理的連接超時、查詢超時和失敗重試邏輯。
• 數據一致性：在MySQL主從切換時，是強一致性方案（如使用MGR）還是最終一致性方案（異步復制），需根據業務容忍度選擇，并制定相應的數據核對與補償流程。
• 監控告警：建立完善的監控，覆蓋MyCat節點狀態、后端數據庫狀態、VIP歸屬、業務關鍵指標（TPS、響應時間、錯誤率）等。
• 定期演練：高可用架構不應只停留在設計，需定期進行故障演練，確保自動切換流程可靠，團隊應對熟練。

5.

通過構建MyCat（多節點+Keepalived） + MySQL（分片+主從）的集群架構，并針對在線交易業務特點設計全面的故障注入驗證方案，可以建立起一個具備較高可用性的分布式數據庫解決方案。驗證的核心在于證明故障發生時，服務的恢復是自動、快速且數據一致的，從而為核心OLTP業務提供穩定可靠的數據支撐。后續工作應聚焦于性能壓測、更復雜的故障場景模擬（如雙節點同時故障）以及自動化運維工具的集成。