前言
CAP的理解我也看了很多書籍，也看了不少同行的博文，基本每個人的理解都不一樣，而布魯爾教授得定義又太過的簡單，沒有具體描述和場景案例分析。因此自己參考部分資料梳理了一篇與大家互相分享一下。
標題寫了正確理解，或許某些點不是百分百正確或者有歧義，但是希望與各位分享討論後達到最終正確，
簡介
CAP定理，又被稱作布魯爾定理（Brewer's theorem），是埃裏克·布魯爾教授在2000 年提出的一個猜想，它指出對於一個分佈式系統來說，不可能同時滿足以下三點：
- Consistency（一致性）: where all nodes see the same data at the same time.（所有節點在同一時間具有相同的數據）
- Availability（可用性）: which guarantees that every request receives a response about whether it succeeded or failed.（保證每個請求不管成功或者失敗都有響應）
- Partition tolerance（分隔容忍）: where the system continues to operate even if any one part of the system is lost or fails.（系統中任意信息的丟失或失敗不會影響系統的繼續運作）
很多書籍與文章引用Robert Greiner在2014年8月寫的一篇博文 http://robertgreiner.com/2014/08/cap-theorem-revisited/。相比與看着布魯爾教授一臉懵逼的定義，Robert Greiner的更加容易理解。
定義
原文：In a distributed system (a collection of interconnected nodes that share data.), you can only have two out of the following three guarantees across a write/read pair: Consistency, Availability, and Partition Tolerance - one of them must be sacrificed.
翻譯：在一個分佈式系統（指互相連接並共享數據的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。
關鍵字：interconnected nodes（互連節點）、share data（共享數據）、a write/read pair（讀／寫）
從上面一段話，有幾個，也就是說我們聊CAP定理的時候，是在具有數據讀寫、數據共享和節點互連的前提下，對上面三者選其二，也是建議我們不要花費時間與精力同時滿足三者。
舉例說明，web集羣、memcached集羣不屬於討論對象
- web集羣只是資源複製分配在不同的節點上，然而節點間沒有互連、也沒有數據共享（sessionid、memory cache）。
- memcached集羣數據存儲是通過客戶端實現哈希一致性，但是集羣節點間不互連的，也沒有數據共享。
總得來說，CAP定理討論的並不是分佈式系統所有的功能。
一致性（Consistency）
原文：A read is guaranteed to return the most recent write for a given client.
翻譯：對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結果
關鍵字：a given client（指定的客戶端）。
這裏的一致性與我們平常瞭解ACID的一致性有點偏差，ACID的一致性關注的是數據庫的數據完整性。
上面定義沒說明是所有節點必須在同一時間數據一致，而關注點在客戶端，假如有個場景，您在ATM(客戶端)往某張銀行卡存500元后，立刻在ATM發起查詢餘額的時候會顯示加了500元后的餘額，隨後我們也能把這500元取出來。查詢餘額讀操作可以是寫後立刻讀的主庫，也或者寫後某個時間段過後（中途無寫）讀從庫。
可用性（Availability）
原文：A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
翻譯：非故障節點將在合理的時間內返回合理的響應（不是錯誤或超時）。
關鍵字：non-failing node（非故障節點）、reasonable response（合理的響應）
這裏的可用性和我們平常所理解的高可用性有點偏差，高可用性指系統無中斷的執行其功能的能力。
已故障的節點就不具有可用性了，因爲請求結果要麼error要麼 timeout。合理的響應沒有說明是成功還是失敗，但是響應應該具有是否成功的精確描述。例如我們讀取sql server集羣的某從庫，同步需要時間，讀取出來可能不是最新的數據，但卻是合理的響應。
分區容錯性（Partition tolerance）
原文：The system will continue to function when network partitions occur.
翻譯：當網絡分區發生時，系統將繼續正常運作
關鍵字：continue to function（繼續正常運作）
假如做了一個redis的一主兩從的集羣，某天某個從節點因爲網絡故障變成不可用，但是另外的一主一從仍然能正常運作，那麼我們認爲它具有分區容錯性。
CA-犧牲分區容錯性
作爲分佈式系統，分區必然總會發生（2年1次50分鐘還是1年3次共10分鐘？），因此認爲CAP的討論是大部分建立在P確立前提下。假設我們犧牲了P這個時候因爲網絡故障發生了分區導致節點不可用，這個時候請求響應了error、timeout，與可用性的定義相沖突了。
但是，我們又假如分區大部分時間是不存在的，這時對單節點的讀\寫，那麼就無需作出C、A的取捨。但是上面說分區總會發生這不互相矛盾麼，還是取捨。假如1年時間內99.99%時間是正常的，不可用時間爲0.01%（52.56分鐘）不可用，若這個時間屬於業務接受範圍，或者只在某個地區（華南、華北、華中？）有影響，那麼CA也是可以選擇的。
PC-犧牲可用性
最典型的案例是RDBMS集羣與Redis集羣，這兩種都是利用主從複製實現讀寫分離的方案。假如兩者都是建立一主多從的集羣，在主節點寫入數據，爲了保證隨後的讀操作獲取最新數據（一致性），這個讀操作仍會請求主節點（讀寫分離的複雜點在從庫同步不及時導致業務的異常，爲了保證業務的正常性寫後的讀會請求主庫），某個從節點掛了但是隻要主節點和其他從節點仍然正常運作，就滿足分區容錯性。但是哪天主節點因爲網絡故障導致寫操作的error或者timeout，那麼這個系統就不可用了（犧牲可用性）。
這個時候可以引入其他功能和機制完成，例如Redis哨兵模式、故障轉移功能。
PA-犧牲一致性
最典型的案例是Cassanda集羣和Riak集羣，這種類型的分佈式數據庫，可以任意節點寫入，任意節點讀取，當作爲集羣出現，無論寫入哪個節點，都將會把該節點的數據同步到其他節點上，因爲這種同步方式，讀取數據時只要訪問一個節點就足夠了（喜歡任意訪問也不攔着你），但是因爲其他節點數據同步原因，數據可能並不是最新的（犧牲一致性）。如果當前節點因爲網絡異常導致分區變得不可用（無論讀\寫），可以轉移訪問節點（可用性）。
另外這裏說的犧牲一致性，並不代表放棄一致性，而PA選擇的是最終一致性（系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態）
總結
上面涉及“犧牲”字眼，並不代表非此即彼的選擇，可以根據子系統、模塊之間的設計上進行混搭使用（例如PA和PC、CA和PC）。
本文對CAP定理做了一個簡單的梳理描述，參考了部分書籍和文章加上自己的理解希望可以跟大家做個分享，如果有不同建議和看法包括文章內描述錯誤，請在下方評論指出，我將及時作出修改。