CAP原則
CAP原則又稱CAP定理，指的是在分佈式系統的設計中，沒有一種設計可以同時滿足 Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）3個特性，這三者不可得兼。
It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
分佈式系統的CAP理論
理論首先把分佈式系統中的三個特性進行了如下歸納：
- 一致性（C）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
- 可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
- 分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
爲什麼會是這樣
我們來看一個簡單的問題, 一個DB服務 搭建在兩個機房（北京,廣州)，兩個DB實例同時提供寫入和讀取
image
-
假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功
在沒有出現網絡故障的時候，滿足CA原則，C 即我的任何一個寫入，更新操作成功並返回客戶端完成後,分佈式的所有節點在同一時間的數據完全一致， A 即我的讀寫操作都能夠成功，但是當出現網絡故障時，我不能同時保證CA，即P條件無法滿足 -
假設DB的更新操作是隻寫本地機房成功就返回，通過binlog/oplog回放方式同步至側邊機房
這種操作保證了在出現網絡故障時,雙邊機房都是可以提供服務的，且讀寫操作都能成功，意味着他滿足了AP ，但是它不滿足C，因爲更新操作返回成功後，雙邊機房的DB看到的數據會存在短暫不一致，且在網絡故障時，不一致的時間差會很大（僅能保證最終一致性） -
假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功且網絡故障時提供降級服務
降級服務，如停止寫入，只提供讀取功能，這樣能保證數據是一致的，且網絡故障時能提供服務，滿足CP原則，但是他無法滿足可用性原則
一致性與可用性的的選擇與權衡
CAP理論就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而由於當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。
通過上面的例子，我們得知，我們永遠無法同時得到CAP這3個特性，那麼我們怎麼來權衡選擇呢？選擇的關鍵點取決於業務場景
對於大多數互聯網應用來說（如網易門戶），因爲機器數量龐大，部署節點分散，網絡故障是常態，可用性是必須需要保證的，所以只有設置一致性來保證服務的AP，通常常見的高可用服務吹噓5個9 6個9服務SLA穩定性就本都是放棄C選擇AP
對於需要確保強一致性的場景，如銀行，通常會權衡CA和CP模型，CA模型網絡故障時完全不可用，CP模型具備部分可用性，實際的選擇需要通過業務場景來權衡（並不是所有情況CP都好於CA，只能查看信息不能更新信息有時候從產品層面還不如直接拒絕服務）
關係數據庫的缺失
對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地
-
數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求並不高。允許實現最終一致性。 -
數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之 後，過幾秒乃至十幾秒之後，我的訂閱者纔看到這條動態是完全可以接受的。 -
對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
與NoSQL的關係
關係型數據庫
傳統的關係型數據庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到複雜的多表聯合查詢再到事務機制的支持。而與之不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制（事務就是強一致性的體現）。
傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。A代表原子性，即在事務中執行多個操作是原子性的，要麼事務中的操作全部執行，要麼一個都不執行;C代表一致性，即保證進行事務的過程中整個數據加的狀態是一致的，不會出現數據花掉的情況;I代表隔離性，即兩個事務不會相互影響，覆蓋彼此數據等;D表示持久化，即事務一量完成，那麼數據應該是被寫到安全的，持久化存儲的設備上（比如磁盤）。
NoSQL系統僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行的時候是會串行的執行，保證了每一個Key-Value對不會被破壞。