本文介紹了介紹了分布式系統著名的 cap 理論。什麼是 cap 理論？為什麼說 cap 隻能三選二？了解 cap 對于系統架構又有什麼指導意義？本文将一一作答。
在計算機科學理論，cap 定理（也稱為 brewer 定理），是由計算機科學家 eric brewer 提出的，即在分布式計算機系統不可能同時提供以下全部三個保證：
一緻性（consistency）：所有節點同一時間看到是相同的資料；
可用性（availability）：不管是否成功，確定每一個請求都能接收到響應；
分區容錯性（partition tolerance）：系統任意分區後，在網絡故障時，仍能操作
下面分别舉例說明了為什麼說 cap 隻能三選二。
上面的圖顯示了在一個網絡中，n1 和 n2 兩個節點。他們都共享資料塊 v，其中有一個值 v0 。運作在 n1 的 a 程式可以認為是安全的、無 bug、可預測的和可靠的。運作在 n2 是 b 程式。這個例子中，a 将寫入 v 新值，而 b 從 v 讀取值
系統預期執行下面的操作
首先寫一個 v 的新值 v1
然後消息（m）從 n1 更新 v 的拷貝到 n2
現在，從 b 讀取将傳回 v1
如果網絡是分區的，當 n1 到 n2 的消息不能傳遞時，執行上面的第三步，會出現雖然 n2 能通路到 v 的值（可用性），但其實與 n1 的 v 的值已經不一緻了（一緻性）。
舉例：
單站點資料庫
叢集資料庫
ldap
xfs 檔案系統
實作方式：
兩階段送出
緩存驗證協定
分布式資料庫
分布式鎖定
絕大部分協定
悲觀鎖
少數分區不可用
coda
web 緩存
dns
到期/租賃
解決沖突
樂觀
在系統架構時，應該根據具體的業務場景，來權衡 cap。比如，對于大多數網際網路應用來說（如門戶網站），因為機器數量龐大，部署節點分散，網絡故障是常态，可用性是必須需要保證的，是以隻有舍棄一緻性來保證服務的 ap。而對于銀行等，需要確定一緻性的場景，通常會權衡 ca 和 cp 模型，ca 模型網絡故障時完全不可用，cp 模型具備部分可用性。