1. 高可用復雜度模型

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

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

b.復雜度本質(zhì)：冗余帶來的復雜性，包括狀態(tài)同步、故障切換、數(shù)據(jù)一致性等。

2. 計算高可用

2.1 任務分配

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

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

b.需動態(tài)監(jiān)控服務器狀態(tài)，故障時快速切換。

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

• 關(guān)鍵點：高性能架構(gòu)關(guān)注正常處理，高可用架構(gòu)關(guān)注異常容錯。

2.2 任務分解

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

a.任務分解器需記錄任務與服務器的映射關(guān)系。

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

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

3. 存儲高可用

3.1 數(shù)據(jù)復制格式

• 命令復制（如Redis AOF）：

a.優(yōu)點：數(shù)據(jù)量小，實現(xiàn)簡單。

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

c.場景：增量復制。

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

3.2 數(shù)據(jù)復制方式

• 同步復制：

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

b.場景：主備架構(gòu)。

• 異步復制：

     a. 高性能，容忍節(jié)點故障，但可能數(shù)據(jù)丟失。

     b.場景：數(shù)據(jù)存儲集群。

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

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

• 多數(shù)復制（如ZooKeeper）：

     a.強一致性+高可用性，但實現(xiàn)復雜。

     b.場景：分布式一致性系統(tǒng)（OceanBase）。

3.3 狀態(tài)決策模式

• 獨裁式（如Redis Sentinel）：

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

b.一致性中等，適用于通用業(yè)務。

• 協(xié)商式（如心跳檢測）：

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

b.一致性弱，適合內(nèi)部系統(tǒng)。

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

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

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

4. 案例與模式

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

5. 核心結(jié)論

• 高可用本質(zhì)：通過冗余應對故障，集群是必然選擇。
• 設計核心：狀態(tài)決策機制（獨裁/協(xié)商/民主）決定架構(gòu)復雜度。
• 數(shù)據(jù)復制權(quán)衡：一致性、性能、故障容忍度需平衡。
• 與高性能對比：高可用更復雜（需冗余管理、狀態(tài)決策、異常處理）。

圖片