在計算機(jī)領(lǐng)域,如果是初入行就算了,如果是多年的老碼農(nóng)還不懂 CAP 定理,那就真的說不過去了。CAP可是每一名技術(shù)架構(gòu)師都必須掌握的基礎(chǔ)原則啊。
現(xiàn)在只要是稍微大一點(diǎn)的互聯(lián)網(wǎng)項(xiàng)目都是采用 分布式 結(jié)構(gòu)了,一個系統(tǒng)可能有多個節(jié)點(diǎn)組成,每個節(jié)點(diǎn)都可能需要維護(hù)一份數(shù)據(jù)。那么如何維護(hù)各個節(jié)點(diǎn)之間的狀態(tài),如何保障各個節(jié)點(diǎn)之間數(shù)據(jù)的同步問題就是大家急需關(guān)注的事情了。
CAP定理是分布式系統(tǒng)中最基礎(chǔ)的原則。所以理解和掌握了CAP,對系統(tǒng)架構(gòu)的設(shè)計至關(guān)重要。
一、什么是 CAP?
「 CAP定理 」又被稱為 布魯爾定理,它提出對于一個分布式系統(tǒng)而言,不能同時滿足以下三點(diǎn):
Consisteny(一致性)
Availability(可用性)
Partition tolerance(分區(qū)容錯性)
也就是說CAP定理指明了,任何分布式系統(tǒng)只能同時滿足這三項(xiàng)中的兩項(xiàng)。
如上圖,如果是最多同時滿足兩項(xiàng),那我們可以有三個組合:CA、CP、AP。在聊這三個組合之前,我們先分別看一下 Consisteny(一致性)、Availability(可用性)、Partition tolerance(分區(qū)容錯性)的含義。
假設(shè)某個系統(tǒng)當(dāng)前有兩個節(jié)點(diǎn)A和B,兩個節(jié)點(diǎn)分別可以由Actor進(jìn)行讀寫,兩個節(jié)點(diǎn)之間的數(shù)據(jù)會自動完成同步。
Consisteny(一致性)
一致性的要求是指,對于任何客戶端(上圖Actor)來說,每次的讀操作,都能獲得最新的數(shù)據(jù)。即,當(dāng)有客戶端向A節(jié)點(diǎn)寫入了新數(shù)據(jù)之后,其它客戶端從B節(jié)點(diǎn)中進(jìn)行讀操作所獲得的數(shù)據(jù)必須也是最新的,是與A節(jié)點(diǎn)數(shù)據(jù)保持一致的。
Availability(可用性)
可用性的要求是指,每個請求都能在合理的時間內(nèi)獲得符合預(yù)期的響應(yīng)(不保證獲取的結(jié)果是最新的數(shù)據(jù))。
按照上圖來看就是,客戶端只要向A節(jié)點(diǎn)或B節(jié)點(diǎn)發(fā)起請求后,只要這兩個節(jié)點(diǎn)收到了請求,就必須響應(yīng)給客戶端,但不需要保證響應(yīng)的值是否正確。
Partition tolerance(分區(qū)容錯性)
分區(qū)容錯性是指,當(dāng)節(jié)點(diǎn)之間的網(wǎng)絡(luò)出現(xiàn)問題之后,系統(tǒng)依然能正常提供服務(wù)。
講完了C、A、P的含義和要求,我們繼續(xù)來看看它們之間如何組合使用。
二、CAP 怎么應(yīng)用?
先把視野回到這張圖上:
雖然我們知道有 CA、CP、AP 三種組合方式,但是在分布式系統(tǒng)的結(jié)構(gòu)下,網(wǎng)絡(luò)是不可能做到100%可靠的。既然網(wǎng)絡(luò)不能保證絕對可靠,那 P(分區(qū)容錯性)就是一個必選項(xiàng)了。原因如下:
如果選擇 CA組合,放棄 P(分區(qū)容錯性)。還是以最上面的圖中A和B節(jié)點(diǎn)來舉例,當(dāng)發(fā)生節(jié)點(diǎn)間網(wǎng)絡(luò)故障時,為了保證 C(一致性),那么就必須將系統(tǒng)鎖住,不允許任何寫入操作,否者就會出現(xiàn)節(jié)點(diǎn)之間數(shù)據(jù)不一致了。但是鎖住了系統(tǒng),就意味著當(dāng)有寫請求進(jìn)來的時候,系統(tǒng)是不可用的,這一點(diǎn)又違背了 A(可用性)原則。
因此分布式系統(tǒng)理論上是不可能有CA組合的,所以我們只能選擇 CP 和 AP組合架構(gòu)。
下面我們來詳細(xì)看一下 CP架構(gòu) 和 AP架構(gòu)的特點(diǎn):
CP 架構(gòu)
CP架構(gòu)即 Consisteny(一致性)與 Partition tolerance(分區(qū)容錯性)的組合。
如上圖,由于網(wǎng)絡(luò)問題,節(jié)點(diǎn)A和節(jié)點(diǎn)B之前不能互相通訊。當(dāng)有客戶端(上圖Actor)向節(jié)點(diǎn)A進(jìn)行寫入請求時(準(zhǔn)備寫入Message 2),節(jié)點(diǎn)A會不接收寫入操作,導(dǎo)致寫入失敗,這樣就保證了節(jié)點(diǎn)A和節(jié)點(diǎn)B的數(shù)據(jù)一致性,即保證了Consisteny(一致性)。
然后,如果有另一個客戶端(上圖另一個Actor)向B節(jié)點(diǎn)進(jìn)行讀請求的時候,B請求返回的是網(wǎng)絡(luò)故障之前所保存的信息(Message 1),并且這個信息是與節(jié)點(diǎn)A一致的,是整個系統(tǒng)最后一次成功寫入的信息,是能正常提供服務(wù)的,即保證了Partition tolerance(分區(qū)容錯性)。
上述情況就是保障了CP架構(gòu),但放棄了Availability(可用性)的方案。
AP 架構(gòu)
AP架構(gòu)即 Availability(可用性)與 Partition tolerance(分區(qū)容錯性)的組合架構(gòu)。
如上圖,由于網(wǎng)絡(luò)問題,節(jié)點(diǎn)A和節(jié)點(diǎn)B之前不能互相通訊。當(dāng)有客戶端(上圖Actor)向節(jié)點(diǎn)A進(jìn)行寫入請求時(準(zhǔn)備寫入Message 2),節(jié)點(diǎn)A允許寫入,請求操作成功。但此時,由于A和B節(jié)點(diǎn)之前無法通訊,所以B節(jié)點(diǎn)的數(shù)據(jù)還是舊的(Message 1)。當(dāng)有客戶端向B節(jié)點(diǎn)發(fā)起讀請求時候,讀到的數(shù)據(jù)是舊數(shù)據(jù),與在A節(jié)點(diǎn)讀到的數(shù)據(jù)不一致。但由于系統(tǒng)能照常提供服務(wù),所以滿足了Availability(可用性)要求。
因此,這種情況下,就是保障了AP架構(gòu),但其放棄了 Consisteny(一致性)。
三、CAP 注意事項(xiàng)?
了解了CAP定理后,對于開發(fā)者而言,當(dāng)我們構(gòu)建服務(wù)的時候,就需要根據(jù)業(yè)務(wù)特性作出權(quán)衡考慮,哪些點(diǎn)是當(dāng)前系統(tǒng)可以取舍的,哪些是應(yīng)該重點(diǎn)保障的。
即使是在同一個系統(tǒng)中,不同模塊的數(shù)據(jù)可能應(yīng)用的CAP架構(gòu)都是不同的。舉個例子,在某個電商系統(tǒng)中,屬于用戶模塊的數(shù)據(jù)(賬密、錢包余額等)對一致性的要求很高,就可以采用CP架構(gòu)。而對于一些商品信息方面的數(shù)據(jù)對一致性要求沒那么高,但為了照顧用戶體驗(yàn),所以對可用性要求更高一些,那么這個模塊的數(shù)據(jù)就可以采用AP架構(gòu)。
另外,雖然上面第二節(jié)講到過我們只能選擇CP和AP,無法選擇CA。但這句話成立的前提條件是在系統(tǒng)發(fā)生了網(wǎng)絡(luò)故障的情況下。然而,網(wǎng)絡(luò)故障的概率在系統(tǒng)的整個生命周期中占比是很小的,因此我們在設(shè)計的時候,雖然要考慮網(wǎng)絡(luò)問題下的方案,但也要考慮網(wǎng)絡(luò)正常情況下的方案,即在網(wǎng)絡(luò)正常情況下,CA是可以實(shí)現(xiàn)的,我們也需要去保證在絕大多數(shù)時間下的CA架構(gòu)。
再者,即使我們按照CAP定理,三個中只能取其二,但不代表我們只需要保障其中的兩點(diǎn),而完全的放棄第三點(diǎn),我們應(yīng)該為不能保障的第三點(diǎn)也做一些防備措施或者冗余方案,來使系統(tǒng)更加的完善健全。
以上,就是對CAP定理的一些思考。
-
CP
+關(guān)注
關(guān)注
3文章
35瀏覽量
25632 -
CAP平臺
+關(guān)注
關(guān)注
0文章
4瀏覽量
8316
原文標(biāo)題:架構(gòu)設(shè)計之「 CAP 定理 」
文章出處:【微信號:LinuxHub,微信公眾號:Linux愛好者】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論