本文首發于 Computer 雜志，由InfoQ和IEEE呈現給您。 CAP理論斷言任何基于網絡的數據共享系統，最多只能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。但是通過顯式處理分區情形，系統設計師可以做到優化數據一致性和可用性，進而取得三者之間的平

本文首發于  Computer 雜志，由InfoQ和IEEE呈現給您。

CAP理論斷言任何基于網絡的數據共享系統，最多只能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。但是通過顯式處理分區情形，系統設計師可以做到優化數據一致性和可用性，進而取得三者之間的平衡。

自打引入CAP理論的十幾年里，設計師和研究者已經以它為理論基礎探索了各式各樣新穎的分布式系統，甚至到了濫用的程度。NoSQL運動也將CAP理論當作對抗傳統關系型數據庫的依據。

CAP理論主張任何基于網絡的數據共享系統，都最多只能擁有以下三條中的兩條：

CAP理論的表述很好地服務了它的目的，即開闊設計師的思路，在多樣化的取舍方案下設計出多樣化的系統。在過去的十幾年里確實涌現了不計其數的新系統，也隨之在數據一致性和可用性的相對關系上產生了相當多的爭論?！叭x二”的公式一直存在著誤導性，它會過分簡單化各性質之間的相互關系?，F在我們有必要辨析其中的細節。實際上只有“在分區存在的前提下呈現完美的數據一致性和可用性”這種很少見的情況是CAP理論不允許出現的。

雖然設計師仍然需要在分區的前提下對數據一致性和可用性做取舍，但具體如何處理分區和恢復一致性，這里面有不計其數的變通方案和靈活度。當代CAP實踐應將目標定為針對具體的應用，在合理范圍內最大化數據一致性和可用性的“合力”。這樣的思路延伸為如何規劃分區期間的操作和分區之后的恢復，從而啟發設計師加深對CAP的認識，突破過去由于CAP理論的表述而產生的思維局限。

理解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了C性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那么又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質。一般來說跨區域的系統，設計師無法舍棄P性質，那么就只能在數據一致性和可用性上做一個艱難選擇。不確切地說，NoSQL運動的主題其實是創造各種可用性優先、數據一致性其次的方案；而傳統數據庫堅守ACID特性（原子性、一致性、隔離性、持久性），做的是相反的事情。下文“ACID、BASE、CAP”小節詳細說明了它們的差異。

事實上，CAP理論本身就是在類似的討論中誕生的。早在1990年代中期，我和同事構建了一系列的基于集群的跨區域系統（實質上是早期的云計算），包括搜索引擎、緩存代理以及內容分發系統1。從收入目標以及合約規定來講，系統可用性是首要目標，因而我們常規會使用緩存或者事后校核更新日志來優化系統的可用性。盡管這些策略提升了系統的可用性，但這是以犧牲系統數據一致性為代價的。

關于“數據一致性 VS 可用性”的第一回合爭論，表現為ACID與BASE之爭2。當時BASE還不怎么被人們接受，主要是大家看重ACID的優點而不愿意放棄。提出CAP理論，目的是證明有必要開拓更廣闊的設計空間，因此才有了“三選二”公式。CAP理論最早在1998年秋季提出，1999年正式發表3，并在2000年登上Symposium on Principles of Distributed Computing大會的主題演講4，最終確立了該理論的正確性。

“三選二”的觀點在幾個方面起了誤導作用，詳見下文“CAP之惑”小節的解釋。首先，由于分區很少發生，那么在系統不存在分區的情況下沒什么理由犧牲C或A。其次，虛擬主機，C與A之間的取舍可以在同一系統內以非常細小的粒度反復發生，而每一次的決策可能因為具體的操作，乃至因為牽涉到特定的數據或用戶而有所不同。最后，這三種性質都可以在程度上衡量，并不是非黑即白的有或無?？捎眯燥@然是在0%到100%之間連續變化的，一致性分很多級別，連分區也可以細分為不同含義，如系統內的不同部分對于是否存在分區可以有不一樣的認知。

要探索這些細微的差別，就要突破傳統的分區處理方式，而這是一項根本性的挑戰。因為分區很少出現，CAP在大多數時候允許完美的C和A。但當分區存在或可感知其影響的情況下，就要預備一種策略去探知分區并顯式處理其影響。這樣的策略應分為三個步驟：探知分區發生，進入顯式的分區模式以限制某些操作，啟動恢復過程以恢復數據一致性并補償分區期間發生的錯誤。

ACID和BASE代表了兩種截然相反的設計哲學，分處一致性-可用性分布圖譜的兩極。ACID注重一致性，香港服務器，是數據庫的傳統設計思路。我和同事在1990年代晚期提出BASE，目的是抓住當時正逐漸成型的一些針對高可用性的設計思路，并且把不同性質之間的取舍和消長關系擺上臺面。現代大規?？鐓^域分布的系統，包括云在內，同時運用了這兩種思路。

這兩個術語都好記有余而精確不足，出現較晚的BASE硬湊的感覺更明顯，它是“Basically Available, Soft state, Eventually consistent（基本可用、軟狀態、最終一致性）”的首字母縮寫。其中的軟狀態和最終一致性這兩種技巧擅于對付存在分區的場合，并因此提高了可用性。

CAP與ACID的關系更復雜一些，也因此引起更多誤解。其中一個原因是ACID的C和A字母所代表的概念不同于CAP的C和A。還有一個原因是選擇可用性只部分地影響ACID約束。ACID四項特性分別為：

原子性（A）。所有的系統都受惠于原子性操作。當我們考慮可用性的時候，沒有理由去改變分區兩側操作的原子性。而且滿足ACID定義的、高抽象層次的原子操作，實際上會簡化分區恢復。

一致性（C）。ACID的C指的是事務不能破壞任何數據庫規則，如鍵的唯一性。與之相比，CAP的C僅指單一副本這個意義上的一致性，因此只是ACID一致性約束的一個嚴格的子集。ACID一致性不可能在分區過程中保持，因此分區恢復時需要重建ACID一致性。推而廣之，分區期間也許不可能維持某些不變性約束，所以有必要仔細考慮哪些操作應該禁止，分區后又如何恢復這些不變性約束。

隔離性（I）。隔離是CAP理論的核心：如果系統要求ACID隔離性，那么它在分區期間最多可以在分區一側維持操作。事務的可串行性（serializability）要求全局的通信，因此在分區的情況下不能成立。只要在分區恢復時進行補償，在分區前后保持一個較弱的正確性定義是可行的。

持久性（D）。犧牲持久性沒有意義，理由和原子性一樣，雖然開發者有理由（持久性成本太高）選擇BASE風格的軟狀態來避免實現持久性。這里有一個細節，分區恢復可能因為回退持久性操作，而無意中破壞某項不變性約束。但只要恢復時給定分區兩側的持久性操作歷史記錄，破壞不變性約束的操作還是可以被檢測出來并修正的。通常來講，讓分區兩側的事務都滿足ACID特性會使得后續的分區恢復變得更容易，并且為分區恢復時事務的補償工作奠定了基本的條件。

CAP理論的經典解釋，是忽略網絡延遲的，但在實際中延遲和分區緊密相關。CAP從理論變為現實的場景發生在操作的間歇，系統需要在這段時間內做出關于分區的一個重要決定：

最后一步的目的是恢復一致性，以及補償在系統分區期間程序產生的錯誤。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com