?? ? ?最近在學習消息中間件的時候，接觸到了分布式系統，進而接觸到CAP理論，上一次接觸還是在年初的時候公司的技術分享會上，有人在介紹項目的時候簡單介紹了這個CAP理論，但并沒有深入研究。這次，該是時候研究一下這個CAP原則到底是個啥了。
? ? ? ?其實，CAP理論在大部分的開發者心里都有一定的位置，在互聯網界也有廣泛的知名度，稍微經驗豐富或者知識廣泛的程序員都會把它作為衡量一個系統，尤其是分布式系統的設計準則，也就是我們說的CAP原則。大家都非常清晰的知道：任何的分布式系統，在可用性、一致性和分區容錯性方面，是不可兼得的，就像是我們常說的“魚和熊掌不可兼得”一樣，最多值能得其二。所以說，任何一個分布式系統的設計，都是根據各自的實際應用場景和需求，對這三個維度的的不同取舍而已。
?
? ? ? ?說了這么多，大家可能還是比較懵逼。到底什么是CAP原則？下面先知道下它的定義：
?

CAP原則又稱CAP定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。換句話說，就是說在一個系統中對某個數據不存在一個算法同時滿足 Consistency, Availability, Partition-tolerance。

?
? ? ? ?定義就是定義，一句話，就把上面的一大段廢話說的清晰明了！那可能接下來，又來了個“三臉懵逼”，到底啥是一致性、可用性和分區容錯性？同樣的，上定義：
?

●?一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。一致性被稱為原子對象，任何的讀寫都應該看起來是“原子“的，或串行的。（等同于所有節點訪問同一份最新的數據副本）
● 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
● 分區容錯性（P）：以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

?
? ? ? ?現在大家應該對這些基本概念有了一個比較清晰的認識。那我們在深入理解CAP原則之前，先了解下CAP原則的前世今生。
?
為什么會產生這個CAP理論？
?
? ? ? ?1985年Lynch證明了異步通信中不存在任何一致性的分布式算法（FLP Impossibility）的同時，人們就開始尋找分布式系統設計的各種因素。一致性算法既然不存在，但若能找到一些設計因素，并進行適當的取舍以最大限度滿足實現系統需求成為當時的重要議題。比如，在CAP之前研究者就已經發現低延遲和順序一致性不可能同時被滿足。
? ? ? ?2000年，Eric Brewer教授在PODC的研討會上提出了一個猜想：一致性、可用性和分區容錯性三者無法在分布式系統中被同時滿足，并且最多只能滿足其中兩個！這個猜想首次把一致性、可用性和分區容錯三個因素提煉出來作為系統設計的重要特征，斷言用此三者可以劃分所有的分布式系統，并指明這三個特征之間的不可能性關系。Brewer猜想比單純的“低延遲和順序一致性不能被同時滿足”的結論更具體，對實際系統的構建也更具有可操作性！Brewer教授當時想象的分布式場景是webservice，一組websevrice后臺運行著眾多的server，對service的讀寫會反應到后臺的server集群，并對CAP進行了定義，就是上面列出的定義。高可用、數據一致是很多系統設計的目標，但是分區又是不可避免的事情，CAP的出現仿佛是一盞明燈，它揭露了分布式系統的本質，并給出了設計的準則，而這正是1985年以來人們正在尋找的東西！所以CAP在當時的影響力是非常大的！
? ? ? ?2002年，Lynch與其他人證明了Brewer猜想，從而把CAP上升為一個定理。
?
這么一帆風順嗎？直至今日，對CAP理論的質疑聲不斷
?
? ? ? ?就在這些理論被踢出來，大家覺得終于對分布式系統設計有了指導原則的時候，有些工程師和研究者就對CAP提出了各種質疑，紛紛有用反例證明著CAP在各種場合不適用性，同時挑戰著Lynch的證明結果！你是否看了CAP的概念定義后還是感覺很模糊？如果是，你并不孤獨，有很多人都是如此！CAP沒有考慮不同的基礎架構、不同的應用場景、不同的網絡基礎和用戶需求，而C、A、P在這些不同場景中的含義可能完全不同，這種無視差異化的定義導致了非常大的概念模糊，同時也變成CAP被質疑的源頭！

? ? ? ?其中，這些質疑主要集中在以下幾個方面：
?

• 概念模糊混亂，廢話一堆，不能作為定理

• 不適用于數據庫事務架構

• 應該構建不可變模型避免CAP的復雜性

• 分區容錯概念有誤導

?
? ? ? ?其實，搞了半天，我也不是很清晰這些高大上的推論和證明，也不是我們該操心的，因為CAP理論的提出者和證明者也在后續對這些質疑進行了相應的“回擊”！
?
回擊和解釋
?
? ? ? ?面對大量的質疑，Brewer和Lynch終于坐不住了，因此兩人紛紛出來澄清。Brewer于2012年重申”3個中的2個“這個表述是不準確的，在某些分區極少發生的情況下，三者能順暢地在一起配合，而且CAP不僅僅是發生在整個系統中，可能是發生在某個子系統或系統的某個階段。
? ? ? ?Lynch也在10年后的2012年重寫了論文，縮小CAP適用的定義，消除質疑的場景，展示了CAP在非單一一致性結果下的廣闊的研究結果！并順便暗示CAP定理依舊正確！
?
? ? ? ?多么精彩的“撕逼”過程！但是對我們來說，真正有意義的還是CAP理論本身。
?
我們該如何看待CAP理論本身？
?
? ? ? ?首先肯定的是，CAP并不適合再作為一個適應任何場景的定理，它的正確性更加適合基于原子讀寫的NoSQL場景。質疑雖然很多，但很多質疑者只是偷歡概念，并沒有解決各個因素之間的取舍問題。而無論如何C、A、P這個三個概念始終存在任何分布式系統，只是不同的模型會對其有不同的呈現，可能某些場景對三者之間的關系敏感，而另一些不敏感。就像Lynch所說，現在分布式系統有很多特性，比如擴展性、優雅降級等，隨著時間的發展，或許這些也會被納入研究范疇，而作為開發者，這都是我們需要考慮的問題，而不僅是CAP三者！
?
對CAP三者的選擇
?
? ? ? ?當處理CAP的問題時，你會有幾個選擇。最明顯的是：

?
1.（CA）放棄Partition Tolerance：
如果你想避免partition問題發生，你就必須要阻止其發生。一種做法是將所有的東西（與事務相關的）都放到一臺機器上。或者放在像rack這類的atomically-failling單元上。無法100%地保證，因為還是有可能部分失敗，但你不太可能碰到由partition問題帶來的負面效果。當然，這個選擇會嚴重影響scale限制。

2.（CP）放棄Availability：
相對于放棄partition tolerance來說，其反面就是放棄availability。一旦遇到partition 事件，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務。在多個節點上控制這一點會相當復雜，而且恢復的節點需要處理邏輯，以便平滑地返回服務狀態。

3.（AP）放棄Consistency：
或者如同Werner Vogels所提倡的，接受事情會變得“最終一致（Eventually Consistent）”（2008年12月更新）。Vogels的文章值得一讀。他比我在這里討論了更多的操作方面的細節。許多的不一致性并不比你想的需要更多的工作（意味著持續的consistency或許并不是我們所需要的）。在購書的例子中，如果一本庫存的書，接到了2個訂單，第二個就會成為備份訂單。只要告知客戶這種情況（請記住這是一種罕見的情況），也許每個人都會高興的。
?

?
總結
?
? ? ? ?在Consistency, Availability和Partition-tolerance中，你只能保證2點，這是確實的，并且已經被這個星球上最成功的網站證實了。如果對網站是有效的，我看不出在企業環境中，在日常的工作中，不考慮同樣的折衷設計的理由。當然，CAP理論也只是對我們的分布式系統設計起到一個指導性的作用，我們在設計系統時，要考慮的方面也絕非只有這三個方面，正如上文所提到的，擴展性、降級等也是我們需要考慮的內容，所有，只有結合實際的業務需求和使用場景，才能設計出更加合適的系統。

參考資料：
1、http://blog.csdn.net/chen77716/article/details/30635543
2、http://blog.sina.com.cn/s/blog_493a8455010161hi.html

相關文章：

• 分布式一致性算法：Raft 算法

• 分布式系列文章——Paxos算法原理與推導

• 分布式基礎通信協議:paxos,totem和gossip
  

原文地址：https://ask.zkbhj.com/?/article/61

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的你真的理解CAP理论吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。