CAP 定理

在一個分布式系統中，以下三個特性不可能同時完全滿足，最多只能滿足其中兩個：

• C（Consistency，一致性）：
  所有節點在同一時間看到的數據是完全一致的（即更新操作成功并返回后，所有節點都能獲取到最新值）。

• A（Availability，可用性）：
  只要收到用戶的請求，系統就必須在合理時間內返回一個非錯誤的響應（即系統始終處于可用狀態，不會拒絕服務）。

• P（Partition tolerance，分區容錯性）：
  當分布式系統中的網絡出現分區（如節點間通信中斷）時，系統仍能繼續運行（即對網絡故障的容忍能力）。

為什么三者不可兼得？

在分布式系統中，網絡分區（P）是不可避免的（如網絡故障、延遲等）。因此，實際設計中往往需要在?C 和 A 之間做權衡：

• 若優先保證?C + P（CP 系統）：網絡分區時，為了保證數據一致，可能會拒絕部分節點的請求（犧牲可用性）。
• 若優先保證?A + P（AP 系統）：網絡分區時，為了保證所有節點可用，可能會返回不一致的數據（犧牲一致性）。

CP 系統

是指在分布式系統中，通過強一致性協議（如 Raft）、多數派確認和故障檢測，優先保證一致性（C）和分區容錯性（P），犧牲可用性（A）?的設計。適合對數據一致性要求極高的場景（如金融交易、分布式鎖）。

強一致性優先（Consistency First）

所有節點必須達成數據一致后才響應客戶端，不允許 “臟讀” 或 “中間狀態”。例如：分布式鎖服務必須保證同一時間只有一個客戶端獲取鎖。

采用強一致性協議確保數據同步，常見選擇：Paxos/Raft：通過選舉 Leader 節點協調寫入，確保多數節點確認后才提交數據。Raft 更易實現，適合工程落地（如 etcd、Consul 采用）。2PC（兩階段提交）：適合中心化架構，但容錯性較差（協調者故障會導致阻塞）。

集群成員管理：故障檢測：通過心跳（Heartbeat）或定期探活識別失聯節點（如 ZooKeeper 的 Follower 與 Leader 保持心跳）。法定人數（Quorum）：要求超過半數節點可用才能進行寫操作（如 5 節點集群需 3 節點確認，避免分區時兩邊都能寫入）。

數據存儲設計：只讀副本：可部署只讀節點分擔讀壓力，但寫操作必須通過主節點（Leader）。版本控制：通過版本號（如樂觀鎖）避免舊數據覆蓋新數據（如 etcd 的 Revision 機制）。

分區容錯性保障

網絡分區發生時，系統需能識別故障節點，避免數據分裂（腦裂）。例如：通過心跳檢測和超時機制標記故障節點。

可用性妥協

分區期間，可能拒絕部分讀寫請求（返回錯誤或超時），直到分區恢復或集群重新達成一致。

注意事項

• 避免過度犧牲可用性

  • 分區時可允許讀舊數據（弱一致性讀），但寫操作必須嚴格保證一致。
  • 例如：etcd 提供 “線性一致性讀”（通過 Leader 讀取）和 “串行化讀”（可能讀舊數據）兩種模式。

• 網絡分區恢復策略

  • 分區恢復后，需通過日志同步（如 Raft 的日志復制）讓所有節點數據一致。
  • 少數派節點需丟棄本地未提交的修改，以 Leader 數據為準。

• 性能優化

  • 讀寫分離：Leader 處理寫請求，Follower 處理讀請求（需保證讀一致性）。
  • 批量操作：減少網絡交互，提升同步效率

?CP 系統場景

• 分布式鎖（如 Redis RedLock、ZooKeeper 分布式鎖）：必須保證同一時間只有一個持有者。
• 元數據管理（如 HDFS NameNode、Kubernetes ETCD）：集群配置需強一致。
• 金融交易：轉賬操作必須確保雙方賬戶余額同步更新

AP系統

AP 系統（Availability + Partition Tolerance）是分布式系統設計中，優先保證可用性（A）和分區容錯性（P），而在網絡分區時允許一定程度數據不一致的系統。它更注重服務的持續可用，適合對響應速度和服務連續性要求高的場景。

高可用性（Availability）

無論是否發生網絡分區，系統都能在合理時間內響應客戶端請求（不返回錯誤），確保服務不中斷。

無中心節點：避免單點依賴，采用去中心化設計（如 P2P 或多主節點模式），每個節點可獨立處理請求。

本地優先寫入，異步復制：寫請求優先在本地節點執行并立即返回，數據通過后臺線程異步同步到其他節點（如 Cassandra 的 “最終一致性” 復制策略）。

沖突解決機制：分區恢復后，若不同節點存在數據沖突（如同一 key 被修改多次），需通過預設規則解決（如時間戳、版本號、業務邏輯）。

冗余設計：數據多副本存儲，即使部分節點故障，仍能從其他副本讀取數據。

讀寫策略：讀本地：優先讀取本地節點數據，保證低延遲。NWR 模型：可配置 “寫 N 個節點，讀 W 個節點”，在一致性和可用性間靈活調整（如 Riak）。

故障檢測與自動恢復：通過 Gossip 協議傳播節點狀態，分區恢復后自動觸發數據合并（如 Redis Cluster 的槽位遷移）。

分區容錯性（P）

網絡分區（節點通信中斷）時，各分區仍能獨立處理請求，不會因部分節點故障導致整個系統不可用。

最終一致性

犧牲強一致性，但保證 “最終一致性”—— 分區恢復后，通過數據同步機制，最終所有節點的數據會達成一致。

AP系統場景

• 社交網絡：用戶動態、評論等對實時一致性要求低，但需高可用。
• 內容分發：視頻、圖片等靜態資源，允許短期數據不一致。
• 物聯網（IoT）：設備狀態上報，優先保證設備能持續寫入數據。
• 緩存系統：如 Redis Cluster，優先保證緩存服務可用，短暫不一致可接受。

?????