入门理论，相信很多人都听说过，意思是分布式系统只能满足一致性、可用性、分区容忍度这三项中的两项。 为什么要理解CAP理论？我可以给出很多理由。 如果是在职场，或许最合适的理由是，当领导给的任务不靠谱时，我们可以按CAP否决。 比如有一个任务，给你设定了三个目标:提高系统的可用性，保证数据的实时可见性，提高系统的容错性。你想到阿里了吗……好吧，如果你深入了解CAP，你会发现完成这个任务是不可能的？ 但是，如果你不认识CAP，然后你拍着胸脯保证完成任务，你也不在乎，职场上就不需要眼泪和遗憾了。 有点跑题了。让我们言归正传。 CAP理论是分布式设计中最基本也是最重要的理论。没有它，你甚至可能无法分析一个分布式系统的核心设计概念。 为什么看了这么多文章还是不懂CAP？既然CAP理论来源于学术界，而解读CAP理论的人又试图用工程师的方式来解释，这本身就有问题。 CAP本身是基于状态和瞬态的，是描述性的理论，不处理工程问题。 但是，很多工程师总是试图过度解读CAP。 比如，要说CAP理论只能适用于某个场景，CAP理论中的一致性很强，把它和交易的一致性混为一谈。 因为CAP是学术理论，不是工程理论，会抛弃现实世界中的很多实际问题。 比如网络的时长，比如节点内的解析速度不一致，比如节点间的存储方式和速度不一致。 一致性是指客户端能否获得最新的数据，可用性是指客户端不能获得最新的数据。 但是这些东西被工程师补充的太多了，导致文章之间的说法不一样，分析不一样，背景不一样。 在今天的文章中，我们只是解释和说明，而不是弥补。但是，我们大多从工程的角度来解读。我们只讲本质，只提核心，希望能真正讲清楚，理解CAP理论。 希望本文能达到这个目的。 接下来，当你看到正文的时候，我已经写了10天了，是这篇文章的第三版。前两版已经有一半被我推翻重写了，因为我自己看也不满意。 一方面，我对自己的知识不满意，以为自己懂CAP。直到我写出来，才发现有些还是不确定。 另一方面，我并不满足于自己的文笔过于晦涩和教科书式，能让自己的知识浅显易懂才是我所希望的。 让你看看这篇文章在前世是什么样子的。 1.CAP的由来要了解CAP，首先我们需要知道为什么有人提出CAP？他提出CAP是为了解决什么问题？追溯到1985年，后来证实了CAP理论的Lynch教授给当时的IT界来了一个惊雷:她通过无可辩驳的证实告诉业内的工程师，在不稳定的网络环境下(分布式异步模型)，保持数据的一致性是不可能的。 这是什么概念？是她打破了技术人员既想提供超高质量服务，又想提供超高性能服务的幻想。 这个的本质是告诉大家，在分布式系统中，需要妥协。 但是如何妥协呢？在分布式系统中应该如何权衡这种取舍？我们可以想象，在CAP定理提出之前，如果没有这些方向性的指导方针，设计和实现分布式系统会有多么混乱。 分布式系统由几个模块组成，这些模块可能由不同的开发人员完成。 但是，对于这些人来说，在公共层面，实际上并没有一个准则来指导他们如何完成这一套功能。 比如我们同步两个节点的数据，如果出了问题，怎么办？如果没有统一的标准和方向，很可能一个分布式系统中不同的模块会有不同的解决方案。 假设一个系统由两个模块A和b组成。 模块A的设计思想是，如果节点之间出现问题，它可能会反复尝试，直到节点之间的通信恢复。 B的设计理念是:节点之间有问题，断开就好。最多可以记录下状态，以后再解决。 但是，A和B之间有交流的时候怎么办？会有一个从A到B的请求，问题会反复尝试。 而B向A发送请求，出了问题就直接断开。 当然，我们后面会解释，CAP的概念在实际项目中会允许这种不一致性。 但那种不一致是事先设计好计划好的，是根据实际数据和业务需求的重要性做出的妥协，而不是这种混乱的妥协。 因此，15年来，IT领域的人们一直在摸索一些准则来指导分布式系统的设计。 2000年，Eric Brewer教授在PODC会议上提出了CAP理论，但由于没有得到证实，当时只称为CAP猜想。 这个猜想引起了很大的反响，因为CAP是符合人们期待的设计方案。 2002年之后，在Seth Gilbert和Nancy Lynch从理论上证实了CAP猜想之后，CAP理论正式成为分布式系统理论的基石之一。 2.CAP到底是什么？CAP定理表达了在一个分布式系统中同时满足以下三个特性是不可能的:2.1。c:数据一致性什么是数据一致性？乍一看，真的让人摸不着头脑。什么是一致性？意味着数据可以一起变化，可以让数据统一。 那么问题又来了。数据什么时候会变？数据怎么能叫一起变？现在，让我们来回答这些问题。当我们理解了这些问题，我们就会对数据一致性有一个清晰的认识。 一、第一个问题，数据什么时候一起变？答案是:只有当包含数据的服务收到数据升级请求时，数据才会发生变化。 数据升级请求只包括数据的增加、删除和修改，统称为写请求。 因此，只有在写入请求时，数据才会改变。 那我们来回答第二个问题。数据怎么能叫一起改？也就是说，谁来判断数据最终是否被更改？是服务器对写请求返回的结果吗？告诉写请求成功，数据在一致性上肯定会有变化？不，数据更改的一致性需要通过读取请求来检查。 那么阅读请求判断的依据是什么呢？假设我们的分布式存储系统有两个节点，每个节点都包含一些需要更改的数据。 假设两个节点的数据在写入请求后都发生了变化。 然后，读请求读取所有改变的数据，我们把这种数据修改称为数据一致性改变。 然而，这并不是完全的一致性。 因为系统不可能永远正常运行 如果系统内部出现问题，导致系统的节点无法一致变化，会怎么样？当我们这样做时，这意味着希望看到最新数据的读者可能会看到旧数据，或者他们会得到不同版本的数据。 此时，为了保证分布式系统的外部数据一致性，我们选择不返回任何数据。 这里需要注意的是，CAP定理是关于某种状态下的选择，与实际工程中的理论不同。 上面描述的一致性和ACID事务中的一致性是两回事 事务的一致性包括实际项目对状态的后续求解。 但是CAP定理不涉及状态的后续求解。对于这些问题，出现了基础理论等工程结论来解决。目前只需要明白CAP定理主要描述的是状态。 2.2.答:可用性奥维德曾说过:“行动被人遗忘，但结果永存” 这句话说明了结果的重要性，可用性是CAP对结果的要求。 它要求系统中的节点能够解决写请求和读请求，并返回响应结果。 它只有两个必须满足的条件:条件1:返回结果必须在一个合适的时间内，这个时间根据业务来定。 据说服务必须在100毫秒内返回，合适的时间是100毫秒，需要在1秒内返回，也就是1秒。如果服务被调度100毫秒，但是结果在1秒内返回，那么系统就不满足可用性。 条件2:系统中所有可以正常接收请求的节点都需要返回结果。 这有两层意思:如果一个节点不能正常接收请求，比如它宕机了，系统崩溃了，剩下的节点还能正常接收请求，那么我们说系统还是可用的，也就是说部分宕机没问题，不影响可用性指标。 如果节点可以正常接收请求，但是发现节点内部数据有问题，也必须返回结果，即使返回的结果有问题。 例如，系统有两个节点，其中一个节点的数据是三天前的，另一个节点的数据是两分钟前的。如果一个读请求去了包含三天前数据的节点，对不起，这个节点不能拒绝，但是三天前的数据必须返回，即使可能不公平。 2.3.p:具有分区容差的分布式存储系统将有许多节点，所有节点都通过网络进行通信。 但是，网络不可靠。当节点之间的通信出现问题时，就说当前的分布式存储系统是分区的。 不过值得一提的是，分区不一定是网络故障造成的，也有可能是机器故障造成的。 例如，我们的分布式存储系统有两个节点A和b。 那么当A和B之间的路由器、交换机等底层网络设施出现故障时，A和B之间的通信出现了问题，但A和B都还在运行，向外界提供服务。 这时候就说A和B分区了。 在另一种情况下，会发生分割。当A宕机，节点A和B之间的通信也出错时，那么我们也调用A和B分区。 综上所述，我们可以知道，只要分布式系统中的节点通信出现问题，那么就存在分区。 那么，分区容忍度是什么意思呢？也就是说，如果出现分区问题，我们的分布式存储系统需要继续运行。 因为不能出现分区问题，整个分布式节点都会停工，罢工，停止做事。 3.如何选择CAP我们已经知道，在设计分布式系统时，架构师只能选择C、A、p三个特性中的两个。 但是，这道CAP选择题就好比有人问你，“小明爸爸有三个孩子，老大叫大郎，老二叫二郎，请问老三叫什么名字？” 在以分布式存储系统为限制条件的CAP世界里，P是早已确立的答案，P是必须的。 因为，在分布式系统中，P是必然的。如果不选择P，一旦出现分区错误，整个分布式系统将完全无法使用，不符合实际需要。 所以对于分布式系统，我们只能考虑在分区错误发生时，如何选择一致性和可用性。 根据一致性和可用性的选择，开源分布式系统通常分为CP系统和AP系统。 当一个系统出现分区故障，客户端的任何请求都被卡住或者超时，但是系统的每个节点总是返回一致的数据，那么这个系统就是CP系统，经典的例子就是Zookeeper。 如果一个系统出现分区故障，客户端仍然可以访问系统，但是获取的数据有些是新数据有些是旧数据，那么这个系统就是AP系统，经典的例子就是Eureka。 说了这么多，其实CAP定理的本质很简单。它是分布式系统设计的不同概念的概括，包括其一致性、可用性和分区容错性。 这类似于一所大学的校训，极具概念性。 所以，让我们用简单的英语描述一下CAP。CAP告诉程序员，当分布式系统出现内部问题时，你要做两个选择:要么容纳外部服务，像外包公司一样。 要么让外部服务来容纳你，比如银行。 容纳外部服务，就是不能因为自身的问题影响外部服务的业务运营，要优先考虑可用性。 并且让外部服务容纳我们，我们必须优先考虑一致性。 4.CAP 1常见误区:分布式系统因为CAP定理抛弃了C或A中的一个。在没有深入了解CAP的情况下，很多人听说分布式系统必须在CAP的三个特性中选择两个，觉得一个分布式系统必须只有可用性或者一致性，没有完整的可用性和一致性功能。 这种认识很有问题。 因为这个问题的概率很低，所以在没有分区问题的情况下，系统应该有完善的数据一致性和可用性。 你什么时候见过一个系统，内部没有问题的时候，经常会让外部请求卡？还是突然提供旧数据？那还能叫系统吗？误区二:C和A的选择是针对整个分布式系统的。知道C和A的选择只能整体考虑也是不对的。 当分区发生时，一致性和可用性的选择实际上是局部的，而不是针对整个系统。 它可能是在少数子系统中做出的少数选择，甚至可能只是某个事件或数据的一致性和可用性问题。 比如我们设置支付系统时，会员的账户余额、账户流水等财务信息必须一致。 这个时候，你应该考虑选择c。 而会员名称和付费设置不需要考虑强一致性，可用性A可以选择。 分布式系统的运行，就像人生一样，是一次又一次的选择。 当不同的事件发生在不同的阶段，不同的时间，怎么会有完全一样的选择呢？误区三:CAP的三个特性只有两个极端的选择，是和不是，而不是一个范围。这种二元性极具误导性。 CAP理论的三个特征不是布尔型的，它们或者一致或者不一致，可用或者不可用，分区或者不分区。 相反，这三个特征都是范围类型。 从可用性来说，就像我从银行取钱一样。 当我的目的是发压岁钱的时候，我大概要的都是新票。不过新票大概还有一步，就是我需要用旧票换少量新票。这个时候，我可以再等一会儿，就去取新票。 而当我的目的是赚生活费的时候，票是新的还是旧的，我根本就不在乎那么多。快点拿到钱。 这是可用性的范围要求之一，时间延迟的要求。 比如分区容错是因为检测机制的问题，每个节点可能要投票协商分区是否可以存在。当一台机器出现问题，可能不影响业务，会被机器投票认为分区不存在。 然后等到大部分机器都有问题了再投票确认有分区问题。 就像新冠肺炎疫情一样，会分为低、中、高风险区。并非每个通信故障都被逻辑地确定为分区问题。 5.关于CAP理论的几个问题？问题1:遵循CAP定理的系统能适用于任何写请求吗？首先，CAP定理中关于一致性的观点很多，但总的来说，都是描述最新版本数据的可见性。 这些可见性通常表示读取请求返回的数据的可见性。 那么问题来了，当我们要求读取数据的可视性时，对写入数据有什么要求吗？比如我们的系统有三个节点，一个客户端向系统发送写请求，要求系统写一个值为20的数据。 那么，如果要满足CAP定理中的一致性，就需要在写入20的数据后，当其他客户端请求读取值为20的数据时，无论请求转发到系统中的任何节点，都可以返回这个值。 这就要求这个值为20的写请求必须成功写入三个节点，此时系统满足写一致性。 因此，我们可以说，阅读一致性的要求同时约束了写作一致性。 其次，在CAP定理中，可用性本身要求读写请求都应该得到解决。 如果我们以可用性为标准，当出现分区错误时，由于我们没有强制读请求返回完全准确的数据，所以在这个读请求之前的最后一个写请求可能会部分失败。 同样的例子，我们的分布式系统由三个节点组成，最后一个写请求想把值为20的数据写到三个节点。 但是因为分区问题，出现了节点通信失败，写请求无法写入，所以只有两个节点包含值为20的数据。 此时，写请求将向客户端返回结果，该结果可以告诉客户端写成功或者写部分成功。 此时，当后续的读请求恰好发送到通信失败的节点时，系统可能只会返回一个空结果。 但是，因为系统解决并返回读写请求，所以系统满足CAP中的可用性。 问题2:数据分片和数据复制的分布式系统能否都遵守CAP定理？我们知道，在大规模分布式系统中，肯定需要将海量数据分段存储在不同的机器上，以及对这些存储数据的机器进行拷贝。 那么，如果一个分布式系统只分片存储数据或者只存储数据副本，是否都会遵守CAP定理呢？答案是，当数据碎片化时，也应该遵守CAP定理，但这是一种非常特殊的遵守。 当一个分布式系统只有碎片化存储时，CAP理论会是什么样子？例如，我们有一个分布式系统，由三个节点A、B和c组成。 其中，节点A存储表A的数据，B存储表B的数据，C存储表C的数据。 如果有一个业务，它的意图是在表A中插入一个新数据，删除表B中的一个已有数据，升级表c中的一个旧数据，这个分布式系统应该如何解决这个业务？从技术上来说，我们倾向于将这样一种情况打包，即我们希望以一个意图做许多事情，作为一个交易。 当我们把它包装成一个事务的时候，可能会先在节点A执行，然后在节点B执行，最后在节点C执行，直到一切成功才会返回成功。 但是，分区发生后怎么办？当节点A和B成功时，在C中发现通信失败？此时，根据CAP定理，你有两个选择，要么直接向客户端返回一个部分成功的结果，要么直接阻塞客户端等待超时，要么向客户端返回一个失败。 返回部分成功时选择可用性(a)，卡死或用户向客户端返回失败时选择一致性(c)。 然而，我们将请求打包成一个事务，该事务要求要么成功要么失败...为了符合这个要求，由于客观条件的限制，我们不得不选择c。 所以，碎片化的分布式系统往往是CP系统。 可选，但不是可选，是分布式系统只存储碎片数据时，遵守CAP定理的特殊体现。 当分布式系统由多个节点组成时，每个节点存储一组完整的数据，其他节点只是完整数据的备份，即使在一台机器上事务成功，当分区失败时，我们仍然可以有足够的空间来选择是回滚单个事务还是认为写成功。 单个事务的回滚可以对外反映为一致性的选择。 如果认为书写成功，可以认为选择了可用性。 问题3:为什么有时候很难区分一个系统是AP还是CP？前面说过，AP或CP的选择可能只局限于整个系统的某些部分，甚至是某些特殊的数据，而我们用这种局部特征来描述整个系统，这就导致了区分的困难。 其实这本身已经逐渐成为CAP的一大问题，从而被人诟病。 6.CAP的缺点CAP定理本身没有考虑网络延时的问题。它认为一致性立即生效。但是保持一致性是需要时间的，这就导致了分布式系统往往更多的选择AP。因为时代的演进，当CAP定理应用于所有分布式系统时，有少量的无力。因此，它通常会将以前严格的数学定义改为更宽松的业务定义。类似于我们所看到的，CAP定理把一致性、可用性和分区容错性变成了一个范围属性，与CAP定理本身类似数学定理的标题相冲突，产生了不符合严谨数学定义的问题。 在实践和后来，CAP定理的支持者也承认，一致性和可用性不仅仅是一个从另一个中选择一个的问题，而是重要性的微小差异。当强调一致性时，并不意味着可用性完全不可用。 比如Zookeeper，可能只有在主设备出现问题的时候，才会有几十秒不可用，其他时候，会通过各种方式保证系统的可用性。 在强调可用性的时候，往往会使用少量的技术手段来保证数据最终是一致的。 CAP定理并没有给出这些情况的具体描述。 从工程的角度来说，CAP的理论只是对状态的一种描述，告诉我们分布式系统在出问题的时候可能处于什么状态。 但是，状态可能会改变。 怎么改变状态，怎么修复，怎么恢复，没有方向。 7.基数扩大是由于上限以上的各种不足。epay的架构师丹·普里切特根据自己在大规模分布式系统中的实践经验总结了基础理论。 BASE理论是CAP理论的扩展，其核心思想是即使不能达到强一致性，应用也可以通过合适的方式达到最终的一致性。 基础理论是实际工程的理论，它弥补了CAP理论的一般性问题，同时处理AP系统的整体工程实践思想。它是分布式系统的核心理论之一。我们将在下一篇文章中详细解释这套理论。 8.大厂面试问题。文末来几个大厂关于CAP的面试问题，测试一下你的学习效果。hiahiahia，什么是CAP理论？CAP中的p是什么意思？为什么在分布式系统中一定要在C和A之间做选择？结合实际应用，如何选择CP和AP？最后，如果看完还有什么不明白的，可以在下面留言讨论。感谢您的观看。 记得关注我，觉得文章对你有帮助就给我赞！作者:四只猿外部链接:https://juejin.cn/post/6911928896598310926