如何分析CAP principle

如何分析CAP principle ，很多新手對此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

CAP 定理，估計(jì)大部分人都聽說過，但CAP 定理的在實(shí)際中的價(jià)值，其實(shí)倒是鮮有人提及。

理解定理到底對實(shí)際的操作和使用有什么幫助，估計(jì)是很多人都要提及的問題。

Consistency , 一致性

Availability    可用性

Partition tolerance  分區(qū)的容錯(cuò)性

但我和我的很多朋友之間討論這個(gè)定理的時(shí)候，其實(shí)有一些不同的意見，其中關(guān)于C 就是有不同的理解

 Consistency ，一致性， 這個(gè)一致性，有人理解為在同一個(gè)時(shí)刻需要數(shù)據(jù)的一致性，有的人理解是，在最終的一個(gè)時(shí)刻數(shù)據(jù)是具有一致性。

這里我想舉個(gè)例子來講述一下我理解的 C 到底是什么樣子的

例如我們有一個(gè)汽車預(yù)售系統(tǒng)，而預(yù)定汽車在預(yù)定期是開放預(yù)定的，并且在數(shù)量上僅僅有50個(gè)名額。 那根據(jù)C 的定理， 我們的數(shù)據(jù)提供的數(shù)據(jù) A點(diǎn)寫，B點(diǎn)讀，C點(diǎn)讀，由于B 和 C 之間的網(wǎng)絡(luò)不通，導(dǎo)致的兩個(gè)客戶端，在訪問 B 和 C 節(jié)點(diǎn)在同一個(gè)時(shí)刻可能會得到兩個(gè)截然不同的值，我個(gè)人覺得 這就嚴(yán)重的違背了，C ，這個(gè)數(shù)據(jù)的一致性的定理。 我們需要在一個(gè)時(shí)刻，客戶端訪問 ABC，得到的數(shù)據(jù)是一致的。

可用性 A Availability

基本上在這個(gè)概念上，有不同的意見的人比較少，個(gè)人理解就是在分布式系統(tǒng)中，任意的可以繼續(xù)工作的節(jié)點(diǎn)都必須對客戶的請求產(chǎn)生響應(yīng)。

上圖中 A , B 兩個(gè)節(jié)點(diǎn)是故障點(diǎn)，只有C 節(jié)點(diǎn)是存活的，這也就造成兩個(gè)問題，C 要符合 可用性，則必須能繼續(xù)提供服務(wù)，而提供服務(wù)或響應(yīng)。 其中的響應(yīng)是包含于 A 和 B 節(jié)點(diǎn)一致的服務(wù)，例如 讀 或 寫的服務(wù)。

P Partition  tolerance 分區(qū)容錯(cuò)性

我們試想如果網(wǎng)絡(luò)出現(xiàn)問題，則 A , B ,C  不能被互訪的時(shí)候，每個(gè)節(jié)點(diǎn)自己就需要單獨(dú)對客戶端進(jìn)行訪問，由于網(wǎng)絡(luò)的問題，會導(dǎo)致 A, B ,C 三節(jié)點(diǎn)的數(shù)據(jù)不在一致，那么我們的系統(tǒng)還是否能繼續(xù)工作，則是一個(gè)分區(qū)的容錯(cuò)性需要考慮的問題。

那么下面的問題是，我知道這個(gè)定理到底有什么用？

1  首先，一個(gè)數(shù)據(jù)庫系統(tǒng)到底是在使用CAP的那種原理，是需要知道的，知道數(shù)據(jù)庫使用的原理，你就會很清晰的明確的了解到你使用的這個(gè)數(shù)據(jù)庫對應(yīng)的業(yè)務(wù)是什么。

里有一個(gè)我個(gè)人最近悟出的道理， 如果選擇一個(gè)數(shù)據(jù)庫系統(tǒng)僅僅是通過感性來選擇，而不是根據(jù)業(yè)務(wù)的特性來選擇，則很可能會發(fā)生一些尷尬的現(xiàn)象。

例如，我們有一個(gè)字幕系統(tǒng)，對我們的系統(tǒng)的要求是，只要能提供數(shù)據(jù)就好，準(zhǔn)確度不要求，但需要持續(xù)性的提供服務(wù)。

那這樣的一個(gè)系統(tǒng)我們對于 C   A   P  這三者是怎么考慮的

1 C 數(shù)據(jù)的一致性

2 A 數(shù)據(jù)的可用性

3 P 數(shù)據(jù)的分區(qū)容錯(cuò)

根據(jù)上面的簡單（或許還沒有準(zhǔn)確秒的） 需求，我們可以大致判斷這個(gè)系統(tǒng)我們的數(shù)據(jù)庫如果根據(jù) C A P 原理我們能提供的系統(tǒng)方式要保證， A ， P 

從提供服務(wù)的  A ， P  兩個(gè)點(diǎn).

主要原因是，客戶在輸入字幕后，如果我們從多個(gè)節(jié)點(diǎn)中讀取，會保證數(shù)據(jù)的提供，并且在網(wǎng)絡(luò)或其他節(jié)點(diǎn)出現(xiàn)故障時(shí)，還能繼續(xù)提供服務(wù)，但我們不能保證的就是數(shù)據(jù)的一致性，如果客戶從 A 節(jié)點(diǎn)寫入數(shù)據(jù)，但很可能我們在下一秒，或者幾十秒都不能再 B 點(diǎn)讀出出數(shù)據(jù)，或者 C 點(diǎn)已經(jīng)能讀出數(shù)據(jù)，但B 點(diǎn)和C點(diǎn)的數(shù)據(jù)不同步，這都是可以被這個(gè)系統(tǒng)所容忍的。

而符合我們上面系統(tǒng)中所描述的數(shù)據(jù)庫，有哪些，大名鼎鼎的 Cassandra 就是這樣的系統(tǒng)，所以妄圖在同一個(gè)時(shí)間點(diǎn)，必須嚴(yán)格的讀取同樣的數(shù)據(jù)，這樣的想法，你想都不要想在 cassandra 上使用，同時(shí)你要理解這個(gè)特性，你也就很清楚cassarda 會應(yīng)用到哪些系統(tǒng)中，而不會不敢不顧的把cassardra放到銀行金融中關(guān)于付款，收款之類的系統(tǒng)中使用。

而下面如果我們還有相關(guān)的需求，例如我們有一個(gè)關(guān)于合同簽署的系統(tǒng)，顧客在我們這里購買汽車，同時(shí)需要簽署合同并上傳 PDF 的電子版作為最終4S 店和 客戶，汽車金融公司，三方的具有法律效力的存檔。 如果我們使用分布式系統(tǒng)我們需要保證什么？

1 C 一致性， 2 A  可用性  3  分區(qū)容錯(cuò)性

根據(jù)業(yè)務(wù)，我們可以很清楚的明白，C 一致性是我們要保證的，我們不能再 A 節(jié)點(diǎn)上傳PDF 文檔后，在B 節(jié)點(diǎn)還查不到， 在C 節(jié)點(diǎn)查到的文檔和 B 節(jié)點(diǎn)不一致，從業(yè)務(wù)的角度來將，這是不能容忍的。同時(shí)如果有 B 節(jié)點(diǎn)失效，那C 節(jié)點(diǎn)，A 節(jié)點(diǎn)還能繼續(xù)提供相關(guān)的服務(wù)。 

我們損失的是 A ，可用性，如果我們不能保證 C 的前提下，我們會自動的終止服務(wù)。 意思就是如果我們不能保證幸存節(jié)點(diǎn)之間的信息是 C ，具有一致性的話，則我們就應(yīng)該停止服務(wù)。

在數(shù)據(jù)庫系統(tǒng)中，例如MONGO DB 就是 支持 CP 的系統(tǒng)， 例如我們有 三個(gè)節(jié)點(diǎn)的復(fù)制集的MONGODB 當(dāng)我們的受損的節(jié)點(diǎn)超過節(jié)點(diǎn)數(shù)據(jù)量的大多數(shù)的情況下，系統(tǒng)就會終止相關(guān)的服務(wù)。

支持 CA 系統(tǒng)的目前有  Apache KAFKA,  其實(shí)這個(gè)系統(tǒng)中關(guān)鍵點(diǎn)在于他的日志系統(tǒng)在哪里，如果存儲日志的主節(jié)點(diǎn)和 其他節(jié)點(diǎn)無法進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)同步，則能提供服務(wù)的就只有這個(gè)存儲日志的主節(jié)點(diǎn)，所以這個(gè)KAFKA系統(tǒng)就丟棄了 P 這個(gè)屬性。

所以在理解了CAP 原理后，你就可以很清楚的，明白你選擇的系統(tǒng)適合什么業(yè)務(wù)，而什么業(yè)務(wù)又應(yīng)該選擇什么樣的系統(tǒng)來支持。

在目前的分布式系統(tǒng)蓬勃發(fā)展的情形下，例如 MYSQL 的 MGR  則應(yīng)該是 CP原理的產(chǎn)物（如有不同意見請告知），SQL SERVER 的 AWO 也是類似 CP 的產(chǎn)物，而類似ORACLE 這樣的數(shù)據(jù)庫產(chǎn)品，到目前為止，還不屬于分布式數(shù)據(jù)庫系統(tǒng)的一員。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。