CAP定理與BASE理論 CAP定理 2000 年 7 月，加州大學伯克利分校的 Eric Brewer 教授在 ACM PODC 會議上提出 CAP 猜想。2年後，麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明瞭 CAP。之後，CAP 理論正式成為分散式計算領域 ...
CAP定理與BASE理論
CAP定理
2000 年 7 月，加州大學伯克利分校的 Eric Brewer 教授在 ACM PODC 會議上提出 CAP 猜想。2年後，麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明瞭 CAP。之後，CAP 理論正式成為分散式計算領域的公認定理。
CAP 理論為：一個分散式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
- 一致性(Consistency)： 一致性指 (all nodes see the same data at the same time)，即更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致。
- 可用性(Availability)： 可用性指(Reads and writes always succeed)，即服務一直可用，而且是正常響應時間。
- 分區容錯性(Partition tolerance)： 分區容錯性指(the system continues to operate despite arbitrary message loss or failure of part of the system)，即分散式系統在遇到某節點或網路分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。
CAP 權衡
通過 CAP 理論，我們知道無法同時滿足一致性、可用性和分區容錯性這三個特性，那要捨棄哪個呢？
對於多數大型互聯網應用的場景，主機眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網路故障是常態，而且要保證服務可用性達到 N 個 9，即保證 P 和 A，捨棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成用戶流程的嚴重程度。
對於涉及到錢財這樣不能有一絲讓步的場景，C 必須保證。網路發生故障寧可停止服務，這是保證 CA，捨棄 P。貌似這幾年國內銀行業發生了不下 10 起事故，但影響面不大，報道也不多，廣大群眾知道的少。還有一種是保證 CP，捨棄 A。例如網路故障是只讀不寫。
孰優孰略，沒有定論，只能根據場景定奪，適合的才是最好的。
BASE 理論
eBay 的架構師 Dan Pritchett 源於對大規模分散式系統的實踐總結，在 ACM 上發表文章提出 BASE 理論，BASE 理論是對 CAP 理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP 的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。
- 基本可用(Basically Available)： 基本可用是指分散式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
- 軟狀態(Soft State)： 軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。MySQL Replication 的非同步複製也是一種體現。
最終一致性(Eventual Consistency)： 最終一致性是指系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。
ACID 和 BASE 的區別與聯繫
ACID 是傳統資料庫常用的設計理念，追求強一致性模型。BASE 支持的是大型分散式系統，提出通過犧牲強一致性獲得高可用性。
ACID 和 BASE 代表了兩種截然相反的設計哲學，在分散式系統設計的場景中，系統組件對一致性要求是不同的，因此 ACID 和 BASE 又會結合使用。
