CAP理論有以下兩個版本：
- 第一個版本的解釋：對於一個分佈式計算系統，不可能同時滿足一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三個設計約束。
- 第二個版本的解釋：在一個分佈式系統（指互相連接並共享數據的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Avaliability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須犧牲。
對比兩個版本的定義，有幾個很關鍵的差異：
第二版定義了什麼才是CAP理論討論的分佈式系統，強調了兩點：interconnected和Share data (連接和數據共享)，為何要強調這兩點呢？因為分佈式系統並不一定會互聯和共享數據。最簡單的如Memcache集群，相互之間沒有連接和數據共享，因此Memcache集群這類分佈式系統不符合CAP理論探討的對象；而Mysql集群就是互聯和進行數據複製的，因此是CAP理論討論的對象。
第二版強調了write/read pair，也就是說，CAP理論關注的是數據的讀寫操作，而不是分佈式系統中的所有功能。如Zookeeper的選舉機制就不是CAP探討的對象。
所以，相比來說，第二版定義更加精確。
一致性
- 第一版：所有節點在同一時刻都能看到相同的數據。
- 第二版：對某個指定的客戶端來說，讀操作保證能返回最新的寫操作結果。
兩版的差異點表現：第一版從節點node角度描述，第二版從客戶端client的角度描述。
可用性
- 第一版：每個請求都能得到成功或失敗的響應。
- 第二版：非故障節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）
分區容錯性
- 第一版：出現消息丟失或都分區錯誤時系統能繼續運行。
- 第二版：當出現網絡分區後，系統能繼續“履行職責”。
對比兩版本解釋，第一版直接說原因，即message loss造成了分區，但message loss定義有點俠隘，因為通常我們說的message loss（丟包）只是網絡故障中的一種；第二版直接說現象，即發生了分區現象，不管是什麼原因，可能是丟包，也可能是網絡中斷，還有可能是擁塞，只要導致了網絡分區，都通通算在裡面。
CAP應用
雖然CAP理論中定義的三個要素中只能取兩個，但放到分佈式環境下來考慮，我們會發現必須選擇分區容錯性，因為網絡本身無法做到100%可靠，可能出現故障，所以分區是一個必然的現象。如果我們選擇了CA,放棄了P，那麼當發生分區現象時，為了保證C,系統需要禁止寫入，當有寫入請求時，系統返回error,這又和A衝突了，因為A要求的是返回no error和no timeout。因此分佈式系統理論上不可能選擇CA架構，只能選擇CP或AP。
CP -Consistency/Partition Tolerance
如圖：
N1節點上的數據已經更新到了y,但N1和N2之前的複製通道中斷，數據y無法同步到N2,N2節點上的數據還是x。為了保證一致性，當發生分區現象後，這時客戶端C訪問N2時，N2需要返回Error,提示客戶端C"系統現在發生了錯誤"，這種處理方式違背了可用性（Availability）的要求，因此CAP三者只能滿足CP。
AP -Availability/Partion Tolerance
如圖
N1節點上的數據已經更新到了y,由於N1和N2之間的複製通道中斷，數據y無法同步到N2,N2節點上的數據還是x。為了保證可用性，當發生分區現象後，這時客戶端C訪問N2時，N2將當前自己擁有的數據x返回給客戶端C了，而實際上當前最新的數據已經是y了，這就不滿足一致性（Consistency）的要求了，因此CAP三者只能滿足AP。
閱讀更多 互聯網說事兒 的文章
