聊一聊分布式系統(tǒng)的CAP理論

分布式系統(tǒng)當(dāng)中有一個(gè)著名的CAP理論，它也是分布式系統(tǒng)理論的基礎(chǔ)。

CAP理論最早發(fā)表于2000年，由加州伯克利的教授首先在ACM PODC會(huì)議上提出猜想，兩年之后，被麻省理工學(xué)院的教授Seth Gilbert和Nancy Lynch從理論上證明。從此之后，它成了分布式系統(tǒng)領(lǐng)域的公認(rèn)定理。

今天這篇文章就和大家聊聊這個(gè)大名鼎鼎的CAP理論。

CAP理論描述起來其實(shí)很簡(jiǎn)單，它說的是一個(gè)分布式系統(tǒng)最多只能滿足C（一致性）、A（可用性）和P（分區(qū)性）這三者當(dāng)中的兩個(gè)。我們先來看一下這三項(xiàng)分別代表了什么。

Consistency 一致性

分布式系統(tǒng)當(dāng)中的一致性指的是所有節(jié)點(diǎn)的數(shù)據(jù)一致，或者說是所有副本的數(shù)據(jù)一致。用英文描述是：All the nodes see the same data at the same time。它和數(shù)據(jù)庫事務(wù)中的一致性是兩碼事，在我們之前的文章里，曾經(jīng)詳細(xì)描述過分布式系統(tǒng)中的各種一致性模型，感興趣的同學(xué)可以點(diǎn)擊這里。

我們可以將一致性一分為二，分別從客戶端和服務(wù)端進(jìn)行探究。對(duì)于客戶端而言，并不關(guān)心后端的實(shí)現(xiàn)，也不關(guān)心后端的節(jié)點(diǎn)運(yùn)行情況。唯一只關(guān)心多次并發(fā)訪問下都能獲得準(zhǔn)確的符合預(yù)期的結(jié)果。比如用戶多次點(diǎn)擊付款，也只會(huì)付款一次，余額無論什么時(shí)候查詢都是當(dāng)下最新的值。

而服務(wù)端關(guān)心的是會(huì)引發(fā)數(shù)據(jù)變更的請(qǐng)求過來，能夠及時(shí)準(zhǔn)確地同步到所有的節(jié)點(diǎn)和副本，并且考慮可能會(huì)出現(xiàn)的網(wǎng)絡(luò)以及通信問題，保證極端情況下依舊不會(huì)產(chǎn)生錯(cuò)誤。

在分布式系統(tǒng)當(dāng)中，針對(duì)不同情況以及不同要求下的一致性，設(shè)計(jì)了多種不同的模型。我們可以簡(jiǎn)單做一個(gè)總結(jié)，將它們分為三類：

1. 要求當(dāng)下更新成功的數(shù)據(jù)立即生效，在后續(xù)的訪問當(dāng)中都能返回最新的結(jié)果。這是強(qiáng)一致性。

2. 如果能容忍在更新發(fā)生之后，部分情況無法訪問到最新數(shù)據(jù)，這是弱一致性。

3. 如果能容忍更新后一段時(shí)間內(nèi)無法訪問到最新數(shù)據(jù)，但最終可以保證結(jié)果準(zhǔn)確，這是最終一致性。

在CAP理論當(dāng)中，我們說的無法同時(shí)滿足的一致性指的是強(qiáng)一致性。

Availability 可用性

可用性指的是：Reads and writes always succeed. 也就是說系統(tǒng)一直可用，而且服務(wù)一直保持正常。

一個(gè)高可用性的分布式系統(tǒng)，必須對(duì)用戶的每一個(gè)請(qǐng)求做出響應(yīng)。不可以出現(xiàn)無法訪問或者是響應(yīng)超時(shí)等影響用戶體驗(yàn)的情況。在一個(gè)分布式系統(tǒng)當(dāng)中，任何一個(gè)節(jié)點(diǎn)的不穩(wěn)定，都有可能影響系統(tǒng)的可用性，比如數(shù)據(jù)庫服務(wù)器、負(fù)載均衡，web服務(wù)器承載等等。為了量化系統(tǒng)的可用性，我們通常使用系統(tǒng)停機(jī)時(shí)間這個(gè)指標(biāo)。即在一年時(shí)間內(nèi)，系統(tǒng)停機(jī)的總時(shí)長(zhǎng)。

據(jù)說淘寶可以做到5個(gè)9，也就是99.999%的時(shí)間內(nèi)可用。算下來全年系統(tǒng)停機(jī)的時(shí)間不會(huì)超過5分鐘，這是非常難以做到的。

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

分區(qū)容錯(cuò)性指的是：System continues operating despire arbitrary message loss or failure of part of the system. 翻譯過來就是說系統(tǒng)在遇到一些節(jié)點(diǎn)或者網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠提供滿足一致性和可用性的服務(wù)。

分區(qū)容錯(cuò)性和拓展性息息相關(guān)，因?yàn)樵酱蟮姆植际较到y(tǒng)越有可能出現(xiàn)機(jī)器宕機(jī)，網(wǎng)絡(luò)阻塞等情況。即使這些意外情況發(fā)生，系統(tǒng)仍然能保持穩(wěn)定是系統(tǒng)拓展的前提。在分布式系統(tǒng)當(dāng)中出現(xiàn)的問題可能性很多，既可能出現(xiàn)部分機(jī)器宕機(jī)，也有可能出現(xiàn)內(nèi)網(wǎng)阻隔，使得整個(gè)集群被拆分成互相不能通信的幾個(gè)部分。分區(qū)容錯(cuò)性需要保證即使這些情況發(fā)生，系統(tǒng)也一樣可以保證一致性和可用性。

舉個(gè)例子，阿里經(jīng)常做機(jī)房斷電實(shí)驗(yàn)，實(shí)驗(yàn)的時(shí)候直接把一個(gè)機(jī)房的電源切斷，觀察這個(gè)時(shí)候系統(tǒng)是否仍然能夠保持穩(wěn)定。

CAP定理的證明

關(guān)于CAP這三個(gè)特性我們就介紹完了，接下來我們?cè)囍C明一下為什么CAP不能同時(shí)滿足。

為了簡(jiǎn)化證明的過程，我們假設(shè)整個(gè)集群里只有兩個(gè)N1和N2兩個(gè)節(jié)點(diǎn)，如下圖：

N1和N2當(dāng)中各自有一個(gè)應(yīng)用程序AB和數(shù)據(jù)庫，當(dāng)系統(tǒng)滿足一致性的時(shí)候，我們認(rèn)為N1和N2數(shù)據(jù)庫中的數(shù)據(jù)保持一致。在滿足可用性的時(shí)候，我們認(rèn)為無論用戶訪問N1還是N2，都可以獲得正確的結(jié)果，在滿足分區(qū)容錯(cuò)性的時(shí)候，我們認(rèn)為無論N1還是N2宕機(jī)或者是兩者的通信中斷，都不影響系統(tǒng)的運(yùn)行。

我們假設(shè)一種極端情況，假設(shè)某個(gè)時(shí)刻N(yùn)1和N2之間的網(wǎng)絡(luò)通信突然中斷了。如果系統(tǒng)滿足分區(qū)容錯(cuò)性，那么顯然可以支持這種異常。問題是在此前提下，一致性和可用性是否可以做到不受影響呢？

我們做個(gè)假象實(shí)驗(yàn)，如下圖，突然某一時(shí)刻N(yùn)1和N2之間的關(guān)聯(lián)斷開：

有用戶向N1發(fā)送了請(qǐng)求更改了數(shù)據(jù)，將數(shù)據(jù)庫從V0更新成了V1。由于網(wǎng)絡(luò)斷開，所以N2數(shù)據(jù)庫依然是V0，如果這個(gè)時(shí)候有一個(gè)請(qǐng)求發(fā)給了N2，但是N2并沒有辦法可以直接給出最新的結(jié)果V1，這個(gè)時(shí)候該怎么辦呢？

這個(gè)時(shí)候無法兩種方法，一種是將錯(cuò)就錯(cuò)，將錯(cuò)誤的V0數(shù)據(jù)返回給用戶。第二種是阻塞等待，等待網(wǎng)絡(luò)通信恢復(fù)，N2中的數(shù)據(jù)更新之后再返回給用戶。顯然前者犧牲了一致性，后者犧牲了可用性。

這個(gè)例子雖然簡(jiǎn)單，但是說明的內(nèi)容卻很重要。在分布式系統(tǒng)當(dāng)中，CAP三個(gè)特性我們是無法同時(shí)滿足的，必然要舍棄一個(gè)。三者舍棄一個(gè)，顯然排列組合一共有三種可能。

1. 舍棄A，保留CP

一個(gè)系統(tǒng)保證了一致性和分區(qū)容錯(cuò)性，舍棄可用性。也就是說在極端情況下，允許出現(xiàn)系統(tǒng)無法訪問的情況出現(xiàn)，這個(gè)時(shí)候往往會(huì)犧牲用戶體驗(yàn)，讓用戶保持等待，一直到系統(tǒng)數(shù)據(jù)一致了之后，再恢復(fù)服務(wù)。

對(duì)于有些系統(tǒng)而言，一致性是安身立命之本，比如Hbase、Redis這種分布式存儲(chǔ)，數(shù)據(jù)一致性是最基本的要求。不滿足一致性的存儲(chǔ)顯然不會(huì)有用戶愿意使用。

ZooKeeper也是一樣，任何時(shí)候訪問ZK都可以獲得一致性的結(jié)果。它的職責(zé)就是保證管轄下的服務(wù)保持同步和一致，顯然不可能放棄一致性。但是在極端情況下，ZK可能會(huì)丟棄調(diào)一些請(qǐng)求，消費(fèi)者需要重新請(qǐng)求才能獲得結(jié)果。

2. 舍棄C，保留AP

這種是大部分的分布式系統(tǒng)的設(shè)計(jì)，保證高可用和分區(qū)容錯(cuò)，但是會(huì)犧牲一致性。比如淘寶購物以及12306購票等等，前面說過淘寶可以做到全年可用性5個(gè)9的超高級(jí)別，但是此時(shí)就無法保證數(shù)據(jù)一致性了。

舉個(gè)例子，我們?cè)?2306買票的時(shí)候就經(jīng)常會(huì)遇到。在我們點(diǎn)擊購買的時(shí)候，系統(tǒng)并沒有提示沒票。等我們輸入了驗(yàn)證碼，付款的時(shí)候才會(huì)告知，已經(jīng)沒有票了。這就是因?yàn)槲覀冊(cè)邳c(diǎn)擊購買的時(shí)候，數(shù)據(jù)沒有達(dá)成一致性，在付款校驗(yàn)的時(shí)候才檢驗(yàn)出余票不足。這種設(shè)計(jì)會(huì)犧牲一些用戶體驗(yàn)，但是可以保證高可用，讓用戶不至于無法訪問或者是長(zhǎng)時(shí)間等待，也算是一種取舍吧。

3. 舍棄P，保留CA

很遺憾，這種情況幾乎不存在。因?yàn)榉植际较到y(tǒng)，網(wǎng)絡(luò)分區(qū)是必然的。如果要舍棄P，那么就是要舍棄分布式系統(tǒng)，CAP也就無從談起了?？梢哉fP是分布式系統(tǒng)的前提，所以這種情況是不存在的。

比如一般的關(guān)系型數(shù)據(jù)庫，像是MySQL或者是Oracle，它們都保證了一致性和可用性，但是并不是分布式系統(tǒng)。從這點(diǎn)上來說CAP并不是等價(jià)的，我們并不能通過犧牲CA來提升P。要想提升分區(qū)容錯(cuò)性，只能通過提升基礎(chǔ)設(shè)施的穩(wěn)定性來達(dá)到。也就是說這并不是一個(gè)軟件問題。

到這里CAP的理論就介紹完了，到最后會(huì)發(fā)現(xiàn)這其實(shí)是一個(gè)取舍問題，并沒有完美的方案。每個(gè)設(shè)計(jì)分布式系統(tǒng)的架構(gòu)師，需要根據(jù)自身業(yè)務(wù)場(chǎng)景的實(shí)際特性來考量。比如，像是涉及到金錢的問題，一致性是必須的，極端情況下，哪怕用戶暫時(shí)無法訪問， 也不能使得相關(guān)的數(shù)據(jù)不準(zhǔn)確。這不僅會(huì)影響一個(gè)公司的聲譽(yù)，也會(huì)帶來許多其他方面的困擾。