本文參考EricBrewer部落格加上自己的理解整理。

CAP定理又被成為布魯爾定理，是加州大學電腦科學家埃裡克·布魯爾提出來的猜想，後來被證明成為分散式計算領域公認的定理。

CAP定義，在高併發的場景下要做取捨，在大型叢集中分割槽容錯很難保證，一旦要確保容錯性，那麼就會損失資料一致性和高可用特性。所以可以認為CAP 的 P 總是成立，剩下的 C 和 A 無法同時做到。

1 CAP理解

C 一致性（Consistency）

系統由G1,G2兩臺伺服器組成，兩臺伺服器都有一個數據 V，初始值為V0。G1和G2相互可以通訊，也可以與客戶端通訊。如下圖

客戶端向G1寫入資料，將G1中的V值改成V1，並從G1中讀取V的值。目前操作是具備一致的的。如下圖

那麼此時如果向G2發起讀請求的話，因為資料沒有同步，就會得到V的值為V0,實際已經向叢集寫入了V=V1，此時資料不一致。如下圖

我們可以通過G1將資料同步到G2，這時客戶端再去讀取，就會解決一致性的問題。如下圖

小結
一致性是指分散式系統中，資料在多節點存在副本，資料如果一直不修改，在讀的時候是不存在問題的，訪問哪個節點的資料都一樣。可一旦要是發生了修改，如果資料同步無法在修改的瞬間廣播到所有副本節點那麼在讀的時候就可能發生資料髒讀。

A 可用性（Availability）

指的是服務是否可用，範圍涵蓋終端客戶訪問我們的系統或者是叢集內部相互通訊交換資料，也就是說在Client向Server發起請求時，伺服器返回了正確的響應，稱之為可用，反之為不可用。
這裡有一個問題，如果傳送請求在很久之後才返回資料，那麼算不算可用？

• “強網” (4G/WIFI)下，1秒完全完成頁面載入，包括首屏資源，可看亦可用;
• 3G下1秒完成首包的返回 ;
• 2G下1秒完成建連。

P 分割槽容錯性（Partition tolerance）

指發生在分散式系統內部相互訪問的通訊網路不可以用，但系統依然正常對外提供服務。如下圖

上圖說明：
叢集中存在3臺節點：server1、server2、server3 。叢集內部server1和server3網路不可用，但是server1和server2，server2和server3相互通訊是正常的。客戶端client1可以與server1和server2通訊，客戶端client2可以與server2和server3通訊。整個叢集對於客戶端來說不會因為server1和server3之前網路不可用而停止服務。因此我們可以認為叢集分割槽具備容錯性。
小結

2 BASE理論

eBay的架構師Dan Pritchett源於對大規模分散式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（StrongConsistency，CAP的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。

基本可用（Basically Available）

在分散式系統出現故障的時候，允許損失部分可用性,支援分割槽失敗，即保證核心可用。

軟狀態（Soft State）

接受一段時間的狀態不同步，及中間狀態，而改中間狀態不影響系統整體可用性。這裡的中間狀態就是CAP理論中的資料不一致性。

最終一致性（Eventually Consistent）

上面說軟狀態，然後不可能一直是軟狀態，必須有個時間期限。在期限過後系統能夠保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問最終都能夠獲取到最新的值。

3 基於CAP架構選型對比

Zookeeper叢集

保證CP。即任何時刻對zookeeper的訪問請求能得到一致性的資料結果，同時系統對網路分割具備容錯性，但是它不能保證每次服務的可用性。從實際情況來分析，在使用zookeeper獲取服務列表時，如果zk正在選舉或者zk叢集中半數以上的機器不可用，那麼將無法獲取資料。所以說，zk不能保證服務可用性。

Redis叢集

保證AP。Redis通過AOF和RDB將資料同步到子節點。如果Master節點掛了，可以很迅速的將Slave提升為Master，儘可能的保證了系統的可用性，但是可能存在資料丟失的問題。所以Redis其實並不適合做分散式鎖。

Eureka叢集

保證AP，eureka在設計時優先保證可用性，每一個節點都是平等的，一部分節點掛掉不會影響到正常節點的工作，不會出現類似zk的選舉leader的過程，客戶端發現向某個節點註冊或連線失敗，會自動切換到其他的節點，只要有一臺eureka存在，就可以保證整個服務處在可用狀態，只不過有可能這個服務上的資訊並不是最新的資訊。