如何設計高可用架構

1. 高可用複雜度模型

• 核心思想

  ：遵循 “冗餘法則”，通過集羣化實現高可用，避免單點故障。

• 單機高可用不存在

  ：單機無法冗餘，高可用必須依賴集羣。

• 複雜度本質

  ：冗餘帶來的複雜性，包括狀態同步、故障切換、數據一致性等。

2. 計算高可用

2.1 任務分配

• 核心設計

  ：通過任務分配器（獨立服務器或 SDK）將任務分發到多個服務器。

• 複雜度分析

  ：

• 任務分配器需管理服務器列表（配置文件或 ZooKeeper）。

• 需動態監控服務器狀態，故障時快速切換。

• 算法選擇（輪詢、哈希、權重等）影響負載均衡。

• 關鍵點

  ：高性能架構關注正常處理，高可用架構關注異常容錯。

2.2 任務分解

• 核心設計

  ：按業務邏輯拆分服務器角色（如接入層、邏輯層、存儲層）。

• 複雜度分析

  ：

• 任務分解器需記錄任務與服務器的映射關係。

• 局部故障隔離，避免業務互相影響。

• 案例

  ：微信服務拆分（獨立接入服務器 + 業務集羣）。

3. 存儲高可用

3.1 數據複製格式

• 命令複製

  （如 Redis AOF）：

• 優點：數據量小，實現簡單。

• 缺點：可能不一致（依賴 SQL 函數）。

• 場景：增量複製。

• 文件複製

  （如 MySQL Row 格式）：

• 優點：數據一致性強。

• 缺點：流量大。

• 場景：全量複製。

• 混合複製

  （如 Redis RDB+AOF）：

• 折衷方案，平衡一致性與性能。

3.2 數據複製方式

• 同步複製

  ：

• 強一致性，但寫入性能低（需所有節點確認）。

• 場景：主備架構。

• 異步複製

  ：

• 高性能，容忍節點故障，但可能數據丟失。

• 場景：數據存儲集羣。

• 半同步複製

  （如 MySQL 半同步）：

• 折衷方案，部分節點確認即可。

• 多數複製

  （如 ZooKeeper）：

• 強一致性 + 高可用性，但實現複雜。

• 場景：分佈式一致性系統（OceanBase）。

3.3 狀態決策模式

• 獨裁式

  （如 Redis Sentinel）：

• 決策者單點需高可用（依賴 ZooKeeper/Raft）。

• 一致性中等，適用於通用業務。

• 協商式

  （如心跳檢測）：

• 簡單但易雙主（需雙通道緩解）。

• 一致性弱，適合內部系統。

• 民主式

  （如 Raft/ZAB 算法）：

• 高一致性 + 高可用，但可能腦裂（需 Quorum 控制）。

• 場景：餘額、庫存等高一致性需求。

4. 案例與模式

• Redis

  ：命令複製（AOF）+ 文件複製（RDB），異步 + 半同步。

• MySQL

  ：命令複製（Statement）+ 數據複製（Row），異步 + 半同步。

• Hadoop/ZooKeeper

  ：獨裁式決策（依賴 ZooKeeper 集羣）。

• MongoDB

  ：民主式選舉（Raft 算法）。

5. 核心結論

1. 高可用本質

   ：通過冗餘應對故障，集羣是必然選擇。

2. 設計核心

   ：狀態決策機制（獨裁 / 協商 / 民主）決定架構複雜度。

3. 數據複製權衡

   ：一致性、性能、故障容忍度需平衡。

4. 與高性能對比

   ：高可用更復雜（需冗餘管理、狀態決策、異常處理）。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zsqeEgvXvxP1fAI3JladRA