什麼是 CAP 理論？

CAP 理論是指在一個分散式系統中，當涉及讀寫操作時，只能保證一制性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，剩下的一個必須被犧牲。

一制性 Consistency：對某個客戶端來說，讀操作保證能夠返回最新寫操作的結果。以社群網站來說，假如今天你按了某個貼文讚，其他看貼文的人如果馬上看到，那就是有一致性；但如果其他人沒有馬上看到貼文多了一個讚，那就是沒有維持一致性。
可用性 Availability：非故障節點能在合理的時間內，返回合理地響應，意即不是錯誤和超時的響應，讓系統能維持可用的狀態。以社群網站來說，如果今天你進到網站中，看到某個喜歡的貼文要按讚，但是按不了，那就是不可用。
分區容錯性 Partition Tolerance：當出現分區時（封包遺失、連接中斷、塞車等），系統能夠繼續履行職責（返回合理的響應）。

讓我們再用比較具體的例子來說明。想像今天你要設計銀行的 ATM 系統，會在世界各地都設置 ATM 系統。每個 ATM 機器都可以想像成一個節點，這些節點透過網路連接，知道目前系統的狀態。

然而，假如今天網路連接出問題，這時如果想從在路口的 A 機台領錢，在沒有網路連接的情況下，A 機台無從得知其他機台的狀態，這時如果用戶甲從 A 機台領了錢，然後走到轉角後想到自己少領，所以在馬路轉角的 B 機台領，因為 A 與 B 兩者沒有連線，所以在 B 機台領錢時，B 機台不會知道餘額要被扣掉剛剛領的，這時會導致餘額顯示錯誤。

上面這種狀況，就是保持可用性，但是一致性出問題 (A 與 B 機台的餘額顯示不一致)，在 ATM 的設計下，這會是個大問題。因此，多數 ATM 不會這樣設計，而是會選擇保持一致性。

但如果我們要保持一致性，就會犧牲可用性，因為若要保持一致性，當網路連接出問題時，就需要暫時鎖死不讓人從任何機台領錢，這樣每台的餘額都會維持一致；但若不給領錢，可用性就會出問題。

CAP 的應用

在分散式系統中，必然會需要選擇 P ，因為網路本身不可能做到 100% 可靠，因此可能的系統可能是 AP 或者是 CP 。

CP：當兩節點 Node 1 將 A 更新為 1 ，當 Node 1 欲將 A 複製到 Node 2 時發生錯誤，則 Client 重新在 Node 2 讀取 A 值時，因為為了確保 Consistency ，所以會得到 Error 。

AP：當兩節點 Node 1 將 A 更新為 1 ，當 Node 1 欲將 A 複製到 Node 2 時發生錯誤，則 Client 重新在 Node 2 讀取 A 值時，因為為了確保 Availability，所以會得到舊的值 0 。

用 CAP 輔助思考系統設計

不同子系統有不同策略

在討論 CAP 時，通常都是以系統、節點的方式來討論，以至於會誤以為系統架構要不選擇可用性，要不選擇一致性，但其實以系統的角度來看，每一個子系統，可能根據不同的特性，可以選擇不同策略，某些部分使用可用性，某些部分則使用一致性。

以搶票系統來說，在最核心的搶票部分，一致性是最關鍵的，因為不一致就可能導致剩下一張票，但兩個人同時買到，這種狀況在搶票系統是不能接受的，所以在這部份要維持一致性。但是在瀏覽有哪些不同活動的頁面，可用性就會比較重要，這時一致性就相對還好，因此在該子系統，就可以朝著優化可用性的方向設計。

更進一步說，在同一個系統中的不同面向，也可能有不同的策略。以上面提到的 ATM 例子來說，如果今天出現網路斷線，在領錢部分要確保一致性，但是存錢可能就不用。因為領錢時的餘額不一致，可能導致領的總額超出餘額，這對銀行來說後續要追討會很麻煩；但是存錢的話，兩邊有暫時的不一致，對銀行業務不會有太大的影響，只要等網路連接恢復後再同步即可，因此存錢就可以往高可用靠。

現實的系統不會是完美的

在用 CAP 思考時，要有個前提，那就是現實系統不會是完美的。舉例來說，即使網路沒有斷線，在資料的複製過程中，一定會有網路延遲，短則幾毫秒，長則幾十毫秒，因此在複製的過程中會有短暫的不一致問題，因此在某些情況下，是做不到完美的一致性，但我們仍會朝著盡可能一致性來設計。與此同時，假設在完美的狀況下 P 沒有發生，我們可以去思考，如何確保設計能保證 CA 被盡可能實現。

放棄並不等於什麼都不做

系統不會一直都處於錯誤的狀態，但錯誤還是有可能發生，因此需要為錯誤發生後要怎麼恢復來做準備，舉例來說，用戶管理系統一開始選擇了 CP ，當分區發生後，節點一可以註冊新帳戶，節點二無法註冊新帳戶（不滿足 A ），當分區發生故障時（ P 失效時），節點一會先將紀錄存在 Log 裡，分區恢復後再將資料同步到節點二。所以對於節點一而言，目前是 CA 狀態。