CAP 定理的簡單理解
布魯斯在1999年提出了 CAP 定理，維基上的定義如下
- 一致性（Consistence），Every read receives the most recent write or an error
- 可用性（Availability），Every request receives a (non-error) response – without guarantee that it contains the most recent write
- 分割槽容錯性（Network partitioning），The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
當系統是單節點的時候，該節點的狀態就是系統的狀態。由於擴充套件系統能力的需要，而將系統擴充套件為多節點的分散式系統時，就引入了資料一致性的問題。
單節點的時候，系統和節點是二位一體的，節點的狀態就是系統的狀態，所謂一人吃飽，全家不餓。
而多節點的時候，為了維持所有節點資料的一致性，就必然要將一個節點的資料變化複製到多個節點。
在現實中，可能由於各種原因導致多個節點的通訊機制出現問題，被分割為了幾個區域，區域間的節點不能互相通訊，即不能保持資料的一致性。（P成為了必選，要在出現分割槽的情況下也能夠提供服務）
此時，有兩種選擇：
保障A，即資料更新複製到某個分割槽內的所有節點就行，不用複製到所有分散式節點，此時失去C；
保障C，將處在其他分割槽的節點設定為資料更新不可用，此時對外就不存在不同的資料版本，保證了資料的一致性，但是損失了A。
這裡的A其實和我們通常認為的可用概念有點不同，容易引起誤解。
看布魯斯12年的 釋疑 ，一開始就提到這三種性質
The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:
+ consistency (C) equivalent to having a single up-to-date copy of the data;
+ high availability (A) of that data (for updates); and
+ tolerance to network partitions (P).
他所指的可用性是針對資料的更新操作而言的（而不是節點是否宕機這類整體故障），只有更新才會與強一致性存在直接的取捨權衡關係。
文章中舉的這個例子就可以理解了
The easiest way to understand CAP is to think of two nodes on opposite sides of a partition. Allowing at least one node to update state will cause the nodes to become inconsistent, thus forfeiting C. Likewise, if the choice is to preserve consistency, one side of the partition must act as if it is unavailable, thus forfeiting A. Only when nodes communicate is it possible to preserve both consistency and availability, thereby forfeiting P.
可用性不是一個 [0,1] 問題，而是 0%~100% 的問題。當為了保障一致性而停用另一個分割槽節點的更新操作時，可以認為性質A損失了50%。
參考
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.6951&rep=rep1&type=pdf
https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed