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

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

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

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

Consistency 一致性

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

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

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

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

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

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

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

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

Availability 可用性

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

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

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

Partition Tolerance 分區(qū)容錯性

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

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

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

CAP定理的證明

關(guān)于CAP這三個特性我們就介紹完了，接下來我們試著證明一下為什么CAP不能同時滿足。

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

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

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

我們做個假象實驗，如下圖，突然某一時刻N1和N2之間的關(guān)聯(lián)斷開：

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

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

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

1. 舍棄A，保留CP

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

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

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

2. 舍棄C，保留AP

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

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

3. 舍棄P，保留CA

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

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

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