「系統架構」CAP 定理的含義

分布式系統（distributed system）正變得越來越重要，大型網站幾乎都是分布式的。

分布式系統的最大難點，就是各個節點的狀态如何同步。CAP 定理是這方面的基本定理，也是了解分布式系統的起點。

本文介紹該定理。它其實很好懂，而且是顯而易見的。下面的内容主要參考了 Michael Whittaker 的https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/

分布式系統的三個名額

1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統有三個名額。

1：Consistency

2：Availability

3：Partition tolerance

它們的第一個字母分别是 C、A、P。Eric Brewer 說，這三個名額不可能同時做到。這個結論就叫做 CAP 定理。

Partion tolerance

先看 Partition tolerance，中文叫做"分區容錯"。

大多數分布式系統都分布在多個子網絡。每個子網絡就叫做一個區（partition）。分區容錯的意思是，區間通信可能失敗。比如，一台伺服器放在中國，另一台伺服器放在美國，這就是兩個區，它們之間可能無法通信。

上圖中，G1 和 G2 是兩台跨區的伺服器。G1 向 G2 發送一條消息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。

一般來說，分區容錯無法避免，是以可以認為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。

Consistency

Consistency 中文叫做"一緻性"。意思是，寫操作之後的讀操作，必須傳回該值。舉例來說，某條記錄是 v0，使用者向 G1 發起一個寫操作，将其改為 v1。

接下來，使用者的讀操作就會得到 v1。這就叫一緻性。

問題是，使用者有可能向 G2 發起讀操作，由于 G2 的值沒有發生變化，是以傳回的是 v0。G1 和 G2 讀操作的結果不一緻，這就不滿足一緻性了。

為了讓 G2 也能變為 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改成 v1。

這樣的話，使用者向 G2 發起讀操作，也能得到 v1。

Availability

Availability 中文叫做"可用性"，意思是隻要收到使用者的請求，伺服器就必須給出回應。

使用者可以選擇向 G1 或 G2 發起讀操作。不管是哪台伺服器，隻要收到請求，就必須告訴使用者，到底是 v0 還是 v1，否則就不滿足可用性。

Consistency和Availability

一緻性和可用性，為什麼不可能同時成立？答案很簡單，因為可能通信失敗（即出現分區容錯）。

如果保證 G2 的一緻性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。隻有資料同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性不。

如果保證 G2 的可用性，那麼勢必不能鎖定 G2，是以一緻性不成立。

綜上所述，G2 無法同時做到一緻性和可用性。系統設計時隻能選擇一個目标。如果追求一緻性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一緻性。

讀者問，在什麼場合，可用性高于一緻性？

舉例來說，釋出一張網頁到 CDN，多個伺服器有這張網頁的副本。後來發現一個錯誤，需要更新網頁，這時隻能每個伺服器都更新一遍。

一般來說，網頁的更新不是特别強調一緻性。短時期内，一些使用者拿到老版本，另一些使用者拿到新版本，問題不會特别大。當然，所有人最終都會看到新版本。是以，這個場合就是可用性高于一緻性。

歡迎工作一到五年的Java工程師朋友們加入Java架構開發：744677563

本群提供免費的學習指導 架構資料 以及免費的解答

不懂得問題都可以在本群提出來 之後還會有職業生涯規劃以及面試指導