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

java填坑路發表於2018-08-01

分散式系統(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

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

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


相關文章