點擊上方"java全棧技術"關注，每天學習一個java知識點
計算機界有很多高大上又難於理解的術語，CAP就是其中之一， 什麼一致性（Consistency）， 可用性（Availability）， 分區容錯性（Partition tolerance） 就很難理解了， 再加上CAP定理更是讓人云裡霧裡， 今天咱們試圖通俗的演繹一下。
張大胖在公司奮發圖強，經過多年的努力，終於做到了架構師的位置。
架構師的椅子還沒坐熱，很快就來了一個項目要做架構設計。
老闆把大胖叫來，諄諄教導說： 大胖啊， 數據是我們的寶貴資產，你設計的系統可千萬要保證數據不能丟失啊！
大胖說老闆放心， 這方面我有經驗， 一般來講我們要做數據的冗餘處理， 簡單的來講就是給數據做多個副本來保存。 我會設計一個分佈式系統， 把數據備份到多個機器節點去。
幾天後， 大胖給發了一張圖， 展示了這個分佈式系統是怎麼工作的：
數據副本在不同的機器上做冗餘， 中間有數據的複製， 保證數據的同步。
雖然只是兩臺機器， 但是也構成了一個簡單的分佈式環境。
老闆雖然不懂技術， 但是看到數據在不同的機器之間有備份，也就放心了。
經過幾個月的開發和測試，系統順利上線， 但是大家很快就發現： 分佈式系統不像單機系統那麼簡單， 由於網絡的原因， 或者某個機器的原因很容易導致通訊失敗，或者節點不可用。
有一天， 用戶先訪問了左邊的機器A , 寫入了一條數據， 然後機器A很不幸， 網線被悲催的網管給踢掉了， 這直接導致了兩個嚴重的後果：
1. 負載均衡找不著機器A，認為它死翹翹了， 就要把用戶的下一次訪問轉到機器B去。
2. 數據複製也找不著機器A , 只好罷工。 用戶剛寫入的數據沒法複製到機器B，機器B上還是老數據
怎麼辦？ 雖然這是一次偶然， 把網管臭罵一頓， 插上網線就可以了， 但是誰能保證以後兩個機器的通信是一致暢通的呢？
組裡的小王說： 我們的機器B 還活著呢， 還能提供服務， 數據複製不到機器B， 不就是少看幾條數據嘛， 無傷大雅，不影響大局， 勉強可用， 插上網線後數據複製就會工作， 一切就會恢復正常。
小王無意中選擇了系統的可用性(Availability，簡稱A)， 系統能提供服務就好， 數據不一致可以忍受。
張大胖說: 不行， 老闆說了，我們系統的數據極為重要， 數據如果不一致會帶來嚴重後果，所以機器B上的和這些關鍵數據相關的功能也必須停掉， 必須等到機器A插上網線，數據同步以後才能開工
很明顯， 張大胖遵循老闆指示， 把一致性（Consistency, 簡稱C ）放到了首位。
所以問題就很明顯了， 在網絡節點之間無法通信的情況下, 和數據複製相關的功能， 要麼選擇可用性(A) , 要麼選擇一致性(C)， 不能同時選擇兩者。
大胖仔細思考了一下， 其實這兩種選擇的背後其實隱藏著另外一個事實， 那就是網絡節點之間無法通信的情況下， 節點被隔離，產生了網絡分區， 整個系統仍然是可以工作的， 大胖給它起了個名：
分區容錯性（Partition tolerance， 簡稱P）。如果選擇了可用性(A) + 分區容錯性(P) , 就要放棄一致性(C)。
如果選在一致性(C) + 分區容錯性(P) , 就得放棄可用性(A) ， 對了， 這種情況下，雖然系統的有些功能是不能使用的， 因為需要等待數據的同步， 但是那些和數據同步無關的功能還是可以訪問的 ， 相當於系統做了功能的降級。
既然有AP和CP, 會不會出現僅僅是CA（一致性+可用性）這種組合呢？ 就是沒有分區容錯性， 只保留可用性和一致性？ 仔細想想， 這種情況其實就退化成了單機應用， 沒有意義了。
大胖覺得自己似乎發現了一個規律： 在一個分佈式計算機系統中，一致性(C)，可用性(A)和分區容錯性(P) 這三種保證無法同時得到滿足，最多滿足兩個。
他決定把找個規律叫做CAP定理， 聽起來比較高大上， 顯得自己高深莫測。
如果你實在是搞不懂這CAP, 張大胖會告訴你一個更容易理解的版本： 在一個分佈式系統中， 在出現節點之間無法通信（網絡分區產生）， 你只能選擇 可用性 或者 一致性， 沒法同時選擇他們。
閱讀更多 java全棧技術 的文章
