CAP原則指的是在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一、理論
分佈式系統的CAP理論：理論首先把分佈式系統中的三個特性進行了如下歸納：
一致性（C）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
即更新操作成功並返回客戶端後，所有節點在同一時間的數據完全一致，這就是分佈式的一致性。一致性的問題在併發系統中不可避免，對於客戶端來說，一致性指的是併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。
可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
讀寫操作在單臺機器發生故障的時候仍然能夠進行，不需要等待發生故障的機器重啓或者其上面的服務遷移到其他的機器，在分佈式領域來說一般是用多副本來保證
分區容錯性（P）：即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。
分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
二、CAP定理的證明
要滿足分區容錯性的分佈式系統，只能在一致性和可用性兩者中，選擇其中一個。也就是說分佈式系統不可能同時滿足三個特性。這就需要我們在搭建系統時進行取捨了，那麼，怎麼取捨纔是更好的策略呢?
CA without P：
如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。
CP without A： 如果不要求A（可用），相當於每個請求都需要在Server之間強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，如此CP也是可以保證的。很多傳統的數據庫分佈式事務都屬於這種模式。
AP wihtout C： 要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在衆多的NoSQL都屬於此類，如redis,mongdb等。
有用戶向N2發送數據讀取請求，由於數據還沒有進行同步，應用程序沒辦法立即給用戶返回最新的數據DB1，怎麼辦呢？有二種選擇，第一，犧牲數據一致性，響應舊的數據DB0給用戶；第二，犧牲可用性，阻塞等待，直到網絡連接恢復，數據更新操作完成之後，再給用戶響應最新的數據DB1。
三、與可用的決擇
CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。
數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者纔看到這條動態是完全可以接受的。
對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
四、總結
現如今，對於多數大型互聯網應用的場景，主機衆多、部署分散，而且現在的集羣規模越來越大，節點只會越來越多，所以節點故障、網絡故障是常態，因此分區容錯性也就成爲了一個分佈式系統必然要面對的問題。那麼就只能在C和A之間進行取捨。但對於傳統的項目就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於數據一致性不能做出一絲的讓步，C必須保證，出現網絡故障的話，寧可停止服務，可以在A和P之間做取捨。
總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的纔是最好的。