只有 系統 達到一定的體量，就不得不面臨分布式的問題，分布式系統的最大難點，就是各個節點的狀態如何同步。 CAP 定理就是這方面的基本定理，由加州大學的計算機科學家 Eric Brewer 于 1998 年提出。
定理的主要內容
Eric Brewer 認為 分布式系統有三個指標
- C : Consistency 一致性
- A : Availability 可用性
- P : Partition tolerance 分區容錯性 并且 Eric Brewer 認為這三個指標不可能同時做到！ 這個結論就叫做 CAP 定理 。
我們先來看下這三個指標是什么意思
Partition tolerance
Partition tolerance 直譯 分區容錯性， 我們將 Partition tolerance 拆開來理解。
Partition(分區)： 分布式、分布式，系統分部在不同的地方才叫分布式， Eric Brewer 將"系統分部在不同的地方"這個概念取了個名字叫 Partition(分區) ,這就是分區的含義。
tolerance(容錯): 既然分布式一定是 Partition(分區) 的，那么就會帶來一個問題，不同區域之間通信會有延遲甚至是失敗。比如一臺服務器在 齊齊哈爾 一臺服務器在 上海長距離通信可能導致超時或失敗
總的來理解，就是 分布式系統的不同分區之間會產生“隔閡”
通常來講一個分布式系統一定(有“隔閡”)滿足 Partition tolerance(分區容錯性)
Consistency
Consistency 中文叫做"一致性"
假設有如下分布式系統
G1、G2 是同一個服務的兩個實例，分部在不同的區域
- 客戶端發送一個請求被網關轉發到 G1 上，將 G1 的 u0 改為了 u1
- 客戶端想查看修改結果，于是又發送一個請求，這次被網關轉發到 G2 上，結果發現還是 u0
上面的例子值在 G1 上是 u1, 在 G2 上是 u0，就不符合 Consistency(一致性)
那么樣才能滿足 Consistency(一致性) 呢，可以讓 G1 和 G2 同步
如圖，G1 發生變化后同步到 G2， 這樣 G1 和 G2 就一樣了。
但問題并沒有解決，上一章我們講到 分布式系統的不同分區之間會產生“隔閡” ，這意味著 同步不是瞬間完成 的而是有個過程的，甚至可能還會失敗。假如在同步過程中，client 訪問 G2 得到還是 u0
怎么解決這個問題呢？
答案是，在同步完成之前，不讓 G2 對外提供服務，同步完成之后，在對外提供服務
經過上面的一系列操作，終于完成了 Consistency(一致性)
Availability
Availability 中文叫做"可用性" ，顧名思義指的是 分布式系統中，服務必須可以使用(訪問)。
這一點實現起來比較簡單，只有你的服務不掛，并且對外提供服務就可以了。
Consistency 和 Availability 難以共存
Consistency 那節提到，為了保證同步過程中的數據一致，我們讓G2不對外提供服務。此時 G2就處于 不可用 狀態。 不滿足 Availability(可用性) 的條件。
但是我們如果不這么做，有無法保證 Consistency(一致性)
因此說 Consistency 和 Availability 難以共存
Consistency 和 Availability 難以共存的根本原因
Consistency 和 Availability 難以共存的根本原因是因為 Partition tolerance(分區容錯性)
回到 Consistency 那一小節，我們為什么要讓 G2 停止對外提供服務，是因為 同步需要一個過程 。 哪為什么 同步需要一個過程 呢？是因為 分布式系統的不同分區之間會產生“隔閡”，相互通信可能會有延遲或失敗。
等哪一天，通信技術發達了從中國到美國也能做的通信0延遲，分布式系統的不同分區之間就不會產生“隔閡”了。分區之前同步瞬間完成，我們也不需要讓 G2 對外停止服務了。**Consistency 和 Availability ** 就可以共存！
