CAP理論作為分布式系統的基礎理論,它描述的是一個分布式系統在以下三個特性中：
- 一致性（Consistency）
- 可用性（Availability）
- 分區容錯性（Partition tolerance）
最多滿足其中的兩個特性。也就是下圖所描述的。分布式系統要么滿足CA,要么CP，要么AP。無法同時滿足CAP。
?
?
I.?什么是 一致性、可用性和分區容錯性
分區容錯性：指的分布式系統中的某個節點或者網絡分區出現了故障的時候，整個系統仍然能對外提供滿足一致性和可用性的服務。也就是說部分故障不影響整體使用。
事實上我們在設計分布式系統是都會考慮到bug,硬件，網絡等各種原因造成的故障，所以即使部分節點或者網絡出現故障，我們要求整個系統還是要繼續使用的
(不繼續使用,相當于只有一個分區,那么也就沒有后續的一致性和可用性了)
?
可用性： 一直可以正常的做讀寫操作。簡單而言就是客戶端一直可以正常訪問并得到系統的正常響應。用戶角度來看就是不會出現系統操作失敗或者訪問超時等問題。
?
一致性：在分布式系統完成某寫操作后任何讀操作，都應該獲取到該寫操作寫入的那個最新的值。相當于要求分布式系統中的各節點時時刻刻保持數據的一致性。
?
II.?該怎么理解
如果我們事先保證了分區容錯性，也意味著若某個節點故障了，用戶還是可以繼續訪問。這時用戶在訪問過程中就會出現一致性和可用性不能同時滿足的情況，參考下圖：
?
如圖假設分布式系統有G1，G2兩個節點，初始值都是v0。現在有一個client向系統寫入了值v1，這里假設直接寫的是節點G1。寫完之后client再去讀取這個值，這時讀到了G2節點,
由于G2節點與G1節點失去連接，這時G1節點上的數據還未同步到G2節點，因此客戶端讀取到的是修改之前的值v0。 這就出現了不滿足一致性的情況了。相當于滿足了可用性，失去了一致性。
?
類似的，如果系統保證了強的一致性，那么在client 寫完G1節點后, 而G1向G2節點同步數據出現了問題，這時如果client再去讀取G2節點的數據時，client就會一直處于等待狀態，因為系統內各節點
數據為同步上，需要等同步上才能使用。這就相當于滿足了一致性，而失去了可用性。
?
?
考慮多個客戶端訪問時，一致性和可用性還可以這么理解：假如client1 向G1 修改某個值的時候, 寫操作還未完成，client2就發起來對該值的讀操作，讀的是G2節點，這時如果要滿足一致性，
那么就得讓client2 暫時無法使用，如果要讓client2 使用，那么獲取到的數據不是最新的，系統就不滿足一致性。
?
?III. CAP三者不可兼得，該如何取舍：
(1) CA: 優先保證一致性和可用性，放棄分區容錯。 這也意味著放棄系統的擴展性，系統不再是分布式的，有違設計的初衷。
(2) CP: 優先保證一致性和分區容錯性，放棄可用性。在數據一致性要求比較高的場合(譬如:zookeeper,Hbase) 是比較常見的做法，一旦發生網絡故障或者消息丟失，就會犧牲用戶體驗，等恢復之后用戶才逐漸能訪問。
(3) AP: 優先保證可用性和分區容錯性，放棄一致性。NoSQL中的Cassandra 就是這種架構。跟CP一樣，放棄一致性不是說一致性就不保證了，而是逐漸的變得一致。
?
?
參考：
https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/
?
