CAP理論

• 注：文章來源：極客時間的專欄《從0開始學架構》

CAP定理又稱做布魯爾定理。

CAP理論

• 初版解釋：

對於一個分佈式計算系統，不可能同時知足一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三個設計約束。

• 第二版解釋：

在一個分佈式系統（指互相鏈接並共享數據的節點的集合）中，當涉及讀寫操做時，只能保證一致性、可用性、分區容錯性三者中的兩個，另一個必須被犧牲。

差別點

• 第二版定義了什麼纔是CAP理論探討的分佈式系統，強調了兩點：interconnected（互聯）和share data。由於分佈式系統並不必定會互聯和共享數據。最簡單的例如Memcache的集羣，相互之間就沒有鏈接和共享數據，所以Memcache集羣這類分佈式系統就不符合CAP理論探討的對象；而MySQL集羣就是互聯和進行數據複製的，所以是CAP理論探討的對象。
• 第二版強調了write/read pair。CAP關注的是對數據的讀寫操做，而不是分佈式系統的全部功能。例如，Zookeeper的選舉機制就不是CAP探討的對象。

1. 一致性

• 初版解釋：

全部節點在同一時刻都能看到相同的數據。

• 第二版解釋：

對某個指定的客戶端來講，讀操做保證可以返回最新的寫操做結果。

差別點：

• 初版從節點node的角度描述，第二版從客戶端client的角度描述。

第二版更符合咱們觀察和評估系統的方式，即站在客戶端的角度來觀察系統的行爲和特徵。

對於系統執行事務來講，在事務執行過程當中，系統其實處於一個不一致的狀態，不一樣的節點的數據並不徹底一致

2. 可用性

• 初版解釋：

每一個請求都能獲得成功或者失敗的響應。

• 第二版解釋：

非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時的響應）。

差別點：

• 初版是every request，第二版強調了A non-failing node。

初版的every request是不嚴謹的，由於只有非故障節點才能知足可用性要求，若是節點自己就故障了，發給節點的請求不必定能獲得一個響應。

• 初版的response分爲success和failure，第二版用了兩個reasonable：reasonable response和reasonable time，並且強調了no error or timeout。

初版的success/failure的定義太泛了，幾乎任何狀況，不管是否符合CAP理論，咱們均可以說請求成功和失敗，由於超時也算失敗、錯誤也算失敗、異常也算失敗、結果不正確也算失敗；即便是成功的響應，也不必定是正確的。例如，原本應該返回100，但實際上返回了90，這就是成功的響應，但並無獲得正確的結果。相比之下，第二版的解釋明確了不能超時、不能出錯，結果是合理的，注意沒有說「正確」的結果。

3. 分區容錯性

• 初版解釋：

出現消息丟失或者分區錯誤時系統可以繼續運行。

• 第二版解釋：

當出現網絡分區後，系統可以繼續「履行職責」。

差別點：

• 初版用的是work，第二版用的是function。

work強調「運行」，只要系統不宕機，咱們均可以說系統在work，返回錯誤也是work，拒絕服務也算work；而function強調「發揮做用」「履行職責」，這點和可用性是一脈相承的。也就是說，只有返回reasonable response纔是function。

• 初版描述分區用的是message loss or partial failure，第二版直接用network partitions。

初版是直接說緣由，即message loss形成了分區，但message loss的定義有點狹隘，由於一般咱們說的是message loss（丟包），只是網絡故障的一種；第二版直接說現象，即發生分區現象 ，無論什麼緣由，多是丟包，也多是鏈接中斷，還多是擁塞，只要致使了網絡分區，就統統算在裏面。

CAP應用

雖然CAP理論定義是三個要素中只能取兩個，但放到分佈式環境下來思考，咱們會發現必須選擇P（分區容錯）要素，由於網絡自己沒法作到100%可靠，有可能出故障，因此分區是一個必然的現象。若是咱們選了CA而放棄P，那麼當發生分區現象時，爲了保證C，系統須要禁止寫入，當有寫入請求時，系統返回error（例如，當前系統不容許寫入），這又和A衝突了，由於A要求返回no error和 no timeout。所以，分佈式系統理論上不可能選擇CA架構，只能選擇CP或者AP架構。

1. CP

以下圖所示，爲了保證一致性，當發生分區現象後，N1節點上的數據已經更新到y，但因爲N1和N2之間的複製通道中斷，數據y沒法同步到N2，N2節點上的數據仍是x。這時客戶端C訪問N2時，N2須要返回error，提示客戶端C「系統如今發生了錯誤」，這種處理方式違背了可用性的要求，所以CAP三者只能知足CP。

2. AP

以下圖所示，爲了保證可用性，當發生分區現象後，N1節點上的數據已經更新到y，但因爲N1和N2之間的複製通道中斷，數據y沒法同步到N2，N2節點上的數據仍是x。這時客戶端C訪問N2時，N2將當前本身擁有的數據x返回給客戶端C了，而實際上當前最新的數據已是y了，這就不知足一致性的要求了，所以CAP三者只能知足AP。注意：這裏N2節點返回x，雖然不是一個「正確」的結果，可是一個「合理」的結果，由於x是舊的數據，並非一個錯亂的值。

注：有興趣瞭解極客時間專欄的同窗，能夠查看極客時間專欄—可提供返現服務