由马丁·克莱普曼于2015年5月11日发布。这篇博客文章已经翻译成了俄语、日语、中文和中文再版。有关CAP问题的更多细节，以及对替代方案的提议，请参见我的论文《CAP定理的批判》。在他出色的博客文章《年轻人的分布式系统笔记》中，杰夫·霍奇斯建议您使用CAP定理来批判系统。很多人认真接受了这个建议，描述他们的系统为“CP”（在网络分区下保持一致但不可用）、“AP”（在网络分区下可用但不一致），或者有时称为“CA”（意味着“我仍然没有阅读Coda在近5年前的帖子”）。我同意杰夫的所有其他观点，但关于CAP定理，我必须表示不同意见。CAP定理过于简单，且被广泛误解，无法有效地用于表征系统。因此，我请求大家停止所有对CAP定理的引用，停止谈论CAP定理，让这个可怜的东西安息。相反，我们应该使用更准确的术语来推理我们的权衡。（是的，我意识到写一篇关于我请求人们停止谈论的主题的博客文章的讽刺。但至少这给了我一个网址，当人们问我为什么不喜欢谈论CAP定理时，我可以给他们。此外，如果这有点像是在咆哮，我表示歉意，但至少这是一篇引用了大量文献的咆哮。） CAP使用非常狭窄的定义 如果你想将CAP称为定理（而不是你数据库的营销材料中的一个模糊概念），你必须精确。数学要求精确。证明的有效性取决于你使用的词与证明中使用的词具有相同的含义。而证明使用了非常具体的定义：CAP中的一致性实际上意味着线性化，这是一个非常特定（且非常强）的标准的一致性概念。特别是它与ACID中的C毫无关系，尽管C也代表“一致性”。我在下面解释了线性化的含义。在CAP中，可用性被定义为“系统中非故障[数据库]节点收到的每个请求必须返回[非错误]响应”。仅仅有一些节点能够处理请求是不够的：任何非故障节点都需要能够处理它。许多所谓的“高度可用”（即停机时间低）系统实际上并不符合这个可用性的定义。分区容忍（命名非常糟糕）基本上意味着你正在通过一个可能延迟或丢失消息的异步网络进行通信。互联网和我们所有的数据中心都有这种特性，因此在这方面你实际上没有选择。此外，请注意CAP定理不仅描述任何旧系统，而是一个非常特定的系统模型：CAP系统模型是一个单独的、可读写的寄存器——就这些。例如，CAP定理对涉及多个对象的事务没有任何说明：除非你能以某种方式将它们减少到一个单独的寄存器，否则它们完全超出定理的范围。CAP定理考虑的唯一故障是网络分区（即节点保持运行，但某些节点之间的网络无法工作）。这种故障确实发生，但这并不是唯一可能出错的事情：节点可能崩溃或重启，你可能用尽磁盘空间，可能会遇到软件bug等。在构建分布式系统时，你需要考虑更广泛的权衡，过于关注CAP定理会导致忽视其他重要问题。此外，CAP定理对延迟没有任何描述，而人们往往更关心延迟而不是可用性。实际上，CAP可用的系统允许响应延迟到任意程度，仍然可以称为“可用”。我敢打赌，如果你的用户在加载页面时需要2分钟，他们不会称你的系统为“可用”。如果你的用词与证明的精确定义相匹配，那么CAP定理适用于你。但如果你使用了某种其他的一致性或可用性的概念，你不能指望CAP定理仍然适用。当然，这并不意味着你可以通过重新定义某些词来突然做到不可能的事！这只是意味着你不能借助CAP定理来指导自己，也无法用CAP定理来证明自己的观点。如果CAP定理不适用，那么这意味着你必须自己考虑权衡。你可以使用自己的定义来推理一致性和可用性，也欢迎你证明自己的定理。但请不要称其为CAP定理，因为那个名字已经被占用了。 线性化 如果你对线性化（即CAP意义上的“一致性”）不太了解，让我简单解释一下。形式上的定义并不是完全简单的，但关键思想，非正式地陈述，是这样的：如果操作B在操作A之后启动，操作B的结果必须在操作A的影响下立即可见。