CAP 定理是數(shù)據(jù)系統(tǒng)設(shè)計的基本理論，目前幾乎所有的數(shù)據(jù)系統(tǒng)的設(shè)計都遵循了這個定理。但 CAP 定理給目前的數(shù)據(jù)系統(tǒng)帶來了許多復(fù)雜的、不可控的問題，使得數(shù)據(jù)系統(tǒng)的設(shè)計越來越復(fù)雜。Twitter 首席工程師、Storm 的作者 Nathan Marz 在本文中通過避開 CAP 定理帶來的諸多復(fù)雜問題，展示了一個不同于以往的數(shù)據(jù)系統(tǒng)設(shè)計方案，給我們的數(shù)據(jù)系統(tǒng)設(shè)計帶來了全新的思路。
成都創(chuàng)新互聯(lián)公司是專業(yè)的大渡口網(wǎng)站建設(shè)公司，大渡口接單;提供網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行大渡口網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!
CAP 定理指出，一個數(shù)據(jù)庫不可能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Partition-Tolerance）。
一致性（Consistency）是指執(zhí)行了一次成功的寫操作之后，未來的讀操作一定可以讀到這個寫入的值?？捎眯裕ˋvailability）是指系統(tǒng)總是可讀可寫的。Yammer 的 Coda Hale 和 Cloudera 的 Henry Robinson 都闡述過，分區(qū)容錯性是不能犧牲的，因此只能在一致性和可用性上做取舍，如何處理這種取舍正是目前 NoSQL 數(shù)據(jù)庫的核心焦點。
選擇一致性而不是可用性的系統(tǒng)將面臨一些尷尬的問題，當(dāng)系統(tǒng)不可用時怎么辦？你可以對寫操作進(jìn)行緩沖處理，但如果存儲緩沖數(shù)據(jù)的機(jī)器出現(xiàn)故障，客戶端將丟失寫入的值。同樣地，緩沖寫也可以被認(rèn)為是一種非一致性的操作，因為客戶端認(rèn)為成功的寫入實際上并沒有寫入到實際的數(shù)據(jù)庫中。當(dāng)然，系統(tǒng)可以在機(jī)器不可用時向客戶端返回錯誤，但可以想象，一個經(jīng)常告訴客戶端“請重試”的產(chǎn)品是多么令人討厭。
常見的理解及分析
目前流行的、對CAP理論解釋的情形是從同一數(shù)據(jù)在網(wǎng)絡(luò)環(huán)境中的多個副本出發(fā)的。為了保證數(shù)據(jù)不會丟失，在企業(yè)級的數(shù)據(jù)管理方案中，一般必須考慮數(shù)據(jù)的冗余存儲問題，而這應(yīng)該是通過在網(wǎng)絡(luò)上的其他獨立物理存儲節(jié)點上保留另一份、或多份數(shù)據(jù)副本來實現(xiàn)的（如附圖所示）。因為在同一個存儲節(jié)點上的數(shù)據(jù)冗余明顯不能解決單點故障問題，這與通過多節(jié)點集群來提供更好的計算可用性的道理是相同的。
附圖 CAP理論示意圖
其實，不用做嚴(yán)格的證明也可以想見，如附圖的情況，數(shù)據(jù)在節(jié)點A、B、C上保留了三份，如果對節(jié)點A上的數(shù)據(jù)進(jìn)行了修改，然后再讓客戶端通過網(wǎng)絡(luò)對該數(shù)據(jù)進(jìn)行讀取。那么，客戶端的讀取操作什么時候返回呢？
有這樣兩種情況：一種情況是要求節(jié)點A、B、C的三份數(shù)據(jù)完全一致后返回。也就是說，這時從任何一個網(wǎng)絡(luò)節(jié)點讀取的數(shù)據(jù)都是一樣的，這就是所謂的強(qiáng)一致性讀。很明顯，這時數(shù)據(jù)讀取的Latency要高一些（因為要等數(shù)據(jù)在網(wǎng)絡(luò)中的復(fù)制），同時A、B、C三個節(jié)點中任何一個宕機(jī)，都會導(dǎo)致數(shù)據(jù)不可用。也就是說，要保證強(qiáng)一致性，網(wǎng)絡(luò)中的副本越多，數(shù)據(jù)的可用性就越差；
另一種情況是，允許讀操作立即返回，容忍B節(jié)點的讀取與A節(jié)點的讀取不一致的情況發(fā)生。這樣一來，可用性顯然得到了提高，網(wǎng)絡(luò)中的副本也可以多一些，唯一得不到保證的是數(shù)據(jù)一致性。當(dāng)然，對寫操作同樣也有多個節(jié)點一致性的情況，在此不再贅述。
可以看出，上述對CAP理論的解釋主要是從網(wǎng)絡(luò)上多個節(jié)點之間的讀寫一致性出發(fā)考慮問題的。而這一點，對于關(guān)系型數(shù)據(jù)庫意味著什么呢？當(dāng)然主要是指通常所說的Standby（關(guān)于分布式事務(wù)，涉及到更多考慮，隨后討論）情況。對此，在實踐中我們大多已經(jīng)采取了弱一致性的異步延時同步方案，以提高可用性。這種情況并不存在關(guān)系型數(shù)據(jù)庫為保證C、A而放棄P的情況；而對海量數(shù)據(jù)管理的需求，關(guān)系型數(shù)據(jù)庫擴(kuò)展過程中所遇到的性能瓶頸，似乎也并不是CAP理論中所描述的那種原因造成的。那么，上述流行的說法中所描述的關(guān)系型數(shù)據(jù)庫為保證C、A而犧牲P到底是在指什么呢？
因此，如果根據(jù)現(xiàn)有的大多數(shù)資料對CAP理論的如上解釋，即只將其當(dāng)作分布式系統(tǒng)中多個數(shù)據(jù)副本之間的讀寫一致性問題的通用理論對待，那么就可以得出結(jié)論：CAP既適用于NoSQL數(shù)據(jù)庫，也適用于關(guān)系型數(shù)據(jù)庫。它是NoSQL數(shù)據(jù)庫、關(guān)系型數(shù)據(jù)庫，乃至一切分布式系統(tǒng)在設(shè)計數(shù)據(jù)多個副本之間讀寫一致性問題時需要遵循的共同原則。
更深入的探究：兩種重要的分布式場景
在本文中我們要說的重點與核心是：關(guān)于對CAP理論中一致性C的理解，除了上述數(shù)據(jù)副本之間的讀寫一致性以外，分布式環(huán)境中還有兩種非常重要的場景，如果不對它們進(jìn)行認(rèn)識與討論，就永遠(yuǎn)無法全面地理解CAP，當(dāng)然也就無法根據(jù)CAP做出正確的解釋。但可惜的是，目前為止卻很少有人提及這兩種場景：那就是事務(wù)與關(guān)聯(lián)。
先來看看分布式環(huán)境中的事務(wù)場景。我們知道，在關(guān)系型數(shù)據(jù)庫的事務(wù)操作遵循ACID原則，其中的一致性C，主要是指一個事務(wù)中相關(guān)聯(lián)的數(shù)據(jù)在事務(wù)操作結(jié)束后是一致的。所謂ACID原則，是指在寫入/異動資料的過程中，為保證交易正確可靠所必須具備的四個特性：即原子性（Atomicity，或稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）和持久性（Durability）。
例如銀行的一個存款交易事務(wù)，將導(dǎo)致交易流水表增加一條記錄。同時，必須導(dǎo)致賬戶表余額發(fā)生變化，這兩個操作必須是一個事務(wù)中全部完成，保證相關(guān)數(shù)據(jù)的一致性。而前文解釋的CAP理論中的C是指對一個數(shù)據(jù)多個備份的讀寫一致性。表面上看，這兩者不是一回事，但實際上，卻是本質(zhì)基本相同的事物：數(shù)據(jù)請求會等待多個相關(guān)數(shù)據(jù)操作全部完成才返回。對分布式系統(tǒng)來講，這就是我們通常所說的分布式事務(wù)問題。
眾所周知，分布式事務(wù)一般采用兩階段提交策略來實現(xiàn)，這是一個非常耗時的復(fù)雜過程，會嚴(yán)重影響系統(tǒng)效率，在實踐中我們盡量避免使用它。在實踐過程中，如果我們?yōu)榱藬U(kuò)展數(shù)據(jù)容量將數(shù)據(jù)分布式存儲，而事務(wù)的要求又完全不能降低。那么，系統(tǒng)的可用性一定會大大降低，在現(xiàn)實中我們一般都采用對這些數(shù)據(jù)不分散存儲的策略。
當(dāng)然，我們也可以說，最常使用的關(guān)系型數(shù)據(jù)庫，因為這個原因，擴(kuò)展性（分區(qū)可容忍性P）受到了限制，這是完全符合CAP理論的。但同時我們應(yīng)該意識到，這對NoSQL數(shù)據(jù)庫也是一樣的。如果NoSQL數(shù)據(jù)庫也要求嚴(yán)格的分布式事務(wù)功能，情況并不會比關(guān)系型數(shù)據(jù)庫好多少。只是在NoSQL的設(shè)計中，我們往往會弱化甚至去除事務(wù)的功能，該問題才表現(xiàn)得不那么明顯而已。
因此，在擴(kuò)展性問題上，如果要說關(guān)系型數(shù)據(jù)庫是為了保證C、A而犧牲P，在盡量避免分布式事務(wù)這一點上來看，應(yīng)該是正確的。也就是說：關(guān)系型數(shù)據(jù)庫應(yīng)該具有強(qiáng)大的事務(wù)功能，如果分區(qū)擴(kuò)展，可用性就會降低；而NoSQL數(shù)據(jù)庫干脆弱化甚至去除了事務(wù)功能，因此，分區(qū)的可擴(kuò)展性就大大增加了。
再來看看分布式環(huán)境中的關(guān)聯(lián)場景。初看起來，關(guān)系型數(shù)據(jù)庫中常用的多表關(guān)聯(lián)操作與CAP理論就更加不沾邊了。但仔細(xì)考慮，也可以用它來解釋數(shù)據(jù)庫分區(qū)擴(kuò)展對關(guān)聯(lián)所帶來的影響。對一個數(shù)據(jù)庫來講，采用了分區(qū)擴(kuò)展策略來擴(kuò)充容量，數(shù)據(jù)分散存儲了，很顯然多表關(guān)聯(lián)的性能就會下降，因為我們必須在網(wǎng)絡(luò)上進(jìn)行大量的數(shù)據(jù)遷移操作，這與CAP理論中數(shù)據(jù)副本之間的同步操作本質(zhì)上也是相同的。
因此，如果要保證系統(tǒng)的高可用性，需要同時實現(xiàn)強(qiáng)大的多表關(guān)系操作的關(guān)系型數(shù)據(jù)庫在分區(qū)可擴(kuò)展性上就遇到了極大的限制（即使是那些采用了各種優(yōu)秀解決方案的MPP架構(gòu)的關(guān)系型數(shù)據(jù)庫，如TeraData，Netezza等，其水平可擴(kuò)展性也是遠(yuǎn)遠(yuǎn)不如NoSQL數(shù)據(jù)庫的），而NoSQL數(shù)據(jù)庫則干脆在設(shè)計上弱化甚至去除了多表關(guān)聯(lián)操作。那么，從這一點上來理解“NoSQL數(shù)據(jù)庫是為了保證A與P，而犧牲C”的說法，也是可以講得通的。當(dāng)然，我們應(yīng)該理解，關(guān)聯(lián)問題在很多情況下不是并行處理的優(yōu)點所在，這在很大程度上與Amdahl定律相符合。
所以，從事務(wù)與關(guān)聯(lián)的角度來關(guān)系型數(shù)據(jù)庫的分區(qū)可擴(kuò)展性為什么受限的原因是最為清楚的。而NoSQL數(shù)據(jù)庫也正是因為弱化，甚至去除了像事務(wù)與關(guān)聯(lián)（全面地講，其實還有索引等特性）等在分布式環(huán)境中會嚴(yán)重影響系統(tǒng)可用性的功能，才獲得了更好的水平可擴(kuò)展性。
那么，如果將事務(wù)與關(guān)聯(lián)也納入CAP理論中一致性C的范疇的話，問題就很清楚了：關(guān)于“關(guān)系型數(shù)據(jù)庫為了保證一致性C與可用性A，而不得不犧牲分區(qū)可容忍性P”的說法便是正確的了。但關(guān)于“NoSQL選擇了C與P，或者A與P”的說法則是錯誤的，所有的NoSQL數(shù)據(jù)庫在設(shè)計策略的大方向上都是選擇了A與P（雖然對同一數(shù)據(jù)多個副本的讀寫一致性問題的設(shè)計各有不同），從來沒有完全選擇C與P的情況存在。
結(jié)論
現(xiàn)在看來，如果理解CAP理論只是指多個數(shù)據(jù)副本之間讀寫一致性的問題，那么它對關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫來講是完全一樣的，它只是運行在分布式環(huán)境中的數(shù)據(jù)管理設(shè)施在設(shè)計讀寫一致性問題時需要遵循的一個原則而已，卻并不是NoSQL數(shù)據(jù)庫具有優(yōu)秀的水平可擴(kuò)展性的真正原因。而如果將CAP理論中的一致性C理解為讀寫一致性、事務(wù)與關(guān)聯(lián)操作的綜合，則可以認(rèn)為關(guān)系型數(shù)據(jù)庫選擇了C與A，而NoSQL數(shù)據(jù)庫則全都是選擇了A與P，但并沒有選擇C與P的情況存在。這才是用CAP理論來支持NoSQL數(shù)據(jù)庫設(shè)計正確認(rèn)識。
其實，這種認(rèn)識正好與被廣泛認(rèn)同的NoSQL的另一個理論基礎(chǔ)相吻合，即與ACID對著干的BASE（基本可用性、軟狀態(tài)與最終一致性）。因為BASE的含義正好是指“NoSQL數(shù)據(jù)庫設(shè)計可以通過犧牲一定的數(shù)據(jù)一致性和容錯性來換取高性能的保持甚至提高”，即NoSQL數(shù)據(jù)庫都應(yīng)該是犧牲C來換取P，而不是犧牲A?？捎眯訟正好是所有NoSQL數(shù)據(jù)庫都普遍追求的特性。
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲。
（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲不需要固定的模式，無需多余操作就可以橫向擴(kuò)展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語言（SQL）
數(shù)據(jù)和關(guān)系都存儲在單獨的表中。
數(shù)據(jù)操縱語言，數(shù)據(jù)定義語言
嚴(yán)格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則
事務(wù)在英文中是transaction，和現(xiàn)實世界中的交易很類似，它有如下四個特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個操作失敗，整個事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài)，事務(wù)的運行不會改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨立性
所謂的獨立性是指并發(fā)的事務(wù)之間不會互相影響，如果一個事務(wù)要訪問的數(shù)據(jù)正在被另外一個事務(wù)修改，只要另外一個事務(wù)未提交，它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后，它所做的修改將會永久的保存在數(shù)據(jù)庫上，即使出現(xiàn)宕機(jī)也不會丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預(yù)定義的模式
鍵 - 值對存儲，列存儲，文檔存儲，圖形數(shù)據(jù)庫
最終一致性，而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。
定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。
CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通?？赡軐σ恢滦砸蟮鸵恍?。
CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實現(xiàn)上面的兩點。
而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實現(xiàn)的。
所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒有NoSQL系統(tǒng)能同時保證這三點。
說明：C：強(qiáng)一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫
AP：大多數(shù)網(wǎng)站架構(gòu)的選擇
CP：Redis、Mongodb
注意：分布式架構(gòu)的時候必須做出取舍。
一致性和可用性之間取一個平衡。多余大多數(shù)web應(yīng)用，其實并不需要強(qiáng)一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用
當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機(jī)，很貴的，好像好幾萬一臺；O 是指 Oracle 數(shù)據(jù)庫，也很貴的，好幾萬呢；M 是指 EMC 的存儲設(shè)備，也很貴的。
難點：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺不需要大面積重構(gòu)。
傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在功能支持上通常很寬泛，從簡單的鍵值查詢，到復(fù)雜的多表聯(lián)合查詢再到事務(wù)機(jī)制的支持。而與之不同的是，NoSQL系統(tǒng)通常注重性能和擴(kuò)展性，而非事務(wù)機(jī)制（事務(wù)就是強(qiáng)一致性的體現(xiàn)） 。傳統(tǒng)的SQL數(shù)據(jù)庫的事務(wù)通常都是支持ACID的強(qiáng)事務(wù)機(jī)制。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對不會被破壞。
重慶分公司
重慶分公司
