如何分析CAP principle

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

CAP 定理，估計大部分人都聽說過，但CAP 定理的在實際中的價值，其實倒是鮮有人提及。

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

Consistency , 一致性

Availability    可用性

Partition tolerance  分區的容錯性

但我和我的很多朋友之間討論這個定理的時候，其實有一些不同的意見，其中關于C 就是有不同的理解

 Consistency ，一致性， 這個一致性，有人理解為在同一個時刻需要數據的一致性，有的人理解是，在最終的一個時刻數據是具有一致性。

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

例如我們有一個汽車預售系統，而預定汽車在預定期是開放預定的，并且在數量上僅僅有50個名額。 那根據C 的定理， 我們的數據提供的數據 A點寫，B點讀，C點讀，由于B 和 C 之間的網絡不通，導致的兩個客戶端，在訪問 B 和 C 節點在同一個時刻可能會得到兩個截然不同的值，我個人覺得 這就嚴重的違背了，C ，這個數據的一致性的定理。 我們需要在一個時刻，客戶端訪問 ABC，得到的數據是一致的。

可用性 A Availability

基本上在這個概念上，有不同的意見的人比較少，個人理解就是在分布式系統中，任意的可以繼續工作的節點都必須對客戶的請求產生響應。

上圖中 A , B 兩個節點是故障點，只有C 節點是存活的，這也就造成兩個問題，C 要符合 可用性，則必須能繼續提供服務，而提供服務或響應。 其中的響應是包含于 A 和 B 節點一致的服務，例如 讀 或 寫的服務。

P Partition  tolerance 分區容錯性

我們試想如果網絡出現問題，則 A , B ,C  不能被互訪的時候，每個節點自己就需要單獨對客戶端進行訪問，由于網絡的問題，會導致 A, B ,C 三節點的數據不在一致，那么我們的系統還是否能繼續工作，則是一個分區的容錯性需要考慮的問題。

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

1  首先，一個數據庫系統到底是在使用CAP的那種原理，是需要知道的，知道數據庫使用的原理，你就會很清晰的明確的了解到你使用的這個數據庫對應的業務是什么。

里有一個我個人最近悟出的道理， 如果選擇一個數據庫系統僅僅是通過感性來選擇，而不是根據業務的特性來選擇，則很可能會發生一些尷尬的現象。

例如，我們有一個字幕系統，對我們的系統的要求是，只要能提供數據就好，準確度不要求，但需要持續性的提供服務。

那這樣的一個系統我們對于 C   A   P  這三者是怎么考慮的

1 C 數據的一致性

2 A 數據的可用性

3 P 數據的分區容錯

根據上面的簡單（或許還沒有準確秒的） 需求，我們可以大致判斷這個系統我們的數據庫如果根據 C A P 原理我們能提供的系統方式要保證， A ， P 

從提供服務的  A ， P  兩個點.

主要原因是，客戶在輸入字幕后，如果我們從多個節點中讀取，會保證數據的提供，并且在網絡或其他節點出現故障時，還能繼續提供服務，但我們不能保證的就是數據的一致性，如果客戶從 A 節點寫入數據，但很可能我們在下一秒，或者幾十秒都不能再 B 點讀出出數據，或者 C 點已經能讀出數據，但B 點和C點的數據不同步，這都是可以被這個系統所容忍的。

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

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

1 C 一致性， 2 A  可用性  3  分區容錯性

根據業務，我們可以很清楚的明白，C 一致性是我們要保證的，我們不能再 A 節點上傳PDF 文檔后，在B 節點還查不到， 在C 節點查到的文檔和 B 節點不一致，從業務的角度來將，這是不能容忍的。同時如果有 B 節點失效，那C 節點，A 節點還能繼續提供相關的服務。 

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

在數據庫系統中，例如MONGO DB 就是 支持 CP 的系統， 例如我們有 三個節點的復制集的MONGODB 當我們的受損的節點超過節點數據量的大多數的情況下，系統就會終止相關的服務。

支持 CA 系統的目前有  Apache KAFKA,  其實這個系統中關鍵點在于他的日志系統在哪里，如果存儲日志的主節點和 其他節點無法進行網絡數據同步，則能提供服務的就只有這個存儲日志的主節點，所以這個KAFKA系統就丟棄了 P 這個屬性。

所以在理解了CAP 原理后，你就可以很清楚的，明白你選擇的系統適合什么業務，而什么業務又應該選擇什么樣的系統來支持。

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

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