分布式CAP相關(guān)知識點有哪些

本篇內(nèi)容主要講解“分布式CAP相關(guān)知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“分布式CAP相關(guān)知識點有哪些”吧!

CAP的前世今生

1.1 起源

CAP理論，被戲稱為“帽子理論”，CAP是Eric Brewer在2000年ACM研討會上出了一個想法：“一致性、可用性和分區(qū)容錯性三者無法在分布式系統(tǒng)中被同時滿足，并且最多只能滿足其中兩個！”

2002年，Seth Gilbert和Nancy Lynch采用反正法證明了猜想：“如果三者可同時滿足，則因為允許P的存在，一定存在Server之間的丟包，如此則不能保證C?！?在該證明中，對CAP的定義進行了更明確的聲明。

C：一致性被稱為原子對象，任何的讀寫都應(yīng)該看起來是“原子”，或串行的。寫后面的讀一定能讀到前面寫的內(nèi)容，所有的讀寫請求都好像被全局排序。

A：對任何非失敗節(jié)點都應(yīng)該在有限時間內(nèi)給出請求的回應(yīng)。（請求的可終止性）

P：允許節(jié)點之間丟失任意多的消息，當網(wǎng)絡(luò)分區(qū)發(fā)生時，節(jié)點之間的消息可能會完全丟失。

但是只證明了CAP三者不可能同時滿足，并沒有證明任意二者都可滿足的問題；所以該證明被認為是一個收窄的結(jié)果，在之后10年里受到各種質(zhì)疑。

1.2 重新詮釋

2012年，Brewer和Lynch針對所有的質(zhì)疑進行了回應(yīng)，重新詮釋CAP。“3個中的2個”表述是不準確的，在某些分區(qū)極少發(fā)生的情況下，三者也能順暢地配合。CAP不僅僅是發(fā)生在整個系統(tǒng)中，可能是發(fā)生在某個子系統(tǒng)或系統(tǒng)的某個階段。把CAP理論的證明局限在原子讀寫的場景，并申明不支持數(shù)據(jù)庫事務(wù)之類的場景。一致性場景不會引入用戶agent，只是發(fā)生在后臺集群之內(nèi)。把分區(qū)容錯歸結(jié)為一個對網(wǎng)絡(luò)環(huán)境的陳述，而非之前一個獨立條件。引入了活(liveness)和安全屬性(safety)，在一個更抽象的概念下研究分布式系統(tǒng)，并認為CAP是活性與安全屬性之間權(quán)衡的一個特例。其中的一致性屬于liveness，可用性屬safety。

網(wǎng)絡(luò)存在同步、部分同步；一致性性的結(jié)果也從僅存在一個到存在N個（部分一致）；引入了通信周期round，保證N個一致性結(jié)果。

總結(jié)：縮小CAP適用的定義，消除質(zhì)疑的場景；展示了CAP在非單一一致性結(jié)果下的廣闊的研究結(jié)果。

CAP的分析

2.1 組成

Consistency：一致性

Availability：可用性

Partition tolerance：分區(qū)容忍性

2.2 Consistency

從論文上看：操作之后的讀操作，必須返回該值。

從百科上看：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。

總結(jié)：在分布式系統(tǒng)中，C代表任何人在任何地點、任何時間，訪問任何數(shù)據(jù) 結(jié)果都是一致的。

2.3 Availability

從論文上看：只要收到用戶的請求，服務(wù)器就必須給出回應(yīng)。

從百科上看：在集群中一部分節(jié)點故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。

總結(jié)：在分布式系統(tǒng)中，A代表服務(wù)在任何時候都要是可用的、可訪問。

2.4 Partition tolerance

從論文上看：直譯叫“分區(qū)容錯”，意思是區(qū)間通信可能失敗。

從百科上看：分區(qū)相當于對通信的時限要求。

總結(jié)：分區(qū)容錯=分區(qū)+容錯。分布式系統(tǒng)因為多實例部署，面臨多個子網(wǎng)絡(luò)，多個子網(wǎng)絡(luò)存在網(wǎng)絡(luò)通訊的需求；因為網(wǎng)絡(luò)通訊的不可靠性造成分區(qū)的存在。而分區(qū)的存在，不可避免出現(xiàn)數(shù)據(jù)和可用性問題，需要有容錯機制來處理。

 實踐分析

3.1 A與P的差異

從上述的描述中，因為兩者都有容錯可用的描述，我們很容易將A 跟 P 混淆在一起。接下去，咱們從各個維度去分析C 與P的差異。

1、從關(guān)注點來說，A關(guān)注的是用戶對分布式系統(tǒng)的可用要求；P關(guān)注的是分布式系統(tǒng)實例間的網(wǎng)絡(luò)連通性。

2、從要求上來看，A從外部的視角，要求分布式系統(tǒng)在正常響應(yīng)時間內(nèi)一直可用；P從實例節(jié)點的視角出發(fā)，在遇到某節(jié)點或節(jié)點間通信故障的時候，要求分布式系統(tǒng)整體對節(jié)點的容錯及恢復(fù)性。

3、從受眾上分析，A針對的是用戶，P針對的是服務(wù)實例。

3.2 CP與AP

三者的組合，產(chǎn)生了AC、AP、CP三個組合。但在分布式環(huán)境中，多實例部署是基本條件，因為網(wǎng)絡(luò)的不可靠性，造成了P成了硬性條件。所以結(jié)果就轉(zhuǎn)化成了CP、AP兩個分支。

CP、AP分支代表的是硬性條件，在這個基礎(chǔ)上去追求利益化才是這個分支的本質(zhì)問題。如果是粗暴的對另外一個選項直接放棄，那這個世界就太simple、easy了，而且也不符合咱們對系統(tǒng)的期望和基本使用。這就是2012年重新詮釋后CAP的最終狀態(tài)意義，“三選二”是一個偽命題。

基于這個2012年CAP的最終意義，咱們發(fā)現(xiàn)CP不是簡單的放棄A，而是保障CP的硬性條件去追求A。所以產(chǎn)生了過半寫入這樣非常經(jīng)典的使用方式:過半寫入后，分布式節(jié)點可以根據(jù)少數(shù)服從多數(shù)完成數(shù)據(jù)的一致性要求。因此產(chǎn)生了最大的效益

1、分布式實例的更高可用性，對所有實例不在全部寫入成功才認為是成功。

2、分布式實例的更快響應(yīng)性，使用廣播快速獲取過半結(jié)果后直接認定結(jié)果。依靠補充手段實現(xiàn)數(shù)據(jù)的一致性。

說完CP的改變，再說說AP的對應(yīng)調(diào)整升級。咱們?yōu)榱烁呖捎梅艞墧?shù)據(jù)的一致性，其實這個說法是不嚴謹，也是錯誤的。數(shù)據(jù)一致性是系統(tǒng)的基本要求。那么要怎么理解AP，應(yīng)該從臟讀、幻讀來說，場景允許數(shù)據(jù)的短暫不一致，接受數(shù)據(jù)的最終一致性。

1、數(shù)據(jù)的嚴謹性是系統(tǒng)的一個要求，但允許數(shù)據(jù)的一定延遲是AP存在的意義。

2、系統(tǒng)的高可用可以滿足更多的群體，從這個的目標上，所以AP是比較友好的

因為分布式系統(tǒng)，系統(tǒng)是多層面的組合型存在，所以我們并不會說一個系統(tǒng)是AP還是CP。我們是根據(jù)系統(tǒng)的業(yè)務(wù)場景去選擇CP和AP，但是高可用是互聯(lián)網(wǎng)分布式應(yīng)用的特性，所以我們絕大部分情況是追求AP，盡量讓系統(tǒng)滿足更多的用戶。然后基于某些場景數(shù)據(jù)的強一致性必要性去選擇CP。

總結(jié)

在分布式環(huán)境下，對cap的要求。不管cp 還是ap，并不是完全丟棄另一個，而是優(yōu)先級問題；在滿足C或者A的基礎(chǔ)上去追求另外一個，結(jié)論如下：

1、CP--在強一致性的底線上追求可用性 (案例-過半寫入)。

2、AP—在高可用的基礎(chǔ)上追求數(shù)據(jù)的一致性(案例-最終一致性)。

3、系統(tǒng)以AP為基調(diào)，在一些數(shù)據(jù)高即時、一致性場景使用CP進行補充。

到此，相信大家對“分布式CAP相關(guān)知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！