CAP定理與權衡實踐

CAP定理

• 一致性（Consistency）

  • 強一致性：所有讀寫操作均基于最新數據（如銀行轉賬）。
  • 最終一致性：數據副本經過一段時間后達到一致（如社交媒體的點贊數）。
  • 技術實現：兩階段提交（2PC）、Paxos/Raft共識算法。

• 可用性（Availability）

  • 響應要求：系統必須在有限時間內返回結果（即使數據可能過時）。
  • 設計原則：無單點故障、快速失敗（Fail Fast）、優雅降級。

• 分區容錯性（Partition Tolerance）

  • 必然性：分布式系統必須容忍網絡分區（因網絡不可靠是客觀存在）。
  • 設計策略：冗余部署、多副本同步、自動故障轉移。

CAP的權衡實踐

• CP系統（一致性+分區容錯）

  • 特點：在分區發生時，優先保證一致性，犧牲可用性（拒絕部分請求）。
  • 典型系統：ZooKeeper選舉Leader期間服務不可寫，保證數據一致性；Etcd基于Raft協議，分區時少數派節點不可用。
  • 適用場景：金融交易系統（如支付結算），分布式鎖服務（如避免重復扣款）。

• AP系統（可用性+分區容錯）

  • 特點：分區發生時，允許返回舊數據，優先保證服務可用性。
  • 典型系統：Eureka服務注冊中心在分區時允許節點獨立運行。
  • 適用場景：社交媒體（如點贊、評論功能）；實時性要求不高的數據展示（如商品詳情頁緩存）。

• CA系統（理論存在，實際不成立）

  • 矛盾點：分布式系統必須面對網絡分區，無法完全放棄P。
  • 誤解案例：單機數據庫（如MySQL主從架構）看似CA，但本質非分布式系統。

CAP的實際工程權衡

• 強一致性優先（CP） ：如訂單支付、庫存扣減，使用分布式事務（如Seata的AT模式）或同步復制。

• 高可用優先（AP） ：如用戶會話管理、新聞Feed流，使用最終一致性（如Redis跨機房異步復制）。

• 混合策略——分而治之：不同子系統采用不同CAP策略。

  • 訂單服務（CP） ：強一致性保證支付原子性。
  • 商品服務（AP） ：允許緩存短暫不一致，優先展示頁面。

• BASE（Basically Available, Soft state, Eventually consistent）

  • 基本可用：允許降級響應（如返回默認庫存值）。
  • 軟狀態：中間狀態允許不同步（如訂單“處理中”狀態）。
  • 最終一致：通過異步補償達成一致（如Saga模式）。

網絡分區的應對策略

• 檢測與響應

  • 心跳檢測：通過ZooKeeper或Consul監控節點健康狀態。
  • 多數派仲裁：只有多數節點存活時允許寫入（如Paxos要求多數派同意）。
  • Fencing機制：舊Leader被隔離后禁止寫操作（如ZooKeeper的ZXID校驗）。

• 恢復后的數據調和

  • Last Write Wins（LWW） ：以最新時間戳為準（簡單但可能丟數據）。
  • 向量時鐘（Vector Clock） ：通過邏輯時間戳合并沖突（如DynamoDB）。
  • 人工干預：記錄沖突日志供運維介入（如金融對賬系統）。

共識算法

Paxos算法

• 角色：

  • Proposer（提議者） ：發起提案（如提議某個值）。
  • Acceptor（接受者） ：接受或拒絕提案。
  • Learner（學習者） ：學習最終達成一致的值。

• 流程：

  • Prepare階段：Proposer發送提案編號（n）給Acceptors。
  • Promise階段：Acceptor承諾不再接受編號小于n的提案，并返回已接受的最高編號提案。
  • Accept階段：Proposer選擇多數派Acceptors接受的最高值，發送Accept請求。
  • Learn階段：一旦提案被多數派接受，Learner廣播最終值。

Raft算法

• 設計目標：簡化Paxos的理解與實現，明確角色劃分。

• 角色：

  • Leader（領導者） ：唯一處理客戶端請求的節點，負責日志復制。
  • Follower（跟隨者） ：被動接收Leader的日志條目。
  • Candidate（候選者） ：在Leader失效時發起選舉。

• Leader選舉：

  • Follower在超時（Election Timeout）后成為Candidate，發起選舉。
  • 獲得多數派投票的Candidate成為新Leader。

• 日志復制：

  • Leader接收客戶端請求，將日志條目廣播給Followers。
  • 多數派確認后提交日志，應用到狀態機。

• 安全性保證：

  • 選舉限制：只有擁有最新日志的Candidate才能成為Leader。
  • 日志匹配：強制Followers的日志與Leader一致。

ZAB協議（ZooKeeper Atomic Broadcast）

• 設計目標：為ZooKeeper設計的高吞吐量原子廣播協議。
• Leader選舉（Fast Leader Election）：節點通過交換epoch（時代編號）快速選出最新數據的Leader。
• 原子廣播：Leader為每個事務生成全局有序的ZXID（事務ID）；Followers按順序提交事務，確保所有節點狀態一致。

分布式事務解決方案

兩階段提交（2PC，Two-Phase Commit）

• 準備階段（Prepare Phase） ：

  • 協調者（Coordinator） 向所有參與者（Participant） 發送事務請求，詢問是否可以提交。
  • 參與者執行事務操作（但不提交），鎖定資源，并返回“同意”（Yes）或“拒絕”（No）。

• 提交階段（Commit Phase） ：

  • 若所有參與者返回“Yes”，協調者發送提交命令，參與者提交事務并釋放鎖。
  • 若有任一參與者返回“No”，協調者發送回滾命令，參與者撤銷操作。

三階段提交（3PC，Three-Phase Commit）

• CanCommit階段：協調者詢問參與者是否“可能提交”（不鎖定資源）。
• PreCommit階段：若所有參與者同意，協調者發送預提交請求，參與者鎖定資源并準備提交。
• DoCommit階段：協調者發送最終提交或回滾命令。

補償事務（Saga模式）

• 編排式（Choreography） ：各服務通過事件（如消息隊列）自主協調，無中心協調者。
• 編排式缺點：邏輯分散，難維護；需處理事件丟失和重復消費。
• 編排式工具：Kafka、RabbitMQ。
• 編排式（Orchestration） ：協調者服務集中管理事務流程，調用各服務接口（Cadence、AWS Step Functions）定義Saga步驟。

TCC（Try-Confirm-Cancel）

• Try階段：預留資源（如凍結庫存、預扣款）。
• Confirm階段：確認操作，提交資源（如實際扣款、減少庫存）。
• Cancel階段：回滾Try階段的預留（如解凍庫存、釋放預扣款）。
• 冪等性：每個階段需支持重試（如通過唯一事務ID）。
• 空回滾：Try未執行時收到Cancel，需忽略操作。
• 懸掛控制：Confirm/Cancel可能先于Try到達，需記錄狀態。

基于消息隊列的最終一致性

• 本地事務 + 消息表：業務操作與消息寫入本地數據庫（原子性保證）；后臺任務輪詢消息表，將消息投遞到MQ。
• 消息消費：下游服務消費消息并執行業務，成功后確認消息；失敗時重試或進入死信隊列人工處理。
• 事務消息：發送半消息到MQ → 執行本地事務 → 提交/回滾消息；MQ定期檢查未確認消息，回調生產者確認狀態。

分布式ID生成方案

UUID

• 原理：基于時間、MAC地址或隨機數生成128位字符串（如550e8400-e29b-41d4-a716-446655440000）
• 無序性：作為數據庫主鍵會導致B+樹頻繁分裂，降低寫入性能。
• 存儲浪費：128位過長（占用36字符），可讀性差。
• 適用場景：日志追蹤、臨時標識等無需有序性的場景。

數據庫自增ID

• 原理：通過數據庫自增字段（如MySQL AUTO_INCREMENT）生成唯一ID。
• 分庫分表：通過步長區分不同分片（如實例1生成1,3,5…，實例2生成2,4,6…）。
• 批量預取：每次從數據庫獲取一批ID（如1000個）緩存在本地，減少數據庫訪問。
• 適用場景：中小規模系統，非高并發場景。

Snowflake算法

• 原理：64位ID = 時間戳（41位） + 機器ID（10位） + 序列號（12位）
• 生成流程：同一毫秒內，通過序列號遞增生成多個ID（最多4096個/ms）；時間戳回撥時，通過等待或拋出異常處理。
• 機器ID分配：需通過ZK/DB/配置中心保證機器ID唯一。

Redis生成ID

• 原理：利用Redis的原子操作INCR或INCRBY生成遞增ID。
• 集群分片：不同業務使用不同Key（如order:id、user:id）。
• 批量預取：每次獲取一段ID范圍（如1~1000），減少Redis交互。
• 適用場景：需要遞增ID且已部署Redis集群的系統。

分布式ID方案對比

方案	唯一性	有序性	性能	依賴	適用場景
UUID	極高	無	極高	無	日志追蹤、臨時標識
數據庫自增	高	嚴格遞增	低	強（數據庫）	中小規模系統
Snowflake	高	時間有序	極高	弱（時鐘同步）	高并發、需有序的大規模系統
Redis生成	高	遞增	高	強（Redis）	已有Redis集群的系統
號段模式	高	嚴格遞增	高	弱（數據庫）	需連續ID的中大規模系統