張大胖和CAP定理（分散式系統、可用性、一致性、分割槽容錯性）

轉自：碼農翻身（微訊號：coderising）

計算機界有很多高大上又難於理解的術語，CAP就是其中之一， 什麼一致性（Consistency）， 可用性（Availability）， 分割槽容錯性（Partition tolerance） 就很難理解了， 再加上CAP定理更是讓人云裡霧裡， 今天我們們試圖通俗的演繹一下。

張大胖在公司奮發圖強，經過多年的努力，終於做到了架構師的位置。

架構師的椅子還沒坐熱，很快就來了一個專案要做架構設計。

老闆把大胖叫來，諄諄教導說： 大胖啊， 資料是我們的寶貴資產，你設計的系統可千萬要保證資料不能丟失啊！

大胖說老闆放心， 這方面我有經驗， 一般來講我們要做資料的冗餘處理， 簡單的來講就是給資料做多個副本來儲存。 我會設計一個分散式系統， 把資料備份到多個機器節點去。

幾天後， 大胖給發了一張圖， 展示了這個分散式系統是怎麼工作的：

 

 資料副本在不同的機器上做冗餘， 中間有資料的複製， 保證資料的同步。

雖然只是兩臺機器， 但是也構成了一個簡單的分散式環境。

老闆雖然不懂技術， 但是看到資料在不同的機器之間有備份，也就放心了。

經過幾個月的開發和測試，可容乃幾千人併發的 順利上線， 但是大家很快就發現： 分散式系統不像單機系統那麼簡單， 由於網路的原因， 或者某個機器的原因很容易導致通訊失敗，或者節點不可用。

有一天， 使用者先訪問了左邊的機器A , 寫入了一條資料， 然後機器A很不幸， 網線被悲催的網管給踢掉了， 這直接導致了兩個嚴重的後果：

1. 負載均衡找不著機器A，認為它死翹翹了， 就要把使用者的下一次訪問轉到機器B去。

2. 資料複製也找不著機器A , 只好罷工。 使用者剛寫入的資料沒法複製到機器B，機器B上還是老資料

怎麼辦？ 雖然這是一次偶然， 把網管臭罵一頓， 插上網線就可以了， 但是誰能保證以後兩個機器的通訊是一致暢通的呢？

組裡的小王說： 我們的機器B 還活著呢， 還能提供服務， 資料複製不到機器B， 不就是少看幾條資料嘛， 無傷大雅，不影響大局， 勉強可用， 插上網線後資料複製就會工作， 一切就會恢復正常。

小王無意中選擇了系統的可用性(Availability，簡稱A)， 系統能提供服務就好， 資料不一致可以忍受。

張大胖說: 不行， 老闆說了，我們系統的資料極為重要， 資料如果不一致會帶來嚴重後果，所以機器B上的和這些關鍵資料相關的功能也必須停掉， 必須等到機器A插上網線，資料同步以後才能開工

很明顯， 張大胖遵循老闆指示， 把一致性（Consistency, 簡稱C ）放到了首位。

所以問題就很明顯了， 在網路節點之間無法通訊的情況下, 和資料複製相關的功能， 要麼選擇可用性(A) , 要麼選擇一致性©， 不能同時選擇兩者。

大胖仔細思考了一下， 其實這兩種選擇的背後其實隱藏著另外一個事實， 那就是網路節點之間無法通訊的情況下， 節點被隔離，產生了網路分割槽， 整個系統仍然是可以工作的， 大胖給它起了個名： 分割槽容錯性（Partition tolerance， 簡稱P）。

如果選擇了可用性(A) + 分割槽容錯性(P) , 就要放棄一致性(C)。

如果選在一致性(C) + 分割槽容錯性(P) , 就得放棄可用性(A) ， 對了， 這種情況下，雖然系統的有些功能是不能使用的， 因為需要等待資料的同步， 但是那些和資料同步無關的功能還是可以訪問的 ， 相當於系統做了功能的降級。

既然有AP和CP, 會不會出現僅僅是CA（一致性+可用性）這種組合呢？ 就是沒有分割槽容錯性， 只保留可用性和一致性？ 仔細想想， 這種情況其實就退化成了單機應用， 沒有意義了。

大胖覺得自己似乎發現了一個規律： 在一個分散式計算機系統中，一致性(C)，可用性(A)和分割槽容錯性(P) 這三種保證無法同時得到滿足，最多滿足兩個。

他決定把找個規律叫做CAP定理， 聽起來比較高大上， 顯得自己高深莫測。

如果你實在是搞不懂這CAP, 張大胖會告訴你一個更容易理解的版本： 在一個分散式系統中， 在出現節點之間無法通訊（網路分割槽產生）， 你只能選擇 可用性 或者 一致性， 沒法同時選擇他們。