CAP的定義

CAP定理（CAP theorem）又被稱作布魯爾定理（Brewer’s theorem），是分布式系統設計中最基礎、最重要的理論，它的意思是對于一個分布式計算系統來說，不可能同時滿足以下三點條件：

• 一致性（Consistency）：每次讀取要么獲得最近寫入的數據，要么獲得一個錯誤。

• 可用性（Availability）：每次請求都能獲得一個(非錯誤)響應，但不保證獲得的數據為最新數據。

• 分區容錯性（Partition tolerance）：盡管任意數量的消息被節點間的網絡丟失（或延遲），系統仍繼續運行。

這三個條件的核心都是數據，數據是否一致，數據是否可用，數據是否做了分區容錯。

為了更好的理解CAP原理，下面我來為大家介紹各個條件實際的應用場景。

• 一致性 
  銀行系統部署了N個節點，其中一個節點收到了用戶的轉賬請求，在該請求處理的過程中，以及處理結束后，無論訪問銀行系統的哪個節點，查詢到該用戶的賬戶金額都應該是一致的。 
  需要注意的是，CAP的一致性與ACID的一致并不相同，CAP側重于不同系統節點的數據一致，ACID則側重于數據庫事務的完整性。

• 可用性 
  與一致性不同，可用性只要能正常響應請求就可以了，哪怕該請求依賴的數據不是最新的也不要緊。 
  比如一個賣書網站，用戶A在某一時刻看到的庫存是1，此時用戶B先買了最后一本書，實際庫存變成0，但是用戶A不知道，也做了下單操作。 
  如果是一個強調一致性的系統，此時會告訴用戶：庫存不足，下單失敗。而一個強調可用性的系統，則會讓用戶下單成功，然后通過其它辦法補充庫存。

• 分區容錯性 
  在不同節點上保存相同的數據副本，當一個節點的數據發生變更時，通知其它節點也做相同的數據變更。

為什么CAP不能同時滿足？

• 滿足CA（一致性 + 可用性）的系統 
  這樣的系統強調一致性和可用性，如果要做P（分區容錯），就需要將數據在不同節點之間同步，但是同步是需要時間的，在同步還沒有完成的時候各個節點的數據并不一致，為了滿足一致性C，需要將數據未同步的節點變為暫時的不可用狀態，但這樣做就無法保證可用性A。 
  反過來講，如果讓未同步數據的節點可用，C就得不到滿足，真是魚與熊掌不可兼得。 
  因此對于一個CA系統，最常見的做法是數據不分區，都保存在一起。

• 滿足CP（一致性 + 分區容錯性）的系統 
  在前面例子中已經說到，如果要滿足CP，需要將未同步到最新數據的節點變為不可用狀態，因此無法同時兼容A。

• 滿足AP（可用性 + 分區容錯性）的系統 
  參考前面的結論： 
  有了CA不能保證P。 
  有了CP不能保證A。 
  因此AP系統不能兼容C。

CAP定理的意義

了解這么繞的一個定理，對于我們設計分布式系統有什么作用呢？我個人認為，掌握CAP定理，能夠讓我們認識到對于分布式系統而言，出現故障時在所難免的，我們不可能構建一個完全不出故障的系統。

相反的，我們可以換一個思路，考慮在出現故障時如何能夠維持系統的正常運轉，結合系統的實際運行場景，在C、A、P三個條件進行適當的取舍。

本文轉自王濤的技術博客，原文鏈接：https://www.taowong.com/blog/2018/07/10/cap-theorem.html