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