本文轉自：https://www.cnblogs.com/bangerlee/p/5328888.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解分散式理論中的基本概念，常見演算法、以及一些較為複雜的分散式原理，同時也需要進一步瞭解zookeeper的實現，以及CAP、一致性原理等一些常見的分散式理論基礎，以便讓你更完整地瞭解分散式理論的基礎，為後續學習分散式技術內容做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

**引言**

CAP是分散式系統、特別是分散式儲存領域中被討論最多的理論，“[什麼是CAP定理？](https://www.quora.com/What-Is-CAP-Theorem-1)”在Quora 分散式系統分類下排名 FAQ 的 No.1。CAP在程式設計師中也有較廣的普及，它不僅僅是“C、A、P不能同時滿足，最多隻能3選2”，以下嘗試綜合各方觀點，從發展歷史、工程實踐等角度講述CAP理論。希望大家透過本文對CAP理論有更多地瞭解和認識。

**CAP定理**

CAP由[Eric Brewer](https://en.wikipedia.org/wiki/Eric_Brewer_(scientist))在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)。

![](https://images2015.cnblogs.com/blog/116770/201603/116770-20160329205542613-1908405713.jpg)

**CAP的工程啟示**

CAP理論提出7、8年後，NoSql圈將CAP理論當作對抗傳統關係型資料庫的依據、闡明自己放寬對資料一致性(consistency)要求的正確性[6]，隨後引起了大範圍關於CAP理論的討論。

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

**1、關於 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.

**2、CA非0/1的選擇**

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

![](https://images2015.cnblogs.com/blog/116770/201604/116770-20160401221124957-2025686892.jpg)

CAP定理證明中的一致性指強一致性，強一致性要求多節點組成的被調要能像單節點一樣運作、操作具備原子性，資料在時間、時序上都有要求。如果放寬這些要求，還有其他一致性型別：

* 序列一致性(sequential consistency)[13]：不要求時序一致，A操作先於B操作，在B操作後如果所有呼叫端讀操作得到A操作的結果，滿足序列一致性
* 最終一致性(eventual consistency)[14]：放寬對時間的要求，在被調完成操作響應後的某個時間點，被調多個節點的資料最終達成一致

可用性在CAP定理裡指所有讀寫操作必須要能終止，實際應用中從主調、被調兩個不同的視角，可用性具有不同的含義。當P(網路分割槽)出現時，主調可以只支援讀操作，透過犧牲部分可用性達成資料一致。

工程實踐中，較常見的做法是透過非同步複製副本(asynchronous replication)、quorum/NRW，實現在呼叫端看來資料強一致、被調端最終一致，在呼叫端看來服務可用、被調端允許部分節點不可用(或被網路分隔)的效果[15]。

**3、跳出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](https://cs.uwaterloo.ca/~brecht/servers/readings-new2/harvest-yield.pdf), Armando Fox , Eric Brewer, 1999

[2] [Towards Robust Distributed Systems](http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf), Eric Brewer, 2000

[3] [Inktomi's wild ride - A personal view of the Internet bubble](https://www.youtube.com/watch?v=E91oEn1bnXM), Eric Brewer, 2004

[4] [Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web](https://pdfs.semanticscholar.org/24ce/ce61e2128780072bc58f90b8ba47f624bc27.pdf), Seth Gilbert, Nancy Lynch, 2002

[5] [Linearizability: A Correctness Condition for Concurrent Objects](http://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf), Maurice P. Herlihy,Jeannette M. Wing, 1990

[6] [Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking](http://julianbrowne.com/article/viewer/brewers-cap-theorem), Julian Browne, 2009

[7] [CAP Theorem between Claims and Misunderstandings: What is to be Sacrificed?](http://www.sersc.org/journals/IJAST/vol56/1.pdf), Balla Wade Diack,Samba Ndiaye,Yahya Slimani, 2013

[8] [Errors in Database Systems, Eventual Consistency, and the CAP Theorem](http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext), Michael Stonebraker, 2010

[9] [CAP Confusion: Problems with 'partition tolerance'](http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/), Henry Robinson, 2010

[10] [You Can’t Sacrifice Partition Tolerance](https://codahale.com/you-cant-sacrifice-partition-tolerance/), Coda Hale, 2010

[11] [Perspectives on the CAP Theorem](https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf), Seth Gilbert, Nancy Lynch, 2012

[12] [CAP Twelve Years Later: How the "Rules" Have Changed](https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2012/0512/T_CO2_CAP12YearsLater.pdf), Eric Brewer, 2012

[13] [How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs](http://research.microsoft.com/en-us/um/people/lamport/pubs/multi.pdf), Lamport Leslie, 1979

[14] [Eventual Consistent Databases: State of the Art](http://www.ronpub.com/publications/OJDB-v1i1n03_Elbushra.pdf), Mawahib Elbushra , Jan Lindström, 2014

[15] [Eventually Consistent](http://www.allthingsdistributed.com/2008/12/eventually_consistent.html), Werner Vogels, 2008

[16] [Speed Matters for Google Web Search](http://www.isaacsunyer.com/wp-content/uploads/2009/09/test_velocidad_google.pdf), Jake Brutlag, 2009

[17] [Consistency Tradeoffs in Modern Distributed Database System Design](http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf), Daniel J. Abadi, 2012

[18] [A CAP Solution (Proving Brewer Wrong)](http://guysblogspot.blogspot.com/2008/09/cap-solution-proving-brewer-wrong.html), Guy's blog, 2008

[19] [How to beat the CAP theorem](http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html), nathanmarz , 2011

[20] [The CAP FAQ](https://github.com/henryr/cap-faq), Henry Robinson

分散式系統理論基礎2 ：CAP

相關文章