1. CAP理論的歷史 2000年7月，Eric Brewer教授提出CAP猜想；2年後，Seth Gilbert和Nancy Lynch從理論上證明瞭CAP；之後，CAP理論正式成為分散式計算領域的公認定理。 2. CAP的背景和定義 CAP理論討論的對象是分散式場景。一個分散式系統需要滿足三個最 ...
1. CAP理論的歷史
2000年7月，Eric Brewer教授提出CAP猜想；2年後，Seth Gilbert和Nancy Lynch從理論上證明瞭CAP；之後，CAP理論正式成為分散式計算領域的公認定理。
2. CAP的背景和定義
CAP理論討論的對象是分散式場景。一個分散式系統需要滿足三個最基本的特性，分別是一致性（Consistency）、可用性（Availability）和分區容錯性（Partition Tolerance，這個中文翻譯很不直觀，沒能體現Partition原來的意思，這也人為拉高了理解成本，至少對以前的我是這樣，後面會單獨介紹）。CAP理論的簡單解釋就是，不可能存在一個完美的分散式架構，能同時滿足這三個特性。架構師們不要試圖花精力去設計一個“完美”的架構來滿足這三個特性，而是應該因地制宜，根據實際的需求在CAP之間做權衡。
這裡也只是從字面意思對CAP做了個翻譯，並不便於理解，下麵結合一個具體的例子來說明。
下圖是一個假想的最小（典型的）分散式應用場景：
- 兩台伺服器Node1, Node2（在分散式環境中，習慣叫節點）構成一個服務集群，對外提供服務
- 客戶Client可以隨機訪問任何一臺伺服器上的服務
- 兩台伺服器內部之間也可以互相訪問
這個簡單的分散式系統需要滿足哪些特性才算得上是一個比較好的系統（產品）呢？思考以下幾個場景：
客戶訪問Node1時寫入了一個數據（比如往賬戶存了100元），當客戶要讀取該值時又隨機訪問了Node2，系統需要保證Node2也能夠返回正確的值，這個就是所謂的一致性要求（Consistency）。
一致性的權威解釋如下（來自證明CAP理論的原作者）：
Consistency
any read operation that begins after a write operation completes must return that value, or the result of a later write operation
當客戶訪問某個節點時，如果該節點正常工作，系統需要保證該節點必須要給客戶一個響應（可以是錯誤的響應，也可以有一定的延遲，但是不能沒有響應），也就是說任何時刻必須保證請求能得到響應，這就是系統的可用性要求（Availability）
Availability
every request received by a non-failing node in the system must result in a response
在分散式環境中，每個節點都不是可靠的，各節點之間的通信也可能出問題。當某些節點出現故障（或者節點本身的故障，或者部分網路故障）時，整個系統就產生了所謂的”分區“。當系統產生”分區“的時候，如果還能對外提供比較好的服務（例如較好的一致性和可用性），就可以說該系統具有較好的”分區容錯性“（Partition Tolerance）。
如果對分區還不好理解的話，看看partition的英文解釋吧：
(n.) a wall or screen that separate one part of a room from another
(v.) to separate one area, one part of a room, etc. from another with a wall or screen
就是分割、隔離的意思，也就是說因為某些原因，部分節點被隔離到集群之外的時候，整個系統還能夠正常工作，對外表現得就像沒事兒一樣。
Partition Tolerance
the network will be allowed to lose arbitrarily many messages sent from one node to another
3. CAP為什麼不能同時滿足
有興趣深入瞭解的同學，可以在這裡看原始的證明：
https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
淺顯易懂點的，可以參考這篇文章：
https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/
再簡單點的解釋就是這樣，考慮下麵的一個場景：
Client寫入數據到Node1；Node2出現分區導致Node1的數據沒有同步到Node2；Client訪問Node2讀取數據
- 同時滿足AP：系統保證在Node2出現分區的情況下，還能立即返回結果給Client。但此時Node2還沒有同步到Node1的數據，所以沒法保證數據的一致性
- 同時滿足CP：系統保證在Node2出現分區的情況下，能返回一致的結果給Client。這個只能等到Node2正確同步到Node1的數據之後才能返回（有可能永遠同步不了），因此不能立即返回（也可能永遠無法返回），也就失去了可用性
- 同時滿足CA：Node2能保證返回準確一致的數據給到Client，但考慮到這是一個分散式系統，是沒法保證每個節點都能正常工作不產生分區的（雖然集群的所有節點同時出現故障的概率非常低，但是單個節點出現故障的概率還是比較高的）
4. CAP理論在現實中的應用
既然理論是這樣，我們就不要浪費時間去設計完美的分散式系統，這就是方法論起的作用。
考慮到在分散式場景中，系統產生分區的情況無法避免，我們就只能儘量提供一個比較好的”分區容錯性“的產品。換句話說，我們需要在系統出現分區的時候，在一致性和可用性之間做權衡。
CP：優先保證數據的一致性，在數據沒有一致的情況下，可以適當降低系統的可用性，比如放棄當前的請求，讓客戶端重試；或者降低對客戶端的響應速度（比如銀行轉賬結束時等待5s的提示界面）。ZooKeeper被設計為在分散式系統中協調服務、保證各服務節點數據一致的產品，就是CP的例子。還有各種分散式資料庫產品，如Redis、HBase，也都是偏向數據一致性的CP的例子。
AP：優先保證系統的可用性，降低數據的一致性訴求。比如電商網站的下單界面展示的可購買數量，這個是時時變化的。如果要保證一致性，則需要系統時時刷新獲取最新的數據，勢必會影響網站的響應速度，也就降低了可用性，影響用戶體驗（可以改為在真正下單的那一刻再提示庫存是否滿足下單條件）。
實際上，隨著基礎設施越來越完善，分散式系統中出現P的情況也可以控制的越來越精細。在不用特別擔心P的情況下，系統在大多數情況下是可以做到完美的C和A的，具體可參考原作者的另外一篇文章（強烈推薦）：CAP 理論十二年回顧："規則"變了
中文版：https://www.infoq.cn/article/cap-twelve-years-later-how-the-rules-have-changed
英文版：https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
