關於CAP原理的討論很多，而且通常會在分布式系統中產生誤解。它規定：任何連網和分享數據的系統最多可以保證以下三個屬性的兩個：一致性、可用性和分區容錯性。我在此不會詳細介紹CAP，因為它涉及的方面很多，但是“三個中的兩個”肯定是有誤導性的——雖然概念上很容易理解。Brewer曾經指出這個問題，而且認同的聲音很多，但是人們對於這個話題仍然存在很多的爭議。底線是你不能犧牲分區容錯性，但是似乎CAP在這個方面有一些偏差。
表面上，CAP將系統分成了三類。CA表示一個在保持一致性和可用性前提下實現完美可選性的網絡系統。CP在犧牲一定可用性的前提下實現一致性和分區容錯性，而AP則不考慮線性一致性的前提下實現可用性和分區容錯性。顯然，CA暗示系統只有在不存在網絡分區時才保證一致性和可用性。然而，要說完全不存在網絡分區，這顯然是不太現實的。這正是許多爭議發生的根源。
分區一定有。它們的出現有很多的原因。交換故障、NIC故障、鏈路層故障、服務器故障、進程故障等，都可能導致分區出現。即使系統不發生故障，也有其他原因可能引起分區，例如GC暫停或長時間延遲。我們要先接受這個事實，然後再繼續分析。這意味著，只有當一個“CA”系統變為不CA時，它才是CA的。一旦出現分區，所有假設和所有保證都會以某一種方式產生嚴重後果。什麼位置不會出現這個問題呢?
CAP的核心在於平衡折衷，但是它是一個排他原則。它告訴我們系統在特定的現實條件下不能做什麼?這其中的區別是並非所有系統都能很好地符合這些模型。如果說Jepsen曾經教會我們什麼，那麼一定是讓我們知道大多數系統都不符合這些分類，即使當初設計者說是符合的。在實踐中，CAP並不是只有黑白兩面。
Nicolas Liochon最近寫了一系列非常不錯的CAP文章。他很好地解釋了這個既晦澀又容易誤解的術語(比我解釋得好多了)，並且提出了一些非常有意義的觀點。Nicolas認為，CA實際上應該看作為一種運營范疇的規范，而CP和AP則是關於行為的描述。我認同這一點，但是我的問題是它回避了一定會出現的平衡折衷。
我們知道網絡分區是無法避免的。如果我們給應用程序這樣的規定：“這個應用程序不會處理網絡分區。如果出現網絡分區，那麼應用程序將部分失效，數據可能受到破壞，而且你可能不得不手工修復數據。”換而言之，我們在這裡實際上要求的是CA，但是如果有一個分區出現，那麼就可能屬於CP;或者說，很不幸地同時失去了可用性和一致性。
在運營范疇內，CA實際上意味著當出現一個分區時，系統會攤開雙手並發出信息：“我拋錨了!”如果我們指定系統不能在網絡分區下正常工作，也就是說分區不在運營范疇之內。我們在地球上給一個設計飛往他拉星球大氣層的太空飛船指定一個規范有什麼意義呢?我們處於一個分區普遍存在的世界中，因此我們肯定要在運營范疇中支持分區。CA確定規定了一個運營范疇，但是你不能將它寫到SLA然後交給客戶看。通俗地說，在沒有定義的時候，它只是一種“未定義行為”模式 ——系統是一致和可用的。CAP並不是一個完美的概念，但是在我看來，它確實很好地強調了構建分布式系統過程中需要考慮的一些基本折衷問題。無論我們有沒有在書面寫下來，它們都存在。如果寫下來了，我們也無法保證可用性。在面對分區時，CAP似乎只能在一致性和可用性上面二選一。事實上，這裡並不是只有兩個選擇。你可以選擇AP、CP或兩者都不選。兩者都不選的問題是，我們很難推出它的原因，甚至很難給它定義。最終，它只是一種選擇假象，因為我們不可能犧牲分區容錯性。
