from:http://divinedm.iteye.com/blog/2252845
首先，CAP理論描述的對象是一個分佈式系統，其中
C：從客戶端來的讀請求訪問任何一個分佈式系統節點，一定能讀到最近的一次寫請求的結果
A：訪問任何一個還存活的分佈式系統節點，一定能夠在一個時間範圍內返回一個肯定的結果（成功或者失敗，不能是超時或者錯誤）
P：分佈式系統允不允許不同節點間的網絡消息丟失。
關於P特性，他的概念不像A和C那樣直觀，網上書上有很多錯誤的理解。想弄明白請讀下面這段話。
關於P特性我有話要說，一個常見的定義，你肯定非常熟悉：“如果網絡異常將一個分佈式系統分成了不能通信的兩個子組，那麼P特性就是要求分佈式應用在每一個子組內都能正常處理請求”，這個定義並不是特別的準確，我稍後解釋。網絡上還有很多中文文章都是抄來抄去再加上抄的人自己的錯誤理解的例子就太多了，不勝枚舉，甚至還有更誇張明顯是錯誤的版本，比如<從paxos到zookeeper>中分區容錯的錯誤定義Page11，該書將P特性定義成“分佈式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務”，簡直就是胡說八道。想弄明白P特性，還是要看英文文檔。這裏推薦一個鏈接http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/，這篇文章援引了2002
SIGACT paper中對p的準確定義。即P特性本質上描述的是對網絡的一個限制要求--網絡中允不允許節點間消息傳遞丟失。如果你的分佈式系統允許網絡的P特性，那麼你必然不能同時滿足一致性和可用性（試想，網絡出現問題，如果還想保證不同group的數據一致，勢必服務需要報錯，從而不滿足可用性。如果追求可用，在給定時間內有成功響應，那麼也就失去了一致性），如果不允許，那麼是能做到一致性和可用性的。滿足P特性就是要求你在C和A中必須做出取捨，換一個等式也許更容易理解
Possibility of Network Partitions => not(availability and consistency)
這樣的等式沒有CAP現在的3選2這麼簡潔，但這也是很多人都錯誤理解CAP的原因所在。回過頭來再看我提到的那個非常熟悉的定義，它看上去更像是在描述A特性（如果一個寫請求到了某一個group，它會如何響應？）
上面這三點對CAP分別得定義是正確理解cap theory的精髓所在！！！！！
再回到流傳最多的白話版本，Brewer的CAP理論證明了：對於任何一個分佈式系統，最多隻能滿足cap三點中的兩點，不可能同時滿足全部。
這是因爲，從實踐的角度來看，網絡是一個不穩定的存在，對於一個分佈式系統而言，如果網絡出現問題，系統就不能服務，這顯然是不能接受的，因此，P特性往往是分佈式系統首先需要滿足的條件。
以此爲基礎，我們接下來看一下下面兩種組合
1 CP
系統追求了C特性和P特性，也就是容忍了A的不足。也就是說，如果節點間網絡出現問題，爲了追求數據的一致性，允許讀請求超時或者返回錯誤。
來個例子加深理解，考慮一個分佈式系統由n1、n2兩個節點構成，如果n1、n2之間的網絡出現了問題，導致n1、n2數據同步停止，此時一個readrequest過來訪問到n2節點，n2需要和n1協商誰的數據是最新的，但是由於網絡中斷，一直不能得出協商的結論，最後以超時或者錯誤返回給客戶端（具體是超時還是錯誤由應用方而定，並沒有要求）
2 AP
系統追求了A特性和P特性，也就是允許C的不足。也就是說，如果節點間網絡出現問題，爲了每個節點都可以及時響應不報錯，那麼就允許了讀請求拿得不是最新更新後的數據。
來個例子加深理解，和上面一樣的分佈式系統，如果n1、n2之間的網絡出現了問題，導致數據同步停止。這時候一個readrequest過來訪問n2節點，由於不需要和n1協商誰的數據最新，因此n2可以直接響應返回，不會超時或者報錯，但是返回的數據就可能不會是最新的了，也就失去了c特性