CAP原理的讨论很多，在分布式系统中通常会引起误解。它指出，任何联网并共享数据的系统最多只能保证以下三个属性中的两个：一致性、可用性和分区容错性。我不会在这里详细介绍CAP，因为要涵盖的内容很多，但“三分之二”肯定会产生误导——尽管从概念上讲很容易理解。布鲁尔曾经指出过这个问题，赞同的声音很多，但人们对这个话题还是有很多争议。底线是您不能牺牲分区容错性，但CAP在这方面似乎有点偏离。从表面上看，CAP将系统分为三类。CA代表了一个在保持一致性和可用性的同时实现完美可选性的网络系统。CP是在牺牲一定可用性的前提下实现一致性和分区容错，而AP是在不考虑线性一致性的情况下实现可用性和分区容错。显然，CA意味着系统只有在没有网络分区的情况下才能保证一致性和可用性。但是，说完全没有网络分区显然是不现实的。这是许多争议的根源。必须有分区。它们出现的原因有很多。切换故障、网卡故障、链路层故障、服务器故障、进程故障等，都可能导致分区出现。即使系统没有发生故障，也有其他原因可能导致分区，例如GC暂停或长时间延迟。在继续分析之前，我们必须接受这个事实。这意味着“CA”系统只有在变为非CA时才是CA。一旦发生分区，所有的假设和所有的保证都会以这样或那样的方式产生严重的后果。哪里不会出现这个问题？CAP的核心在于平衡妥协，但它是排他性原则。它告诉我们系统在某些现实条件下不能做什么？这里的区别在于并非所有系统都适合这些模型。如果Jepsen教会了我们什么，那就是大多数系统都不属于这些类别，即使他们的设计师说他们符合。实际上，CAP不仅仅是非黑即白的。NicolasLiochon最近写了一系列非常好的CAP文章。他很好地解释了这个晦涩和被误解的术语（比我解释得好得多），并提出了一些非常有趣的观点。Nicolas认为CA其实应该看成是一种操作范畴的规范，而CP和AP则是对行为的描述。我同意这一点，但我的问题是它回避了必然会出现的平衡权衡。我们知道网络分区是不可避免的。如果我们给应用程序这样一个规则：“这个应用程序不会处理网络分区。如果有网络分区，应用程序将部分失败，数据可能会损坏，你可能需要手动修复数据。”也就是说，我们这里其实求的是CA，但是如果有partition的话，可能是属于CP的；或者，不幸的是，可用性和一致性都丢失了。在运维语境中，CA其实就是当分区发生时，系统摊开双手发出信息：“我崩溃了！”如果我们指定系统不能在某个网络分区下正常工作，那就意味着该分区不在操作范围内。我们在地球上指定设计用于飞入泰拉大气层的宇宙飞船的规格有什么意义？我们处在一个分区很普遍的世界，所以我们当然希望在操作域中支持分区。CA肯定规定了一个操作范围，但是你不能写到SLA里，然后给客户。通俗地说，这只是一种在没有定义的情况下“未定义行为”的模式——系统是一致的、可用的。CAP不是一个完美的概念，但在我看来，它很好地突出了构建分布式系统时需要考虑的一些基本权衡。无论我们是否将它们写成书面形式，它们都存在。如果写下来，我们也不能保证可用性。面对分区时，CAP似乎可以在一致性和可用性之间做出选择。事实上，这里不仅有两种选择。您可以选择AP、CP或两者都不选。两者都不选的问题在于很难推理，甚至很难定义原因。最终，它只是一个选择的产物，因为我们不可能牺牲分区容错性。原文链接：http://www.searchdatabase.com.cn/showcontent_89029.htm
