2022
Mar
05
CAP 定理是指一個分散式系統 storage ,三個功能 Consistency / Availability / Partition Tolerance 只能滿足其中的兩項,不可能同時滿足全部。
這個定理只存在分散式系統,也就是你的機器數必須大於 1 ,且組成一個機器群,這一群機器之間會互相通訊,並同步資料。

下面文章將使用 Node 代稱機器。

C: Consistency , 所有的 Nodes 資料必須一致
A: Availability ,Always Success 所有的 Request 都能得到成功且正確的 Response ,不能 Timeout 或是 Error
P: Partition Tolerance,容錯,當 Nodes 之間的網路發生問題,所有 Nodes 仍然可以運作。

這個定理告訴我們只能滿足 CP or AP or CA 三取二,無法同時滿足網路有問題的情況下保證資料一致且得到成功的 Response, 而 CA 沒有 P 代表非分散式系統,不是 CAP 討論的範圍, CA 只有一個 Node ,討論 CA 也沒什麼意義。


滿足 CP 的情況


CP 是指網路有問題的情況下,維持資料一致性,但不保證成功得到 Response ,也就是 User 可能會拿到一個 Error,從圖中可以看出來 Node A 的資料已從 10 更新為 20 ,但因為網路斷掉無法將這個 update 傳送給 Node B,Node B 在不知道資料已更新的情況下,這時可以回傳 10 或 Error,如果回傳 10 就代表資料不一致,不滿足 Consistency 這個條件,最終 Node B 只能回傳 Error。

滿足 AP 的情況

AP 是指網路有問題的情況下,可以成功得到 Response ,但不保證資料是最新的,也就是 User 可能會拿到一個過期的資料,從圖中可以看出來 Node A 的資料已從 10 更新為 20 ,但因為網路斷掉無法將這個 update 傳送給 Node B,Node B 在不知道資料已更新的情況下,還是回傳舊的數值 10。


什麼時候要選用 CP 呢

如果你要開發一個購物系統,有商品資料庫及它的庫存量,若是庫存量的 Storage 選用 AP 會發生什麼事呢? 假設我的商品庫存量是 5 ,有 3 個人同時購買了這個商品,又剛好購買的當下 Node 間的網路出現狀況。

- 第一個人成功購買,Node A 庫存量 5 - 1 剩餘 4
- 第二個人也成功購買,但因為網路問題 Node B 的庫存量還是 5, 5 - 1 剩餘 4
- 第三個人也成功購買,Node A 的庫存量 4 - 1 剩餘 3
這個情況下 Node A 庫存量是 3 , Node B 庫存量是 4 ,數據是不一致, 而且總共賣出了 3 件(超賣一件),為了避免發生超賣的問題,購物系統 Storage 最好要選擇 CP 。

各種 Storage CAP

- CA: Memcached
- CP: Redis / MongoDB
- AP: Dynamodb / Cassandra / Vespa-engine
- MySQL: master CA , slave AP

回應 (Leave a comment)