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

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

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

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

Consistency 一致性

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

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

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

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

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

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

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

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

Availability 可用性

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

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

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

Partition Tolerance 分區容錯性

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

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

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

CAP定理的證明

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

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

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

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

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

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

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

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

1. 舍棄A，保留CP

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

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

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

2. 舍棄C，保留AP

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

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

3. 舍棄P，保留CA

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

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

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