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

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

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

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

Consistency 一致性

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

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

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

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

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

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

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

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

Availability 可用性

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

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

據(jù)說淘寶可以做到5個9，也就是99.999%的時間內可用。算下來全年系統(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)絡分區(qū)故障的時候，仍然能夠提供滿足一致性和可用性的服務。

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

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

CAP定理的證明

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

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

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

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

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

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

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

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

1. 舍棄A，保留CP

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

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

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

2. 舍棄C，保留AP

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

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

3. 舍棄P，保留CA

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

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

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