CAP到底是什麼?
在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對於一個分佈式計算系統來說，不可能同時滿足以下三點：
- 一致性（Consistency） （等同於所有節點訪問同一份最新的數據副本）
- 可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的數據爲最新數據）
- 分區容錯性（Partition tolerance）（以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。）
也就是著名的CAP三選二。因爲這個定理有實際的理論支撐、並被學術界廣泛認可，所以大家一定要記住，CAP全有的情形是不存在的。實際上，因爲定理在中文的翻譯下容易讓人產生誤解，所以很多人會以爲，只要在分佈式情形下，就算什麼也不做，系統都可以保證至少有兩個屬性，或者我們可以任意選擇其中兩種屬性。但是，其實，就算不發生分區情形，想在分佈式系統內部實現CA，也是很難、很複雜的。比如，以前的Servlet都是將用戶的Session存在服務器上的，這個時候如果要將單機服務器擴展到集羣情形，那怎麼保證用戶的Session在每臺機器上都是一致的呢？這個時候，要麼需要應用自己去做額外的同步協調工作，要麼只能想辦法讓用戶的請求只打到同一臺機器上。因爲這種問題的存在，爲了實現服務的擴展性，所以現在都是將服務做成無狀態的。用戶的Session之類的管理丟給分佈式緩存（redis、memcache）等來處理，由已經實現了對CA的支持的分佈式KV組件來幫忙處理這些讓人難受的問題。
大白話：
分區容錯性P其實就是每個服務都會有多個節點（一般都是主從），這樣就可以保證此服務的一個節點掛了之後，此服務的其他節點依然可以響應，其實這就是分區容錯性。
但是一個服務有多個節點之後，一個服務的 多個節點之間 的數據爲了保持一致性就要進行 數據複製 ，在此過程中就會出現數據一致性C（強一致性）的問題。 (數據一致性包含強一致性，弱一致性，最終一致性，這裏指的是強一致性)
如果一定要保持一致性C，可以不做分區，即每個服務都是單節點，這樣就不用考慮數據一致性問題了，但是每個服務只有一個節點，此節點掛了，此服務就能不可用了，分區就不能容錯了，那就不是高可用分佈式系統了，所以一般分佈式系統都必須滿足分區容錯性P。
在滿足了分區容錯性P後，想要滿足一致性C，一個服務的多個節點之間就必須進行數據複製達到數據一致之後再返回給調用者響應，然而在多個節點數據複製的過程中，可能節點之間會出現網絡等問題使得數據複製阻塞或失敗導致響應超時，服務調用失敗，這就失去了系統的可用性A。
如果不強制滿足強一致性，那在服務被調用的時候不用管數據複製的問題，直接返回響應，這就滿足了可用性，但是由於此服務的多個節點數據可能沒有完成複製，節點數據可能不一致，這就失去了系統的一致性。
結論：一個高可用的分佈式系統分區容錯性P是一定要滿足的，在此基礎上，只能滿足可用性A或者一致性C