1.what這個理論是什麼
官方文檔定義
分佈式系統的CAP理論：理論首先把分佈式系統中的三個特性進行了如下歸納：
- 一致性（C）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
- 可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容忍性（P）：必然存在網絡故障斷開的風險，這個網絡斷開的專業場景成爲網絡分區。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
詳細
一致性：
- 解釋
CAP理論中的C是指對一個數據多個備份的讀寫一致性。本質：數據請求會等待多個相關數據操作全部完成才返回。（類似銀行的一個存款交易事務，將導致交易流水錶增加一條記錄。同時，必須導致賬戶表餘額發生變化，這兩個操作必須是一個事務中全部完成，保證相關數據的一致性。）
- 例子
在企業級的數據管理方案中，一般必須考慮數據的冗餘存儲問題，而這應該是通過在網絡上的其他獨立物理存儲節點上保留另一份、或多份數據副本來實現的（如附圖所示）。
一種情況是要求節點A、B、C的三份數據完全一致後返回。也就是說，這時從任何一個網絡節點讀取的數據都是一樣的，這就是所謂的強一致性讀。
- 一致性的強弱
從客戶端角度，多進程併發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性，它也分好多種的。
- 注意
弱一致性，最終一致性 你可以認爲和CAP的C一點關係也沒有。因爲CAP的C是更新操作完成後，任何節點看到的數據完全一致, 弱一致性。最終一致性本身和CAP的C一致性是違背的。
可用性：
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用，以下兩個就是“基本可用”的典型例子。
- 響應時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內返回給用戶相應的查詢結果，但由於出現異常（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了1~2秒。
- 功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節日大促購物高峯的時候，由於消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
弱狀態也稱爲軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據聽不的過程存在延時。
所以後文提到的可用性要求不高，是指基本可用。
分區容忍性：
網上版本有很多。
版本1：如果網絡故障時，分區兩邊的處理可以繼續，那就是分區容忍的。（那不就不一致了嗎）
版本2：爲啥分區容忍是必選的，因爲無論如何，它都要發生，無法控制。:（這不是廢話嗎）
我的版本：支持擴展方面是否良好，就是如果系統需求逐步提升，是否可以比較快速簡單的通過擴展節點數來提升系統。那就是說明副本和分片越多，數據分散的程度越來越高，然後上面那兩個的衝突就會更明顯。
2.這個理論的背景
對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地
-
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。 -
數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者纔看到這條動態是完全可以接受的。 -
對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
所以某些情況下一致性保證最終一致性就可以了。當機器擴展到成百上千的規模時，面對可能的錯誤，維持一致性變的非常昂貴（你不得不往更多的機器寫數據，機器數目比你所能容忍的失敗機器多一）。
3.解決問題
eBay的架構師Dan Pritchett源於對大規模分佈式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）。
ACID是傳統數據庫常用的設計理念，追求強一致性模型。BASE支持的是大型分佈式系統，提出通過犧牲強一致性獲得高可用性。
ACID和BASE代表了兩種截然相反的設計哲學，在分佈式系統設計的場景中，系統組件對一致性要求是不同的，因此ACID和BASE又會結合使用。
4.例子
衆所周知，分佈式事務一般採用兩階段提交策略來實現，這是一個非常耗時的複雜過程，會嚴重影響系統效率，在實踐中我們儘量避免使用它。在實踐過程中，如果我們爲了擴展數據容量將數據分佈式存儲，而事務的要求又完全不能降低。那麼，系統的可用性一定會大大降低，在現實中我們一般都採用對這些數據不分散存儲的策略。
當然，我們也可以說，最常使用的關係型數據庫，因爲這個原因，擴展性（分區可容忍性P）受到了限制，這是完全符合CAP理論的。但同時我們應該意識到，這對NoSQL數據庫也是一樣的。如果NoSQL數據庫也要求嚴格的分佈式事務功能，情況並不會比關係型數據庫好多少。只是在NoSQL的設計中，我們往往會弱化甚至去除事務的功能，該問題才表現得不那麼明顯而已。
因此，在擴展性問題上，如果要說關係型數據庫是爲了保證C、A而犧牲P，在儘量避免分佈式事務這一點上來看，應該是正確的。也就是說：關係型數據庫應該具有強大的事務功能，如果分區擴展，可用性就會降低；而NoSQL數據庫乾脆弱化甚至去除了事務功能，因此，分區的可擴展性就大大增加了。
關係型數據庫設計選擇了C（一致性）與A（可用性），NoSQL數據庫設計則不同。noSQL等的分佈式系統現在都可以讓你配置來取決C和A的選擇，因爲他們都不想因爲這個把自己的場景能力所限制了。