無(wú)論你是一個(gè)系統(tǒng)架構(gòu)師，還是一個(gè)普通開(kāi)發(fā)，當(dāng)你開(kāi)發(fā)或者設(shè)計(jì)一個(gè)分布式系統(tǒng)的時(shí)候，CAP理論是無(wú)論如何也繞不過(guò)去的。本文就來(lái)介紹一下到底什么是CAP理論，如何證明CAP理論，以及CAP的權(quán)衡問(wèn)題。

CAP理論概述

CAP理論：一個(gè)分布式系統(tǒng)最多只能同時(shí)滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance）這三項(xiàng)中的兩項(xiàng)。

讀者需要注意的的是，CAP理論中的CA和數(shù)據(jù)庫(kù)事務(wù)中ACID的CA并完全是同一回事兒。兩者之中的A都是C都是一致性(Consistency)。CAP中的A指的是可用性（Availability），而ACID中的A指的是原子性（Atomicity)，切勿混為一談。

CAP的定義

Consistency 一致性

一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后，所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致，所以，一致性，說(shuō)的就是數(shù)據(jù)一致性。分布式的一致性

對(duì)于一致性，可以分為從客戶端和服務(wù)端兩個(gè)不同的視角。從客戶端來(lái)看，一致性主要指的是多并發(fā)訪問(wèn)時(shí)更新過(guò)的數(shù)據(jù)如何獲取的問(wèn)題。從服務(wù)端來(lái)看，則是更新如何復(fù)制分布到整個(gè)系統(tǒng)，以保證數(shù)據(jù)最終一致。

一致性是因?yàn)橛胁l(fā)讀寫(xiě)才有的問(wèn)題，因此在理解一致性的問(wèn)題時(shí)，一定要注意結(jié)合考慮并發(fā)讀寫(xiě)的場(chǎng)景。

從客戶端角度，多進(jìn)程并發(fā)訪問(wèn)時(shí)，更新過(guò)的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。

三種一致性策略

對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過(guò)的數(shù)據(jù)能被后續(xù)的訪問(wèn)都能看到，這是強(qiáng)一致性。

如果能容忍后續(xù)的部分或者全部訪問(wèn)不到，則是弱一致性。

如果經(jīng)過(guò)一段時(shí)間后要求能訪問(wèn)到更新后的數(shù)據(jù)，則是最終一致性。

CAP中說(shuō)，不可能同時(shí)滿足的這個(gè)一致性指的是強(qiáng)一致性。

Availability 可用性

可用性指“Reads and writes always succeed”，即服務(wù)一直可用，而且是正常響應(yīng)時(shí)間。

對(duì)于一個(gè)可用性的分布式系統(tǒng)，每一個(gè)非故障的節(jié)點(diǎn)必須對(duì)每一個(gè)請(qǐng)求作出響應(yīng)。所以，一般我們?cè)诤饬恳粋€(gè)系統(tǒng)的可用性的時(shí)候，都是通過(guò)停機(jī)時(shí)間來(lái)計(jì)算的。

可用性分類可用水平（%）年可容忍停機(jī)時(shí)間

容錯(cuò)可用性	99.9999	<1 min
極高可用性	99.999	<5 min
具有故障自動(dòng)恢復(fù)能力的可用性	99.99	<53 min
高可用性	99.9	<8.8h
商品可用性	99	<43.8 min

通常我們描述一個(gè)系統(tǒng)的可用性時(shí)，我們說(shuō)淘寶的系統(tǒng)可用性可以達(dá)到5個(gè)9，意思就是說(shuō)他的可用水平是99.999%，即全年停機(jī)時(shí)間不超過(guò)?(1-0.99999)*365*24*60 = 5.256 min，這是一個(gè)極高的要求。

好的可用性主要是指系統(tǒng)能夠很好的為用戶服務(wù)，不出現(xiàn)用戶操作失敗或者訪問(wèn)超時(shí)等用戶體驗(yàn)不好的情況。一個(gè)分布式系統(tǒng)，上下游設(shè)計(jì)很多系統(tǒng)如負(fù)載均衡、WEB服務(wù)器、應(yīng)用代碼、數(shù)據(jù)庫(kù)服務(wù)器等，任何一個(gè)節(jié)點(diǎn)的不穩(wěn)定都可以影響可用性。

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

分區(qū)容錯(cuò)性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

分區(qū)容錯(cuò)性和擴(kuò)展性緊密相關(guān)。在分布式應(yīng)用中，可能因?yàn)橐恍┓植际降脑驅(qū)е孪到y(tǒng)無(wú)法正常運(yùn)轉(zhuǎn)。好的分區(qū)容錯(cuò)性要求能夠使應(yīng)用雖然是一個(gè)分布式系統(tǒng)，而看上去卻好像是在一個(gè)可以運(yùn)轉(zhuǎn)正常的整體。比如現(xiàn)在的分布式系統(tǒng)中有某一個(gè)或者幾個(gè)機(jī)器宕掉了，其他剩下的機(jī)器還能夠正常運(yùn)轉(zhuǎn)滿足系統(tǒng)需求，或者是機(jī)器之間有網(wǎng)絡(luò)異常，將分布式系統(tǒng)分隔未獨(dú)立的幾個(gè)部分，各個(gè)部分還能維持分布式系統(tǒng)的運(yùn)作，這樣就具有好的分區(qū)容錯(cuò)性。

簡(jiǎn)單點(diǎn)說(shuō)，就是在網(wǎng)絡(luò)中斷，消息丟失的情況下，系統(tǒng)如果還能正常工作，就是有比較好的分區(qū)容錯(cuò)性。

CAP的證明

如上圖，是我們證明CAP的基本場(chǎng)景，網(wǎng)絡(luò)中有兩個(gè)節(jié)點(diǎn)N1和N2，可以簡(jiǎn)單的理解N1和N2分別是兩臺(tái)計(jì)算機(jī)，他們之間網(wǎng)絡(luò)可以連通，N1中有一個(gè)應(yīng)用程序A，和一個(gè)數(shù)據(jù)庫(kù)V，N2也有一個(gè)應(yīng)用程序B2和一個(gè)數(shù)據(jù)庫(kù)V。現(xiàn)在，A和B是分布式系統(tǒng)的兩個(gè)部分，V是分布式系統(tǒng)的數(shù)據(jù)存儲(chǔ)的兩個(gè)子數(shù)據(jù)庫(kù)。

在滿足一致性的時(shí)候，N1和N2中的數(shù)據(jù)是一樣的，V0=V0。在滿足可用性的時(shí)候，用戶不管是請(qǐng)求N1或者N2，都會(huì)得到立即響應(yīng)。在滿足分區(qū)容錯(cuò)性的情況下，N1和N2有任何一方宕機(jī)，或者網(wǎng)絡(luò)不通的時(shí)候，都不會(huì)影響N1和N2彼此之間的正常運(yùn)作。

如上圖，是分布式系統(tǒng)正常運(yùn)轉(zhuǎn)的流程，用戶向N1機(jī)器請(qǐng)求數(shù)據(jù)更新，程序A更新數(shù)據(jù)庫(kù)Vo為V1，分布式系統(tǒng)將數(shù)據(jù)進(jìn)行同步操作M，將V1同步的N2中V0，使得N2中的數(shù)據(jù)V0也更新為V1，N2中的數(shù)據(jù)再響應(yīng)N2的請(qǐng)求。

這里，可以定義N1和N2的數(shù)據(jù)庫(kù)V之間的數(shù)據(jù)是否一樣為一致性；外部對(duì)N1和N2的請(qǐng)求響應(yīng)為可用行；N1和N2之間的網(wǎng)絡(luò)環(huán)境為分區(qū)容錯(cuò)性。這是正常運(yùn)作的場(chǎng)景，也是理想的場(chǎng)景，然而現(xiàn)實(shí)是殘酷的，當(dāng)錯(cuò)誤發(fā)生的時(shí)候，一致性和可用性還有分區(qū)容錯(cuò)性，是否能同時(shí)滿足，還是說(shuō)要進(jìn)行取舍呢？

作為一個(gè)分布式系統(tǒng)，它和單機(jī)系統(tǒng)的最大區(qū)別，就在于網(wǎng)絡(luò)，現(xiàn)在假設(shè)一種極端情況，N1和N2之間的網(wǎng)絡(luò)斷開(kāi)了，我們要支持這種網(wǎng)絡(luò)異常，相當(dāng)于要滿足分區(qū)容錯(cuò)性，能不能同時(shí)滿足一致性和響應(yīng)性呢？還是說(shuō)要對(duì)他們進(jìn)行取舍。

假設(shè)在N1和N2之間網(wǎng)絡(luò)斷開(kāi)的時(shí)候，有用戶向N1發(fā)送數(shù)據(jù)更新請(qǐng)求，那N1中的數(shù)據(jù)V0將被更新為V1，由于網(wǎng)絡(luò)是斷開(kāi)的，所以分布式系統(tǒng)同步操作M，所以N2中的數(shù)據(jù)依舊是V0；這個(gè)時(shí)候，有用戶向N2發(fā)送數(shù)據(jù)讀取請(qǐng)求，由于數(shù)據(jù)還沒(méi)有進(jìn)行同步，應(yīng)用程序沒(méi)辦法立即給用戶返回最新的數(shù)據(jù)V1，怎么辦呢？

有二種選擇，第一，犧牲數(shù)據(jù)一致性，保證可用性。響應(yīng)舊的數(shù)據(jù)V0給用戶；

第二，犧牲可用性，保證數(shù)據(jù)一致性。阻塞等待，直到網(wǎng)絡(luò)連接恢復(fù)，數(shù)據(jù)更新操作M完成之后，再給用戶響應(yīng)最新的數(shù)據(jù)V1。

這個(gè)過(guò)程，證明了要滿足分區(qū)容錯(cuò)性的分布式系統(tǒng)，只能在一致性和可用性兩者中，選擇其中一個(gè)。

CAP權(quán)衡

通過(guò)CAP理論及前面的證明，我們知道無(wú)法同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性這三個(gè)特性，那要舍棄哪個(gè)呢？

我們分三種情況來(lái)闡述一下。

CA without P

這種情況在分布式系統(tǒng)中幾乎是不存在的。首先在分布式環(huán)境下，網(wǎng)絡(luò)分區(qū)是一個(gè)自然的事實(shí)。因?yàn)榉謪^(qū)是必然的，所以如果舍棄P，意味著要舍棄分布式系統(tǒng)。那也就沒(méi)有必要再討論CAP理論了。這也是為什么在前面的CAP證明中，我們以系統(tǒng)滿足P為前提論述了無(wú)法同時(shí)滿足C和A。

比如我們熟知的關(guān)系型數(shù)據(jù)庫(kù)，如My Sql和Oracle就是保證了可用性和數(shù)據(jù)一致性，但是他并不是個(gè)分布式系統(tǒng)。一旦關(guān)系型數(shù)據(jù)庫(kù)要考慮主備同步、集群部署等就必須要把P也考慮進(jìn)來(lái)。

其實(shí)，在CAP理論中。C，A，P三者并不是平等的，CAP之父在《Spanner，真時(shí)，CAP理論》一文中寫(xiě)到：

如果說(shuō)Spanner真有什么特別之處，那就是谷歌的廣域網(wǎng)。Google通過(guò)建立私有網(wǎng)絡(luò)以及強(qiáng)大的網(wǎng)絡(luò)工程能力來(lái)保證P，在多年運(yùn)營(yíng)改進(jìn)的基礎(chǔ)上，在生產(chǎn)環(huán)境中可以最大程度的減少分區(qū)發(fā)生，從而實(shí)現(xiàn)高可用性。

從Google的經(jīng)驗(yàn)中可以得到的結(jié)論是，無(wú)法通過(guò)降低CA來(lái)提升P。要想提升系統(tǒng)的分區(qū)容錯(cuò)性，需要通過(guò)提升基礎(chǔ)設(shè)施的穩(wěn)定性來(lái)保障。

所以，對(duì)于一個(gè)分布式系統(tǒng)來(lái)說(shuō)。P是一個(gè)基本要求，CAP三者中，只能在CA兩者之間做權(quán)衡，并且要想盡辦法提升P。

CP without A

如果一個(gè)分布式系統(tǒng)不要求強(qiáng)的可用性，即容許系統(tǒng)停機(jī)或者長(zhǎng)時(shí)間無(wú)響應(yīng)的話，就可以在CAP三者中保障CP而舍棄A。

一個(gè)保證了CP而一個(gè)舍棄了A的分布式系統(tǒng)，一旦發(fā)生網(wǎng)絡(luò)故障或者消息丟失等情況，就要犧牲用戶的體驗(yàn)，等待所有數(shù)據(jù)全部一致了之后再讓用戶訪問(wèn)系統(tǒng)。

設(shè)計(jì)成CP的系統(tǒng)其實(shí)也不少，其中最典型的就是很多分布式數(shù)據(jù)庫(kù)，他們都是設(shè)計(jì)成CP的。在發(fā)生極端情況時(shí)，優(yōu)先保證數(shù)據(jù)的強(qiáng)一致性，代價(jià)就是舍棄系統(tǒng)的可用性。如Redis、HBase等，還有分布式系統(tǒng)中常用的Zookeeper也是在CAP三者之中選擇優(yōu)先保證CP的。

無(wú)論是像Redis、HBase這種分布式存儲(chǔ)系統(tǒng)，還是像Zookeeper這種分布式協(xié)調(diào)組件。數(shù)據(jù)的一致性是他們最最基本的要求。一個(gè)連數(shù)據(jù)一致性都保證不了的分布式存儲(chǔ)要他有何用？

在我的Zookeeper介紹（二）——Zookeeper概述一文中其實(shí)介紹過(guò)zk關(guān)于CAP的思考，這里再簡(jiǎn)單回顧一下：

ZooKeeper是個(gè)CP（一致性+分區(qū)容錯(cuò)性）的，即任何時(shí)刻對(duì)ZooKeeper的訪問(wèn)請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性。但是它不能保證每次服務(wù)請(qǐng)求的可用性，也就是在極端環(huán)境下，ZooKeeper可能會(huì)丟棄一些請(qǐng)求，消費(fèi)者程序需要重新請(qǐng)求才能獲得結(jié)果。ZooKeeper是分布式協(xié)調(diào)服務(wù)，它的職責(zé)是保證數(shù)據(jù)在其管轄下的所有服務(wù)之間保持同步、一致。所以就不難理解為什么ZooKeeper被設(shè)計(jì)成CP而不是AP特性的了。

AP wihtout C

要高可用并允許分區(qū)，則需放棄一致性。一旦網(wǎng)絡(luò)問(wèn)題發(fā)生，節(jié)點(diǎn)之間可能會(huì)失去聯(lián)系。為了保證高可用，需要在用戶訪問(wèn)時(shí)可以馬上得到返回，則每個(gè)節(jié)點(diǎn)只能用本地?cái)?shù)據(jù)提供服務(wù)，而這樣會(huì)導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性。

這種舍棄強(qiáng)一致性而保證系統(tǒng)的分區(qū)容錯(cuò)性和可用性的場(chǎng)景和案例非常多。前面我們介紹可用性的時(shí)候說(shuō)到過(guò)，很多系統(tǒng)在可用性方面會(huì)做很多事情來(lái)保證系統(tǒng)的全年可用性可以達(dá)到N個(gè)9，所以，對(duì)于很多業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，比如淘寶的購(gòu)物，12306的買(mǎi)票。都是在可用性和一致性之間舍棄了一致性而選擇可用性。

你在12306買(mǎi)票的時(shí)候肯定遇到過(guò)這種場(chǎng)景，當(dāng)你購(gòu)買(mǎi)的時(shí)候提示你是有票的（但是可能實(shí)際已經(jīng)沒(méi)票了），你也正常的去輸入驗(yàn)證碼，下單了。但是過(guò)了一會(huì)系統(tǒng)提示你下單失敗，余票不足。這其實(shí)就是先在可用性方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲，會(huì)影響一些用戶體驗(yàn)，但是也不至于造成用戶流程的嚴(yán)重阻塞。

但是，我們說(shuō)很多網(wǎng)站犧牲了一致性，選擇了可用性，這其實(shí)也不準(zhǔn)確的。就比如上面的買(mǎi)票的例子，其實(shí)舍棄的只是強(qiáng)一致性。退而求其次保證了最終一致性。也就是說(shuō)，雖然下單的瞬間，關(guān)于車(chē)票的庫(kù)存可能存在數(shù)據(jù)不一致的情況，但是過(guò)了一段時(shí)間，還是要保證最終一致性的。

對(duì)于多數(shù)大型互聯(lián)網(wǎng)應(yīng)用的場(chǎng)景，主機(jī)眾多、部署分散，而且現(xiàn)在的集群規(guī)模越來(lái)越大，所以節(jié)點(diǎn)故障、網(wǎng)絡(luò)故障是常態(tài)，而且要保證服務(wù)可用性達(dá)到N個(gè)9，即保證P和A，舍棄C（退而求其次保證最終一致性）。雖然某些地方會(huì)影響客戶體驗(yàn)，但沒(méi)達(dá)到造成用戶流程的嚴(yán)重程度。

適合的才是最好的

上面介紹了如何CAP中權(quán)衡及取舍以及典型的案例。孰優(yōu)孰略，沒(méi)有定論，只能根據(jù)場(chǎng)景定奪，適合的才是最好的。

對(duì)于涉及到錢(qián)財(cái)這樣不能有一絲讓步的場(chǎng)景，C必須保證。網(wǎng)絡(luò)發(fā)生故障寧可停止服務(wù)，這是保證CP，舍棄A。比如前幾年支付寶光纜被挖斷的事件，在網(wǎng)絡(luò)出現(xiàn)故障的時(shí)候，支付寶就在可用性和數(shù)據(jù)一致性之間選擇了數(shù)據(jù)一致性，用戶感受到的是支付寶系統(tǒng)長(zhǎng)時(shí)間宕機(jī)，但是其實(shí)背后是無(wú)數(shù)的工程師在恢復(fù)數(shù)據(jù)，保證數(shù)數(shù)據(jù)的一致性。

對(duì)于其他場(chǎng)景，比較普遍的做法是選擇可用性和分區(qū)容錯(cuò)性，舍棄強(qiáng)一致性，退而求其次使用最終一致性來(lái)保證數(shù)據(jù)的安全。這其實(shí)是分布式領(lǐng)域的另外一個(gè)理論——BASE理論。我們下一篇文章再來(lái)介紹。

總結(jié)

無(wú)論你是一個(gè)架構(gòu)師，還是一個(gè)普通開(kāi)發(fā)，在設(shè)計(jì)或開(kāi)發(fā)分布式系統(tǒng)的時(shí)候，不可避免的要在CAP中做權(quán)衡。需要根據(jù)自己的系統(tǒng)的實(shí)際情況，選擇最適合自己的方案。

參考：https://www.hollischuang.com/archives/666

總結(jié)

以上是生活随笔為你收集整理的大数据开发者应该知道的分布式系统 CAP 理论的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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