CAP原則又稱CAP定理，指的是在一個分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可得兼。

　　CAP原則是NOSQL數(shù)據(jù)庫的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分區(qū)容錯性）。

分布式系統(tǒng)的CAP理論：理論首先把分布式系統(tǒng)中的三個特性進(jìn)行了如下歸納：

• 一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）
• 可用性（A）：在集群中一部分節(jié)點故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）
• 分區(qū)容忍性（P）：以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

一致性與可用性的決擇編輯

CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒有NoSQL系統(tǒng)能同時保證這三點。 對于web2.0網(wǎng)站來說，關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地

數(shù)據(jù)庫事務(wù)一致性需求?
　　很多web實時系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù)，對讀一致性的要求很低，有些場合對寫一致性要求并不高。允許實現(xiàn)最終一致性。

數(shù)據(jù)庫的寫實時性和讀實時性需求
　　對關(guān)系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對于很多web應(yīng)用來說，并不要求這么高的實時性，比方說發(fā)一條消息之 后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態(tài)是完全可以接受的。

對復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求?
　　任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的報表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設(shè)計角 度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個短語的簡寫，BASE是對CAP中一致性和可用性權(quán)衡的結(jié)果，其來源于對大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實踐的結(jié)論，是基于CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性（Eventual consistency）。接下來我們著重對BASE中的三要素進(jìn)行詳細(xì)講解。

基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候，允許損失部分可用性——但請注意，這絕不等價于系統(tǒng)不可用，以下兩個就是“基本可用”的典型例子。

• 響應(yīng)時間上的損失：正常情況下，一個在線搜索引擎需要0.5秒內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)異常（比如系統(tǒng)部分機房發(fā)生斷電或斷網(wǎng)故障），查詢結(jié)果的響應(yīng)時間增加到了1~2秒。
• 功能上的損失：正常情況下，在一個電子商務(wù)網(wǎng)站上進(jìn)行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時候，由于消費者的購物行為激增，為了保護(hù)購物系統(tǒng)的穩(wěn)定性，部分消費者可能會被引導(dǎo)到一個降級頁面。

弱狀態(tài)也稱為軟狀態(tài)，和硬狀態(tài)相對，是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)聽不的過程存在延時。

最終一致性

最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后，最終能夠達(dá)到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性

亞馬遜首席技術(shù)官Werner Vogels在于2008年發(fā)表的一篇文章中對最終一致性進(jìn)行了非常詳細(xì)的介紹。他認(rèn)為最終一致性時一種特殊的弱一致性：系統(tǒng)能夠保證在沒有其他新的更新操作的情況下，數(shù)據(jù)最終一定能夠達(dá)到一致的狀態(tài)，因此所有客戶端對系統(tǒng)的數(shù)據(jù)訪問都能夠胡渠道最新的值。同時，在沒有發(fā)生故障的前提下，數(shù)據(jù)達(dá)到一致狀態(tài)的時間延遲，取決于網(wǎng)絡(luò)延遲，系統(tǒng)負(fù)載和數(shù)據(jù)復(fù)制方案設(shè)計等因素。

在實際工程實踐中，最終一致性存在以下五類主要變種。

因果一致性：

??????? 因果一致性是指，如果進(jìn)程A在更新完某個數(shù)據(jù)項后通知了進(jìn)程B，那么進(jìn)程B之后對該數(shù)據(jù)項的訪問都應(yīng)該能夠獲取到進(jìn)程A更新后的最新值，并且如果進(jìn)程B要對該數(shù)據(jù)項進(jìn)行更新操作的話，務(wù)必基于進(jìn)程A更新后的最新值，即不能發(fā)生丟失更新情況。與此同時，與進(jìn)程A無因果關(guān)系的進(jìn)程C的數(shù)據(jù)訪問則沒有這樣的限制。

讀己之所寫：

??????? 讀己之所寫是指，進(jìn)程A更新一個數(shù)據(jù)項之后，它自己總是能夠訪問到更新過的最新值，而不會看到舊值。也就是說，對于單個數(shù)據(jù)獲取者而言，其讀取到的數(shù)據(jù)一定不會比自己上次寫入的值舊。因此，讀己之所寫也可以看作是一種特殊的因果一致性。

會話一致性：

??????? 會話一致性將對系統(tǒng)數(shù)據(jù)的訪問過程框定在了一個會話當(dāng)中：系統(tǒng)能保證在同一個有效的會話中實現(xiàn)“讀己之所寫”的一致性，也就是說，執(zhí)行更新操作之后，客戶端能夠在同一個會話中始終讀取到該數(shù)據(jù)項的最新值。

單調(diào)讀一致性：

??????? 單調(diào)讀一致性是指如果一個進(jìn)程從系統(tǒng)中讀取出一個數(shù)據(jù)項的某個值后，那么系統(tǒng)對于該進(jìn)程后續(xù)的任何數(shù)據(jù)訪問都不應(yīng)該返回更舊的值。

單調(diào)寫一致性：

???????? 單調(diào)寫一致性是指，一個系統(tǒng)需要能夠保證來自同一個進(jìn)程的寫操作被順序地執(zhí)行。

以上就是最終一致性的五類常見的變種，在時間系統(tǒng)實踐中，可以將其中的若干個變種互相結(jié)合起來，以構(gòu)建一個具有最終一致性的分布式系統(tǒng)。事實上，可以將其中的若干個變種相互結(jié)合起來，以構(gòu)建一個具有最終一致性特性的分布式系統(tǒng)。事實上，最終一致性并不是只有那些大型分布式系統(tǒng)才設(shè)計的特性，許多現(xiàn)代的關(guān)系型數(shù)據(jù)庫都采用了最終一致性模型。在現(xiàn)代關(guān)系型數(shù)據(jù)庫中，大多都會采用同步和異步方式來實現(xiàn)主備數(shù)據(jù)復(fù)制技術(shù)。在同步方式中，數(shù)據(jù)的復(fù)制國恥鞥通常是更新事務(wù)的一部分，因此在事務(wù)完成后，主備數(shù)據(jù)庫的數(shù)據(jù)就會達(dá)到一致。而在異步方式中，備庫的更新往往存在延時，這取決于事務(wù)日志在主備數(shù)據(jù)庫之間傳輸?shù)臅r間長短，如果傳輸時間過長或者甚至在日志傳輸過程中出現(xiàn)異常導(dǎo)致無法及時將事務(wù)應(yīng)用到備庫上，那么狠顯然，從備庫中讀取的的數(shù)據(jù)將是舊的，因此就出現(xiàn)了不一致的情況。當(dāng)然，無論是采用多次重試還是認(rèn)為數(shù)據(jù)訂正，關(guān)系型數(shù)據(jù)庫還是能搞保證最終數(shù)據(jù)達(dá)到一致——這就是系統(tǒng)提供最終一致性保證的經(jīng)典案例。

總的來說，BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)，和傳統(tǒng)事務(wù)的ACID特性使相反的，它完全不同于ACID的強一致性模型，而是提出通過犧牲強一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達(dá)到一致狀態(tài)。但同時，在實際的分布式場景中，不同業(yè)務(wù)單元和組件對數(shù)據(jù)一致性的要求是不同的，因此在具體的分布式系統(tǒng)架構(gòu)設(shè)計過程中，ACID特性與BASE理論往往又會結(jié)合在一起使用。

小結(jié)：

計算機系統(tǒng)從集中式向分布式的變革隨著包括分布式網(wǎng)絡(luò)、分布式事務(wù)和分布式數(shù)據(jù)一致性等在內(nèi)的一系列問題與挑戰(zhàn)，同時也催生了一大批諸如ACID、CAP和BASE等經(jīng)典理論的快速發(fā)展。

與NoSQL的關(guān)系編輯

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到復(fù)雜的多表聯(lián)合查詢再到事務(wù)機制的支持。而與之不同的是，NoSQL系統(tǒng)通常注重性能和擴展性，而非事務(wù)機制（事務(wù)就是強一致性的體現(xiàn)）[2]??。
　　傳統(tǒng)的SQL數(shù)據(jù)庫的事務(wù)通常都是支持ACID的強事務(wù)機制。A代表原子性，即在事務(wù)中執(zhí)行多個操作是原子性的，要么事務(wù)中的操作全部執(zhí)行，要么一個都不執(zhí)行;C代表一致性，即保證進(jìn)行事務(wù)的過程中整個數(shù)據(jù)加的狀態(tài)是一致的，不會出現(xiàn)數(shù)據(jù)花掉的情況;I代表隔離性，即兩個事務(wù)不會相互影響，覆蓋彼此數(shù)據(jù)等;D表示持久化，即事務(wù)一量完成，那么數(shù)據(jù)應(yīng)該是被寫到安全的，持久化存儲的設(shè)備上（比如磁盤）。
　　NoSQL系統(tǒng)僅提供對行級別的原子性保證，也就是說同時對同一個Key下的數(shù)據(jù)進(jìn)行的兩個操作，在實際執(zhí)行的時候是會串行的執(zhí)行，保證了每一個Key-Value對不會被破壞。

CAP的是什么關(guān)系

It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
在分布式系統(tǒng)的設(shè)計中，沒有一種設(shè)計可以同時滿足一致性，可用性，分區(qū)容錯性 3個特性

注意：不要將弱一致性，最終一致性放到CAP理論里混為一談（混淆概念的坑真多）
弱一致性，最終一致性 你可以認(rèn)為和CAP的C一點關(guān)系也沒有，因為CAP的C是更新操作完成后，任何節(jié)點看到的數(shù)據(jù)完全一致, 弱一致性。最終一致性本身和CAP的C一致性是違背的，所以你可以看到那些謊稱自己系統(tǒng)同時具備CAP 3個特性是多么的可笑，可能國內(nèi)更多的場景是：一個開放人員一旦走上講臺演講，就立馬轉(zhuǎn)變?yōu)榱藸I銷人員，連最基本的理念也不要了。
這里有一篇標(biāo)題很大的文章??cap-twelve-years-later-how-the-rules-have-changed?，實際上本文的changed更多的是在思考方式上，而本身CAP理論是沒有changed的

為什么會是這樣

我們來看一個簡單的問題, 一個DB服務(wù)?? 搭建在兩個機房（北京,廣州)，兩個DB實例同時提供寫入和讀取

? 1.?假設(shè)DB的更新操作是同時寫北京和廣州的DB都成功才返回成功
????? 在沒有出現(xiàn)網(wǎng)絡(luò)故障的時候，滿足CA原則，C 即我的任何一個寫入，更新操作成功并返回客戶端完成后,分布式的所有節(jié)點在同一時間的數(shù)據(jù)完全一致， A 即我的讀寫操作都能夠成功，但是當(dāng)出現(xiàn)網(wǎng)絡(luò)故障時，我不能同時保證CA，即P條件無法滿足

? 2.?假設(shè)DB的更新操作是只寫本地機房成功就返回，通過binlog/oplog回放方式同步至側(cè)邊機房
????? 這種操作保證了在出現(xiàn)網(wǎng)絡(luò)故障時,雙邊機房都是可以提供服務(wù)的，且讀寫操作都能成功，意味著他滿足了AP ，但是它不滿足C，因為更新操作返回成功后，雙邊機房的DB看到的數(shù)據(jù)會存在短暫不一致，且在網(wǎng)絡(luò)故障時，不一致的時間差會很大（僅能保證最終一致性）

? 3.?假設(shè)DB的更新操作是同時寫北京和廣州的DB都成功才返回成功且網(wǎng)絡(luò)故障時提供降級服務(wù)
????? 降級服務(wù)，如停止寫入，只提供讀取功能，這樣能保證數(shù)據(jù)是一致的，且網(wǎng)絡(luò)故障時能提供服務(wù)，滿足CP原則，但是他無法滿足可用性原則

選擇權(quán)衡

通過上面的例子，我們得知，我們永遠(yuǎn)無法同時得到CAP這3個特性，那么我們怎么來權(quán)衡選擇呢？
選擇的關(guān)鍵點取決于業(yè)務(wù)場景

對于大多數(shù)互聯(lián)網(wǎng)應(yīng)用來說（如網(wǎng)易門戶），因為機器數(shù)量龐大，部署節(jié)點分散，網(wǎng)絡(luò)故障是常態(tài)，可用性是必須需要保證的，所以只有設(shè)置一致性來保證服務(wù)的AP，通常常見的高可用服務(wù)吹噓5個9 6個9服務(wù)SLA穩(wěn)定性就本都是放棄C選擇AP

對于需要確保強一致性的場景，如銀行，通常會權(quán)衡CA和CP模型，CA模型網(wǎng)絡(luò)故障時完全不可用，CP模型具備部分可用性，實際的選擇需要通過業(yè)務(wù)場景來權(quán)衡（并不是所有情況CP都好于CA，只能查看信息不能更新信息有時候從產(chǎn)品層面還不如直接拒絕服務(wù)）

延伸

BASE(Basically Available, Soft State, Eventual Consistency? 基本可用、軟狀態(tài)、最終一致性) 對CAP AP理論的延伸, Redis等眾多系統(tǒng)構(gòu)建與這個理論之上
ACID? 傳統(tǒng)數(shù)據(jù)庫常用的設(shè)計理念, ACID和BASE代表了兩種截然相反的設(shè)計哲學(xué)，分處一致性-可用性分布圖譜的兩極。

轉(zhuǎn)自：http://www.cnblogs.com/duanxz/p/5229352.html

總結(jié)

以上是生活随笔為你收集整理的【分布式】1、CAP原则(CAP定理)、BASE理论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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