过时的CAP理论
文章目錄
- 1. CAP簡介
- 2. CAP詳情
- 1. Consistency, 一致性
- 2. Availability
- 3. Partition tolerance
- 3. 再談CAP
- 參考
1. CAP簡介
這里主要是學習一下分布式系統的基礎理論CAP理論,這個理論在之前被認為是理解CAP系統的起點，CAP理論認為對于一個分布式系統，存在以下3個不能同時滿足的指標
- Consistency
- Availability
- Partition tolerance
CAP實際上是取了三個的首字母構成，CAP理論認為分布式系統最多能夠滿足三個指標中的兩個（實際上這個描述是有問題的，下面會聊到）
2. CAP詳情
我們可以假想一下我們的分布式系統有三個節點，假如我們的集群有三個節點（node01,node02,node03）
node01在美國
node02在中國
node03在日本
同時有兩個個client ,client01,client02
每個數據都有都有三個副本,也就是說數據在每個節點上都有一個副本
1. Consistency, 一致性
這里的分布式的一致性理解都來源于《數據密集型系統設計一文》和raft的相關論文，
這里的一致性意味著server端對于client端具備線性化的一致性，這里面有幾個含義：
線性一致性（linearizability）,（也稱為原子一致性（atomic consistency），強一致性（strong consistency），立即一致性（immediate consistency）或外部一致性（external consistency ））。線性一致性的精確定義相當微妙,但是基本的想法是讓一個系統看起來好像只有一個數據副本，而且所有的操作都是原子性的。有了這個保證，即使實際中可能有多個副本，應用也不需要擔心它們。
在raft當中是這樣描述的
Our goal for Raft is to implement linearizable semantics (each operation appears to execute instantaneously, exactly once, at some point between its invocation and its response)也就是每個client請求的操作執行都可以被看做一個瞬時態，這個瞬時態必須處在在client的請求發起到請求返回之間。
這里包含的有多個意思,對這些意思的理解參考了《數據密集型系統設計》一文
client的請求一般包括兩類，write(寫)和read(讀)
瞬時態意味著當前操作的過程對其他操作不可見（就像事務之間的隔離性一樣,是一個原子操作，可以類比對寄存器的操作），如果client01在發起了一次write操作log01,那么在client01發起request和獲得到response之間（因為存在網絡延遲，所以應該說在在server端處理完client01的這個請求之前），這個log01對client02是不可見的，不管client02怎么請求都不能得到值log01。
在write操作返回成功的response之后（因為存在網絡延遲，所以應該說在在server端處理完client01的這個請求之后），這個數據對當前client后續的操作（在時間維度上的后續）就是可見的了
如果服務端對client01的某一次read請求返回了最新的值，那么服務端會對后續（在時間維度上的后續）任何client的請求返回最新值
返回沒有成功寫入，那么這個數據對后續也是不可見的
假如服務端超時，這個時候其實是不知道server端對這個請求是完成了還是拒絕了，理論上需要使用一次查詢請求來看看是否成功了(服務超時一般是網絡丟包或者是服務端出現了master宕機導致)
2. Availability
某個副本即使與其他副本斷開連接，也可以獨立處理請求（例如多主復制）。在這種情況下，應用可以在網絡問題前保持可用，但其行為不是線性一致的,也就是說當你想要A的時候C就已經無法保證了。
3. Partition tolerance
這分區容忍性實際上是必須做的，因為網絡分區是必然發生的
3. 再談CAP
??之前理解CAP的時候，總是覺得過于晦澀，雖然網上相關的資料博客千千萬，但是理解起來很別扭，尤其是分區容忍性這一塊兒，什么叫分區容忍性，比如如果一個系統選擇了CA，那么發生了網絡分區，他怎么辦，繼續工作的話肯定無法滿足Consistency, 返回失敗的話肯定就無法滿足Avaliablity。而網絡上的各種資料更多的介紹都是CAP三個指標我們只能選兩個，如果按照這個邏輯來說的話,這個CAP的應該是CA理論才對。因為網絡故障是必然發生的而不是你選擇有沒有網絡故障發生。
??每次看這個理論都看得很痛苦，終于從**《設計數據密集型系統》**這本書中找到了答案，而且也印證了我的想法是正確的。
CAP最初是作為一個經驗法則提出的，沒有準確的定義，目的是開始討論數據庫的權衡。那時候許多分布式數據庫側重于在共享存儲的集群上提供線性一致性的語義，CAP定理鼓勵數據庫工程師向分布式無共享系統的設計領域深入探索，這類架構更適合實現大規模的網絡服務。 對于這種文化上的轉變，CAP值得贊揚 —— 它見證了自00年代中期以來新數據庫的技術爆炸（即NoSQL）。
CAP定理沒有幫助
CAP有時以這種面目出現：一致性，可用性和分區容錯性：三者只能擇其二。不幸的是這種說法很有誤導性，因為網絡分區是一種錯誤，所以它并不是一個選項：不管你喜不喜歡它都會發生。
在網絡正常工作的時候，系統可以提供一致性（線性一致性）和整體可用性。發生網絡故障時，你必須在線性一致性和整體可用性之間做出選擇。因此，CAP更好的表述成：在分區時要么選擇一致，要么選擇可用。一個更可靠的網絡需要減少這個選擇，但是在某些時候選擇是不可避免的。
在CAP的討論中，術語可用性有幾個相互矛盾的定義，形式化作為一個定理不符合其通常的含義。許多所謂的“高可用”（容錯）系統實際上不符合CAP對可用性的特殊定義?？偠灾?#xff0c;圍繞著CAP有很多誤解和困惑，并不能幫助我們更好地理解系統，所以最好避免使用CAP。
CAP定理的正式定義僅限于很狹隘的范圍，它只考慮了一個一致性模型（即線性一致性）和一種故障（網絡分區，或活躍但彼此斷開的節點）。它沒有討論任何關于網絡延遲，死亡節點或其他權衡的事。 因此，盡管CAP在歷史上有一些影響力，但對于設計系統而言并沒有實際價值。
在分布式系統中有更多有趣的“不可能”的結果，且CAP定理現在已經被更精確的結果取代，所以它現在基本上成了歷史古跡了。
比如CAC理論
參考
https://zhuanlan.zhihu.com/p/42239873?utm_source=wechat_timeline&utm_medium=social&from=timeline&isappinstalled=0
https://zhuanlan.zhihu.com/p/47025699
總結
- 上一篇： es最新的集群选举策略
- 下一篇： 线性一致性理解Linearizabili