分佈式系統中的 CAP 定理

只有 系統 達到必定的體量，就不得不面臨分佈式的問題，分佈式系統的最大難點，就是各個節點的狀態如何同步。 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 中文叫作"一致性"

假設有以下分佈式系統

G一、G2 是同一個服務的兩個實例，分部在不一樣的區域

1. 客戶端發送一個請求被網關轉發到 G1 上，將 G1 的 u0 改成了 u1
2. 客戶端想查看修改結果，因而又發送一個請求，此次被網關轉發到 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 ** 就能夠共存！

參考

• CAP 定理的含義