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定理讨論的并不是分布式系統所有的功能。
原文：A read is guaranteed to return the most recent write for a given client.
翻譯：對某個指定的用戶端來說，讀操作保證能夠傳回最新的寫操作結果
關鍵字：a given client（指定的用戶端）。
這裡的一緻性與我們平常了解ACID的一緻性有點偏差，ACID的一緻性關注的是資料庫的資料完整性。
上面定義沒說明是所有節點必須在同一時間資料一緻，而關注點在用戶端，假如有個場景，您在ATM(用戶端)往某張銀行卡存500元後，立刻在ATM發起查詢餘額的時候會顯示加了500元後的餘額，随後我們也能把這500元取出來。查詢餘額讀操作可以是寫後立刻讀的主庫，也或者寫後某個時間段過後（中途無寫）讀從庫。
原文：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叢集的某從庫，同步需要時間，讀取出來可能不是最新的資料，但卻是合理的響應。
原文：The system will continue to function when network partitions occur.
翻譯：當網絡分區發生時，系統将繼續正常運作
關鍵字：continue to function（繼續正常運作）
假如做了一個redis的一主兩從的叢集，某天某個從節點因為網絡故障變成不可用，但是另外的一主一從仍然能正常運作，那麼我們認為它具有分區容錯性。
作為分布式系統，分區必然總會發生（2年1次50分鐘還是1年3次共10分鐘？），是以認為CAP的讨論是大部分建立在P确立前提下。假設我們犧牲了P這個時候因為網絡故障發生了分區導緻節點不可用，這個時候請求響應了error、timeout，與可用性的定義相沖突了。
但是，我們又假如分區大部分時間是不存在的，這時對單節點的讀\寫，那麼就無需作出C、A的取舍。但是上面說分區總會發生這不互相沖突麼，還是取舍。假如1年時間内99.99%時間是正常的，不可用時間為0.01%（52.56分鐘）不可用，若這個時間屬于業務接受範圍，或者隻在某個地區（華南、華北、華中？）有影響，那麼CA也是可以選擇的。
最典型的案例是RDBMS叢集與Redis叢集，這兩種都是利用主從複制實作讀寫分離的方案。假如兩者都是建立一主多從的叢集，在主節點寫入資料，為了保證随後的讀操作擷取最新資料（一緻性），這個讀操作仍會請求主節點（讀寫分離的複雜點在從庫同步不及時導緻業務的異常，為了保證業務的正常性寫後的讀會請求主庫），某個從節點挂了但是隻要主節點和其他從節點仍然正常運作，就滿足分區容錯性。但是哪天主節點因為網絡故障導緻寫操作的error或者timeout，那麼這個系統就不可用了（犧牲可用性）。
這個時候可以引入其他功能和機制完成，例如Redis哨兵模式、故障轉移功能。
最典型的案例是Cassanda叢集和Riak叢集，這種類型的分布式資料庫，可以任意節點寫入，任意節點讀取，當作為叢集出現，無論寫入哪個節點，都将會把該節點的資料同步到其他節點上，因為這種同步方式，讀取資料時隻要通路一個節點就足夠了（喜歡任意通路也不攔着你），但是因為其他節點資料同步原因，資料可能并不是最新的（犧牲一緻性）。如果目前節點因為網絡異常導緻分區變得不可用（無論讀\寫），可以轉移通路節點（可用性）。
另外這裡說的犧牲一緻性，并不代表放棄一緻性，而PA選擇的是最終一緻性（系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一緻的狀态）
上面涉及“犧牲”字眼，并不代表非此即彼的選擇，可以根據子系統、子產品之間的設計上進行混搭使用（例如PA和PC、CA和PC）。
本文對CAP定理做了一個簡單的梳理描述，參考了部分書籍和文章加上自己的了解希望可以跟大家做個分享，如果有不同建議和看法包括文章内描述錯誤，請在下方評論指出，我将及時作出修改。
作 者：
陳珙
出 處：http://www.cnblogs.com/skychen1218/
關于作者：專注于微軟平台的項目開發。如有問題或建議，請多多賜教！
版權聲明：本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結。
聲援部落客：如果您覺得文章對您有幫助，可以點選文章右下角推薦一下。您的鼓勵是作者堅持原創和持續寫作的最大動力！