目前只要是大型互聯網專案都是采用分布式結構，一個系統可能有多個節點組成，每個節點都可能需要維護一份資料，那么如何維護各個節點之間的狀態，如何保障各個節點之間資料的同步問題就是大家急需關注的事情了，CAP定理是分布式系統中最基礎的原則，所以理解和掌握了CAP，對系統架構的設計至關重要，
分布式系統的三個指標
1998年，加州大學的計算機科學家Eric Brewer 提出，分布式系統有三個指標
Consistency：一致性Availability：可用性Partition tolerance：磁區容錯性
它們的第一個字母分別是CAP，Eric Brewer 說，這三個指標不可能同時做到，這個結論就叫做CAP定理又被稱為布魯爾定理，
下面我們將分別講解cap定理的每個字母的含義 👇
文章目錄
- 分布式系統的三個指標
- C.一致性
- A.可用性
- P.磁區容錯性
- 三指標不可能同時滿足
- CAP三者如何權衡
C.一致性
Consistency 中文叫做 一致性（這里指的是強一致性）所有節點訪問同一份最新的資料副本，也就是說，在一致性系統中，一旦客戶端將值寫入任何一臺服務器并獲得回應，那么之后client從其他任何服務器讀取的都是剛寫入的資料！
舉個例子?
某條記錄是v0，用戶（client）向G1發起一個寫操作，將其改為v1，
接下來，用戶（client）的讀操作就會得到v1，這就叫一致性，
問題是，用戶（client）有可能向 G2 發起讀操作，由于 G2 的值沒有發生變化，因此回傳的是 v0，G1 和 G2 讀操作的結果不一致，這就不滿足一致性了，
為了讓 G2 也能變為 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 發送一條訊息，要求 G2 也改成 v1，
這樣的話，用戶向 G2 發起讀操作，也能得到 v1，
A.可用性
Availability 中文叫做 可用性，意思是系統中非故障節點只要收到用戶的請求，服務器就必須給出回應，稍詳細點說就是在可用系統中，如果我們的客戶端向服務器發送請求，并且服務器未崩潰，則服務器必須最終回應客戶端，不允許服務器忽略客戶的請求！
用戶可以選擇向 G1 或 G2 發起讀操作，不管是哪臺服務器，只要收到請求，就必須告訴用戶，到底是 v0 還是 v1，否則就不滿足可用性，
P.磁區容錯性
Partition tolerance 中文叫做 磁區容錯，大多數分布式系統都分布在多個子網路，每個子網路就叫做一個區（partition），磁區容錯的意思是，區間通信可能失敗，分布式系統要能容忍這種情況，
比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信，
上圖中，G1和G2是兩臺跨區的服務器，G1 向 G2 發送一條訊息，G2 可能無法收到，系統設計的時候，必須考慮到這種情況，
一般來說，磁區容錯無法避免，因此可以認為CAP的P總是成立，CAP定理告訴我們，剩下的C和A無法同時做到，
三指標不可能同時滿足
為什么同時滿足呢？我們通過下方例子進行說明，
假設確實存在三者能同時滿足的系統
那么我們要做的第一件事就是磁區我們的系統，由于滿足磁區容錯性，也就是說可能因為通信不佳等情況，G1和G2之間是沒有同步!
接下來，我們的客戶端將v1寫入G1，但G1和G2之間是不同步的，所以如下G1是v1資料，G2是v0資料，
由于要滿足可用性，即一定要回傳資料，所以G1必須在資料沒有同步給G2的前提下回傳資料給client，
client請求的是G2服務器，由于G2服務器的資料是v0，所以client得到的資料是v0
很明顯，G1回傳的是v1資料，G2回傳的是v0資料，兩者不一致無法同時滿足我們的cap定理，
CAP三者如何權衡
- CA (Consistency + Availability)
關注一致性和可用性，它需要非常嚴格的全體一致的協議，比如“兩階段提交”（2PC），CA 系統不能容忍網路錯誤或節點錯誤，一旦出現這樣的問題，整個系統就會拒絕寫請求，因為它并不知道對面的那個結點是否掛掉了，還是只是網路問題，唯一安全的做法就是把自己變成只讀的，
- CP (consistency + partition tolerance)
關注一致性和磁區容忍性，它關注的是系統里大多數人的一致性協議，比如：Paxos 演算法 (Quorum 類的演算法)，這樣的系統只需要保證大多數結點資料一致，而少數的結點會在沒有同步到最新版本的資料時變成不可用的狀態，這樣能夠提供一部分的可用性，
- AP (availability + partition tolerance)
這樣的系統關心可用性和磁區容忍性，因此，這樣的系統不能達成一致性，需要給出資料沖突，給出資料沖突就需要維護資料版本，Dynamo 就是這樣的系統，
最終的選擇的關鍵點還是要取決于業務場景
對于大多數互聯網應用來說（如網易門戶），因為機器數量龐大，部署節點分散，網路故障是常態，可用性是必須需要保證的，所以只有設定一致性來保證服務的AP，
對于需要確保強一致性的場景，如銀行，通常會權衡CA和CP模型，CA模型網路故障時完全不可用，CP模型具備部分可用性，實際的選擇需要通過業務場景來權衡（并不是所有情況CP都好于CA，只能查看資訊不能更新資訊有時候從產品層面還不如直接拒絕服務）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423612.html
標籤：其他
上一篇：跳槽? 我只想多賺點罷了