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