1. 高可用復雜度模型

• 核心思想：遵循“冗余法則”，通過集群化實現高可用，避免單點故障。

a.單機高可用不存在：單機無法冗余，高可用必須依賴集群。

b.復雜度本質：冗余帶來的復雜性，包括狀態同步、故障切換、數據一致性等。

2. 計算高可用

2.1 任務分配

• 核心設計：通過任務分配器（獨立服務器或SDK）將任務分發到多個服務器。
• 復雜度分析：

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

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

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

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

2.2 任務分解

• 核心設計：按業務邏輯拆分服務器角色（如接入層、邏輯層、存儲層）。
• 復雜度分析：

a.任務分解器需記錄任務與服務器的映射關系。

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

• 案例：微信服務拆分（獨立接入服務器+業務集群）。

3. 存儲高可用

3.1 數據復制格式

• 命令復制（如Redis AOF）：

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

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

c.場景：增量復制。

• 文件復制（如MySQL Row格式）：
• 優點：數據一致性強。
• 缺點：流量大。
• 場景：全量復制。
• 混合復制（如Redis RDB+AOF）：
• 折衷方案，平衡一致性與性能。

3.2 數據復制方式

• 同步復制：

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

b.場景：主備架構。

• 異步復制：

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

     b.場景：數據存儲集群。

• 半同步復制（如MySQL半同步）：

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

• 多數復制（如ZooKeeper）：

     a.強一致性+高可用性，但實現復雜。

     b.場景：分布式一致性系統（OceanBase）。

3.3 狀態決策模式

• 獨裁式（如Redis Sentinel）：

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

b.一致性中等，適用于通用業務。

• 協商式（如心跳檢測）：

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

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

• 民主式（如Raft/ZAB算法）：

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

b.場景：余額、庫存等高一致性需求。

4. 案例與模式

• Redis：命令復制（AOF）+文件復制（RDB），異步+半同步。
• MySQL：命令復制（Statement）+數據復制（Row），異步+半同步。
• Hadoop/ZooKeeper：獨裁式決策（依賴ZooKeeper集群）。
• MongoDB：民主式選舉（Raft算法）。

5. 核心結論

• 高可用本質：通過冗余應對故障，集群是必然選擇。
• 設計核心：狀態決策機制（獨裁/協商/民主）決定架構復雜度。
• 數據復制權衡：一致性、性能、故障容忍度需平衡。
• 與高性能對比：高可用更復雜（需冗余管理、狀態決策、異常處理）。

圖片