分佈式系統理論基礎 - CAP

引言

CAP是分佈式系統、特別是分佈式存儲領域中被討論最多的理論，「什麼是CAP定理？」在Quora 分佈式系統分類下排名 FAQ 的 No.1。CAP在程序員中也有較廣的普及，它不只僅是「C、A、P不能同時知足，最多隻能3選2」，如下嘗試綜合各方觀點，從發展歷史、工程實踐等角度講述CAP理論。但願你們透過本文對CAP理論有更多地瞭解和認識。

 

CAP定理

CAP由Eric Brewer在2000年PODC會議上提出^[1][2]，是Eric Brewer在Inktomi^[3]期間研發搜索引擎、分佈式web緩存時得出的關於數據一致性(consistency)、服務可用性(availability)、分區容錯性(partition-tolerance)的猜測：

It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.

 

該猜測在提出兩年後被證實成立^[4]，成爲咱們熟知的CAP定理：

• 數據一致性(consistency)：若是系統對一個寫操做返回成功，那麼以後的讀請求都必須讀到這個新數據；若是返回失敗，那麼全部讀操做都不能讀到這個數據，對調用者而言數據具備強一致性(strong consistency) (又叫原子性 atomic、線性一致性 linearizable consistency)^[5]
• 服務可用性(availability)：全部讀寫請求在必定時間內獲得響應，可終止、不會一直等待
• 分區容錯性(partition-tolerance)：在網絡分區的狀況下，被分隔的節點仍能正常對外服務

 

在某時刻若是知足AP，分隔的節點同時對外服務但不能相互通訊，將致使狀態不一致，即不能知足C；若是知足CP，網絡分區的狀況下爲達成C，請求只能一直等待，即不知足A；若是要知足CA，在必定時間內要達到節點狀態一致，要求不能出現網絡分區，則不能知足P。

 

C、A、P三者最多隻能知足其中兩個，和FLP定理同樣，CAP定理也指示了一個不可達的結果(impossibility result)。

 

CAP的工程啓示

CAP理論提出七、8年後，NoSql圈將CAP理論看成對抗傳統關係型數據庫的依據、闡明本身放寬對數據一致性(consistency)要求的正確性^[6]，隨後引發了大範圍關於CAP理論的討論。

 

CAP理論看似給咱們出了一道3選2的選擇題，但在工程實踐中存在不少現實限制條件，須要咱們作更多地考量與權衡，避免進入CAP認識誤區^[7]。

 

一、關於 P 的理解

Partition字面意思是網絡分區，即因網絡因素將系統分隔爲多個單獨的部分，有人可能會說，網絡分區的狀況發生機率很是小啊，是否是不用考慮P，保證CA就好^[8]。要理解P，咱們看回CAP證實^[4]中P的定義：

In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another.

 

網絡分區的狀況符合該定義，網絡丟包的狀況也符合以上定義，另外節點宕機，其餘節點發往宕機節點的包也將丟失，這種狀況一樣符合定義。現實狀況下咱們面對的是一個不可靠的網絡、有必定機率宕機的設備，這兩個因素都會致使Partition，於是分佈式系統實現中 P 是一個必須項，而不是可選項^[9][10]。

 

對於分佈式系統工程實踐，CAP理論更合適的描述是：在知足分區容錯的前提下，沒有算法能同時知足數據一致性和服務可用性^[11]：

In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.

 

二、CA非0/1的選擇

P 是必選項，那3選2的選擇題不就變成數據一致性(consistency)、服務可用性(availability) 2選1？工程實踐中一致性有不一樣程度，可用性也有不一樣等級，在保證分區容錯性的前提下，放寬約束後能夠兼顧一致性和可用性，二者不是非此即彼^[12]。

 

CAP定理證實中的一致性指強一致性，強一致性要求多節點組成的被調要能像單節點同樣運做、操做具有原子性，數據在時間、時序上都有要求。若是放寬這些要求，還有其餘一致性類型：

• 序列一致性(sequential consistency)^[13]：不要求時序一致，A操做先於B操做，在B操做後若是全部調用端讀操做獲得A操做的結果，知足序列一致性
• 最終一致性(eventual consistency)^[14]：放寬對時間的要求，在被調完成操做響應後的某個時間點，被調多個節點的數據最終達成一致

 

可用性在CAP定理裏指全部讀寫操做必需要能終止，實際應用中從主調、被調兩個不一樣的視角，可用性具備不一樣的含義。當P(網絡分區)出現時，主調能夠只支持讀操做，經過犧牲部分可用性達成數據一致。

 

工程實踐中，較常見的作法是經過異步拷貝副本(asynchronous replication)、quorum/NRW，實如今調用端看來數據強一致、被調端最終一致，在調用端看來服務可用、被調端容許部分節點不可用(或被網絡分隔)的效果^[15]。

 

三、跳出CAP

CAP理論對實現分佈式系統具備指導意義，但CAP理論並無涵蓋分佈式工程實踐中的全部重要因素。

 

例如延時(latency)，它是衡量系統可用性、與用戶體驗直接相關的一項重要指標^[16]。CAP理論中的可用性要求操做能終止、不無休止地進行，除此以外，咱們還關心到底須要多長時間能結束操做，這就是延時，它值得咱們設計、實現分佈式系統時單列出來考慮。

 

延時與數據一致性也是一對「冤家」，若是要達到強一致性、多個副本數據一致，必然增長延時。加上延時的考量，咱們獲得一個CAP理論的修改版本PACELC^[17]：若是出現P(網絡分區)，如何在A(服務可用性)、C(數據一致性)之間選擇；不然，如何在L(延時)、C(數據一致性)之間選擇。

 

小結

以上介紹了CAP理論的源起和發展，介紹了CAP理論給分佈式系統工程實踐帶來的啓示。

 

CAP理論對分佈式系統實現有很是重大的影響，咱們能夠根據自身的業務特色，在數據一致性和服務可用性之間做出傾向性地選擇。經過放鬆約束條件，咱們能夠實如今不一樣時間點知足CAP(此CAP非CAP定理中的CAP，如C替換爲最終一致性)^[18][19][20]。

 

有很是很是多文章討論和研究CAP理論，但願這篇對你認識和了解CAP理論有幫助。

 

[1] Harvest, Yield, and Scalable Tolerant Systems, Armando Fox , Eric Brewer, 1999

[2] Towards Robust Distributed Systems, Eric Brewer, 2000

[3] Inktomi's wild ride - A personal view of the Internet bubble, Eric Brewer, 2004

[4] Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web, Seth Gilbert, Nancy Lynch, 2002

[5] Linearizability: A Correctness Condition for Concurrent Objects, Maurice P. Herlihy,Jeannette M. Wing, 1990

[6] Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking, Julian Browne, 2009

[7] CAP Theorem between Claims and Misunderstandings: What is to be Sacrificed?, Balla Wade Diack,Samba Ndiaye,Yahya Slimani, 2013

[8] Errors in Database Systems, Eventual Consistency, and the CAP Theorem, Michael Stonebraker, 2010

[9] CAP Confusion: Problems with 'partition tolerance', Henry Robinson, 2010

[10] You Can’t Sacrifice Partition Tolerance, Coda Hale, 2010

[11] Perspectives on the CAP Theorem, Seth Gilbert, Nancy Lynch, 2012

[12] CAP Twelve Years Later: How the "Rules" Have Changed, Eric Brewer, 2012

[13] How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs, Lamport Leslie, 1979

[14] Eventual Consistent Databases: State of the Art, Mawahib Elbushra , Jan Lindström, 2014

[15] Eventually Consistent, Werner Vogels, 2008

[16] Speed Matters for Google Web Search, Jake Brutlag, 2009

[17] Consistency Tradeoffs in Modern Distributed Database System Design, Daniel J. Abadi, 2012

[18] A CAP Solution (Proving Brewer Wrong), Guy's blog, 2008

[19] How to beat the CAP theorem, nathanmarz , 2011

[20] The CAP FAQ, Henry Robinson