對CAP定理的理解

 

CAP定理的常規解釋是任何分佈式系統只能在一致性(Consitency)，可用性(Availability)和分區容忍性(Partition Tolerance)中三選二。這個解釋很讓人費解，筆者在看了一些文章後談談我對它的理解，還請斧正。

從問題出發

假設咱們用一臺服務器A對外提供存儲服務，爲了不這臺服務器宕機致使服務不可用，咱們又在另一臺服務器B上運行了一樣的存儲服務。每次用戶在往服務器A寫入數據的時候，A都往服務器B上寫一份，而後再返回客戶端。一切都運行得很好，用戶的每份數據都存了兩份，分別在A和B上，用戶訪問任意一臺機器都能讀取到最新的數據。
這時不幸的事情發生，A和B之間的網絡斷了致使A和B沒法通訊，也就是說網絡出現了分區，那麼用戶在往服務器A寫入數據的時候，服務器A沒法將該數據寫入到服務器B。這時，服務器A就必需要作出一個艱難的選擇：

• 要麼選擇一致性(C)而犧牲可用性(A)：爲了保證服務器A和B上的數據是一致的，服務器A決定暫停對外提供數據寫入服務，從而保證了服務器A和B上的數據是一致，可是犧牲了可用性。
  注意：這裏的可用性不是咱們一般所說的高可用性(好比，服務器宕機致使服務不可用)，而是指服務器雖然活着，可是卻不能對外提供寫入服務。
• 要麼選擇可用性(A)而犧牲一致性(C)：爲了保證服務不中斷，服務器A先把數據寫入到了本地，而後返回客戶端，從而讓客戶端感受數據已經寫入了。這致使了服務器A和B上的數據就不一致了。

這就是CAP定理試圖解釋的問題。

分佈式系統沒法放棄網絡分區容忍性

網絡分區準確地說是指兩臺機器沒法在指望的時間內完成數據交換。這不單單是指兩臺機器之間的網絡徹底斷開了,還可能有其餘狀況產生網絡分區，好比對方機器宕機了，網絡延時等狀況。所以，在分佈式系統中，一般是沒法放棄Partition Tolerance的，也就只能在CP和AP之間作選擇了。若是有個分佈式系統號稱是CA的，那必定是扯淡。

可用性和一致性的選擇

可用性和一致性之間的選擇不是非此即彼的，而是根據業務的需求在它們二者之間作妥協。好比，咱們能夠放棄對強一致性的追求，讓其變成最終一致性，也就是說當服務器A不能把數據傳給服務器B時，它先將數據緩存在其本地，等到網絡恢復之後再將數據傳給服務器B。這樣，服務仍是可用的，只是在必定的時間窗口內二者的數據是不一致的。

對網絡分區的處理

對網絡分區的處理有如下幾個步驟：

1. 檢測網絡是否出現分區
2. 當分區出現了，進入分區模式並限制某些操做
3. 當網絡恢復後，啓動分區恢復

從圖中可見（圖片來自 InfoQ），系統最開始是處於一致的狀態S，而後分區出現了，每一個分區的狀態分別變成了S1和S2（這是爲了保證系統的可用性，每一個分區繼續響應客戶端的請求）。接着，網絡恢復後開始分區合併，將S1和S2狀態合併成爲新的一致狀態S‘。是否是看起來和代碼版本管理很相似？

小結

其實CAP定理自己很簡單，只是被人爲地搞複雜了。簡單地說，就是分佈式系統中，架構師只能在一致性和可用性之間妥協。而複雜的是如何根據業務系統的須要在兩者之間取捨，以及如何應對網絡出現分區。

參考文獻

• http://codahale.com/you-cant-sacrifice-partition-tolerance/
• http://ksat.me/a-plain-english-introduction-to-cap-theorem/
• http://www.quora.com/Can-someone-provide-an-intuitive-proof-explanation-of-CAP-theorem
• http://robertgreiner.com/2014/08/cap-theorem-revisited/
• http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
• http://blog.foundationdb.com/minimal-explanation-of-the-cap-theorem
• http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/