请停止称呼数据库为 CP 或 AP (2015)

请停止称呼数据库为 CP 或 AP 马丁·克莱普曼于 2015 年 5 月 11 日发表。这篇博文已被翻译成俄文、日文、中文、中文。有关 CAP 问题的更多详细信息以及替代方案的建议，请参阅我的论文《CAP 定理批判》。 Jeff Hodges 在他出色的博客文章 Notes on Distributed Systems for Young Bloods 中建议您使用 CAP 定理来批评系统。很多人都牢记这一建议，将他们的系统描述为“CP”（一致但在网络分区下不可用）、“AP”（可用但在网络分区下不一致），有时甚至是“CA”（意思是“我还没有读过 Coda 近 5 年前的帖子”）。我同意 Jeff 的所有其他观点，但对于 CAP 定理，我必须不同意。 CAP 定理过于简单化并且被广泛误解，对于表征系统没有多大用处。因此，我要求我们撤回所有对 CAP 定理的引用，停止谈论 CAP 定理，并让这个可怜的事情停止。相反，我们应该使用更精确的术语来推理我们的权衡。 （是的，我意识到写一篇关于我要求人们停止写的主题的博客文章很讽刺。但至少它给了我一个 URL，当人们问我为什么不喜欢他们谈论 CAP 定理时，我可以给他们提供这个 URL。另外，如果这有点咆哮，我很抱歉，但至少这是一个有大量文献参考的咆哮。） CAP 使用非常狭窄的定义如果你想将 CAP 称为一个定理（而不是一个模糊的定理）数据库营销材料中的手波概念），你必须精确。数学要求精确。仅当您使用与证明中所用含义相同的单词时，该证明才成立。证明使用了非常特殊的定义：CAP 中的一致性实际上意味着线性化，这是一个非常具体（并且非常强）的一致性概念。特别是它与 ACID 中的 C 无关，尽管 C 也代表“一致性”。下面我解释一下线性化的含义。 CAP 中的可用性被定义为“系统中非故障[数据库]节点收到的每个请求都必须产生[非错误]响应”。某些节点能够处理请求是不够的：任何未发生故障的节点都需要能够处理它。许多所谓的“高可用性”（即低停机时间）系统实际上不符合可用性的定义。分区容错性（名字非常错误）基本上意味着您正在通过异步网络进行通信，这可能会延迟或丢弃消息。互联网和我们所有的数据中心都具有此属性，因此您在这件事上实际上没有任何选择。另请注意，CAP 定理不仅仅描述任何旧系统，而是描述一个非常具体的系统模型：CAP 系统模型是单个读写寄存器 – 仅此而已。例如，CAP 定理没有提及涉及多个对象的事务：它们根本超出了定理的范围，除非您可以以某种方式将它们减少到单个寄存器。 CAP 定理考虑的唯一故障是网络分区（即节点保持运行，但其中一些节点之间的网络不工作）。这种错误绝对会​​发生，但这并不是唯一可能出错的事情：节点可能崩溃或重新启动、磁盘空间可能耗尽、软件可能出现错误等等。在构建分布式系统时，您需要考虑更广泛的权衡，而过于关注 CAP 定理会导致忽略其他重要问题。此外，CAP 定理没有提及延迟，而人们往往更关心延迟而不是可用性。事实上，CAP可用的系统可以任意缓慢地响应，并且仍然可以称为“可用”。大胆地说，如果加载页面需要 2 分钟，我猜您的用户不会称您的系统“可用”。如果您使用的词语与证明的精确定义相匹配，那么 CAP 定理适用于您。但如果您使用其他一致性或可用性概念，则不能指望 CAP 定理仍然适用。当然，这并不意味着你只需重新定义一些词就可以突然做出不可能的事情！这只是意味着你不能向 CAP 定理寻求指导，也不能用 CAP 定理来证明你的观点。如果 CAP 定理不适用，则意味着您必须自己考虑权衡。您可以使用自己对这些词的定义来推理一致性和可用性，并且欢迎您证明自己的定理。但请不要将其称为 CAP 定理，因为该名称已被使用。线性化 如果您不熟悉线性化（即 CAP 意义上的“一致性”），让我简要解释一下。正式的定义并不完全简单，但非正式地表述的关键思想是：