CAP 原理

CAP 原理最早出現在 2000 年，由加州大學伯克利分校的 Eric Brewer 教授在 ACM 組織的 Principles of Distributed Computing（PODC）研討會上提出猜想。兩年後，麻省理工學院的 Nancy Lynch 等學者進行了理論證明。

該原理被認為是分佈式系統領域的重要原理之一，深刻影響了分佈式計算與系統設計的發展。

定義

CAP 原理：分佈式系統無法同時確保一致性（Consistency）、可用性（Availability）和分區容忍性（Partition），設計中往往需要弱化對某個特性的需求。

一致性、可用性和分區容忍性的具體含義如下：

• 一致性（Consistency）：任何事務應該都是原子的，所有副本上的狀態都是事務成功提交後的結果，並保持強一致；

• 可用性（Availability）：系統（非失敗節點）能在有限時間內完成對操作請求的應答；

• 分區容忍性（Partition）：系統中的網絡可能發生分區故障（成為多個子網，甚至出現節點上線和下線），即節點之間的通信無法保障。而網絡故障不應該影響到系統正常服務。

CAP 原理認為，分佈式系統最多隻能保證三項特性中的兩項特性。

比較直觀地理解，當網絡可能出現分區時候，系統是無法同時保證一致性和可用性的。要麼，節點收到請求後因為沒有得到其它節點的確認而不應答（犧牲可用性），要麼節點只能應答非一致的結果（犧牲一致性）。

由於大部分時候網絡被認為是可靠的，因此係統可以提供一致可靠的服務；當網絡不可靠時，系統要麼犧牲掉一致性（多數場景下），要麼犧牲掉可用性。

注意：網絡分區是可能存在的，出現分區情況後很可能會導致發生“腦裂”，多個新出現的主節點可能會嘗試關閉其它主節點。

應用場景

既然 CAP 三種特性不可同時得到保障，則設計系統時候必然要弱化對某個特性的支持。

弱化一致性

對結果一致性不敏感的應用，可以允許在新版本上線後過一段時間才最終更新成功，期間不保證一致性。

例如網站靜態頁面內容、實時性較弱的查詢類數據庫等，簡單分佈式同步協議如 Gossip，以及 CouchDB、Cassandra 數據庫等，都為此設計。

弱化可用性

對結果一致性很敏感的應用，例如銀行取款機，當系統故障時候會拒絕服務。MongoDB、Redis、MapReduce 等為此設計。

Paxos、Raft 等共識算法，主要處理這種情況。在 Paxos 類算法中，可能存在著無法提供可用結果的情形，同時允許少數節點離線。

弱化分區容忍性

現實中，網絡分區出現概率較小，但很難完全避免。

兩階段的提交算法，某些關係型數據庫以及 ZooKeeper 主要考慮了這種設計。

實踐中，網絡可以通過雙通道等機制增強可靠性，實現高穩定的網絡通信。