文章目錄

• • 1. CAP簡介
  • 2. CAP詳情
  • • 1. Consistency, 一致性
    • 2. Availability
    • 3. Partition tolerance
  • 3. 再談CAP
  • 參考

1. CAP簡介

這里主要是學(xué)習(xí)一下分布式系統(tǒng)的基礎(chǔ)理論CAP理論,這個理論在之前被認(rèn)為是理解CAP系統(tǒng)的起點，CAP理論認(rèn)為對于一個分布式系統(tǒng)，存在以下3個不能同時滿足的指標(biāo)

• Consistency
• Availability
• Partition tolerance

CAP實際上是取了三個的首字母構(gòu)成，CAP理論認(rèn)為分布式系統(tǒng)最多能夠滿足三個指標(biāo)中的兩個（實際上這個描述是有問題的，下面會聊到）

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)設(shè)計一文》和raft的相關(guān)論文，
這里的一致性意味著server端對于client端具備線性化的一致性，這里面有幾個含義：

線性一致性（linearizability）,（也稱為原子一致性（atomic consistency），強一致性（strong consistency），立即一致性（immediate consistency）或外部一致性（external consistency ））。線性一致性的精確定義相當(dāng)微妙,但是基本的想法是讓一個系統(tǒng)看起來好像只有一個數(shù)據(jù)副本，而且所有的操作都是原子性的。有了這個保證，即使實際中可能有多個副本，應(yīng)用也不需要擔(dān)心它們。

在raft當(dāng)中是這樣描述的

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)設(shè)計》一文
client的請求一般包括兩類，write(寫)和read(讀)

瞬時態(tài)意味著當(dāng)前操作的過程對其他操作不可見（就像事務(wù)之間的隔離性一樣,是一個原子操作，可以類比對寄存器的操作），如果client01在發(fā)起了一次write操作log01,那么在client01發(fā)起request和獲得到response之間（因為存在網(wǎng)絡(luò)延遲，所以應(yīng)該說在在server端處理完client01的這個請求之前），這個log01對client02是不可見的，不管client02怎么請求都不能得到值log01。

在write操作返回成功的response之后（因為存在網(wǎng)絡(luò)延遲，所以應(yīng)該說在在server端處理完client01的這個請求之后），這個數(shù)據(jù)對當(dāng)前client后續(xù)的操作（在時間維度上的后續(xù)）就是可見的了

如果服務(wù)端對client01的某一次read請求返回了最新的值，那么服務(wù)端會對后續(xù)（在時間維度上的后續(xù)）任何client的請求返回最新值

返回沒有成功寫入，那么這個數(shù)據(jù)對后續(xù)也是不可見的

假如服務(wù)端超時，這個時候其實是不知道server端對這個請求是完成了還是拒絕了，理論上需要使用一次查詢請求來看看是否成功了(服務(wù)超時一般是網(wǎng)絡(luò)丟包或者是服務(wù)端出現(xiàn)了master宕機導(dǎo)致)

2. Availability

某個副本即使與其他副本斷開連接，也可以獨立處理請求（例如多主復(fù)制）。在這種情況下，應(yīng)用可以在網(wǎng)絡(luò)問題前保持可用，但其行為不是線性一致的,也就是說當(dāng)你想要A的時候C就已經(jīng)無法保證了。

3. Partition tolerance

這分區(qū)容忍性實際上是必須做的，因為網(wǎng)絡(luò)分區(qū)是必然發(fā)生的

3. 再談CAP

??之前理解CAP的時候，總是覺得過于晦澀，雖然網(wǎng)上相關(guān)的資料博客千千萬，但是理解起來很別扭，尤其是分區(qū)容忍性這一塊兒，什么叫分區(qū)容忍性，比如如果一個系統(tǒng)選擇了CA，那么發(fā)生了網(wǎng)絡(luò)分區(qū)，他怎么辦，繼續(xù)工作的話肯定無法滿足Consistency, 返回失敗的話肯定就無法滿足Avaliablity。而網(wǎng)絡(luò)上的各種資料更多的介紹都是CAP三個指標(biāo)我們只能選兩個，如果按照這個邏輯來說的話,這個CAP的應(yīng)該是CA理論才對。因為網(wǎng)絡(luò)故障是必然發(fā)生的而不是你選擇有沒有網(wǎng)絡(luò)故障發(fā)生。
??每次看這個理論都看得很痛苦，終于從**《設(shè)計數(shù)據(jù)密集型系統(tǒng)》**這本書中找到了答案，而且也印證了我的想法是正確的。

CAP最初是作為一個經(jīng)驗法則提出的，沒有準(zhǔn)確的定義，目的是開始討論數(shù)據(jù)庫的權(quán)衡。那時候許多分布式數(shù)據(jù)庫側(cè)重于在共享存儲的集群上提供線性一致性的語義，CAP定理鼓勵數(shù)據(jù)庫工程師向分布式無共享系統(tǒng)的設(shè)計領(lǐng)域深入探索，這類架構(gòu)更適合實現(xiàn)大規(guī)模的網(wǎng)絡(luò)服務(wù)。 對于這種文化上的轉(zhuǎn)變，CAP值得贊揚 —— 它見證了自00年代中期以來新數(shù)據(jù)庫的技術(shù)爆炸（即NoSQL）。

CAP定理沒有幫助
CAP有時以這種面目出現(xiàn)：一致性，可用性和分區(qū)容錯性：三者只能擇其二。不幸的是這種說法很有誤導(dǎo)性，因為網(wǎng)絡(luò)分區(qū)是一種錯誤，所以它并不是一個選項：不管你喜不喜歡它都會發(fā)生。
在網(wǎng)絡(luò)正常工作的時候，系統(tǒng)可以提供一致性（線性一致性）和整體可用性。發(fā)生網(wǎng)絡(luò)故障時，你必須在線性一致性和整體可用性之間做出選擇。因此，CAP更好的表述成：在分區(qū)時要么選擇一致，要么選擇可用。一個更可靠的網(wǎng)絡(luò)需要減少這個選擇，但是在某些時候選擇是不可避免的。

在CAP的討論中，術(shù)語可用性有幾個相互矛盾的定義，形式化作為一個定理不符合其通常的含義。許多所謂的“高可用”（容錯）系統(tǒng)實際上不符合CAP對可用性的特殊定義。總而言之，圍繞著CAP有很多誤解和困惑，并不能幫助我們更好地理解系統(tǒng)，所以最好避免使用CAP。

CAP定理的正式定義僅限于很狹隘的范圍，它只考慮了一個一致性模型（即線性一致性）和一種故障（網(wǎng)絡(luò)分區(qū)，或活躍但彼此斷開的節(jié)點）。它沒有討論任何關(guān)于網(wǎng)絡(luò)延遲，死亡節(jié)點或其他權(quán)衡的事。 因此，盡管CAP在歷史上有一些影響力，但對于設(shè)計系統(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é)

以上是生活随笔為你收集整理的过时的CAP理论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。