转载

架构师都该懂的 CAP 定理

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。

也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。

什么是 CAP

CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。

CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）这三个约束属性最终只能同时满足二个。

架构师都该懂的 CAP 定理

下面是关于这三个属性的简单描述：

一致性：客户端进行读操作得到的数据永远是最近一次写入的数据，要求了对数据读写的强一致性。
可用性：客户端的请求在限定时间内总能从非故障的系统节点得到正常的响应，其中不能有超时，不能出错如 502之类。
分区容错性：就是出现网络分区现象，即节点间无法正常通信，数据同步出现延时等情况时，系统仍能继续提供服务。

需要注意的是，CAP 描述了一个常规的分布式系统场景：有网络连接，且数据跨节点进行共享。如果在整个系统中，数据只有一份，并且其他节点没有对应的副本，也不需要进行跨节点的数据共享，这样分布式系统就不是 CAP 关心的对象了，也谈不上结合 CAP 定理去设计和实施。

深入认识 CAP

了解 CAP 基本概念之后，我们再来分别对 C，A，P 三个属性进一步学习下，加深对 CAP 的理解。

C：一致性

这里的一致性从不同角度有着各自的描述方式，在分布式系统中表现是每个节点的数据是相同；而对于客户端，表现是读操作所得到的结果永远是最新写入的。其中需要明确的是，对于分布式系统节点来说，是可能出现某个时刻拥有不同的数据的情况：如果在某个节点执行原子性操作时，对于执行过程中的节点数据跟其他节点就并不完全一致，只有原子性操作执行完成后，节点的数据才会继续保持同步。比如常见的事务操作，只有事务提交后，客户端才能读取到事务写入的数据，失败则回滚为旧的数据，不会出现读取事务中间写入数据的情况。

一致性要求了在分布式环境下的操作要就像在单机上完成的一样，当客户端发起写请求时，收到写请求的节点会及时响应，并将更新的数据同步到另一个节点，保证数据一致性。具体的工作流程，如下所示：

客户端向节点 1 发送写操作，将数据 X 更新为 1 ，
更新操作成功，系统将更新的数据从节点 1 同步到节点 2，将节点 2 的旧数据 X 也更新为 1。
客户端再向节点 2 发送读操作获取数据 X 时，就会得到 X 最新的值：1。

架构师都该懂的 CAP 定理

一致性强调了数据的强一致，这一点要求对于一些系统可以说是十分重要的。比如电商系统的库存扣减，金融系统的转账扣款等场景，任何出现一致性的问题，都可能会造成很严重的后果。

A：可用性

介绍完一致性，再来看下可用性，虽然可用性概念相对简单，但重要程度跟一致性一样。要让系统满足可用性，就是要保证无论除了所有节点出现故障的情况外，系统都能返回有效的响应，允许响应给客户端是旧的数据，但不能出现响应失败，超时的情况。

可用性强调的是服务可用，但不保证数据的正确性。用一个简单的例子来描述分布式系统的可用性如下：允许客户端向节点 1 或者节点 2 发起读操作，当其中某一个节点故障了，不管节点间数据是否一致，只要有节点服务能收到请求，就响应 X 的值，这样就说明这两个节点服务是满足可用性。

架构师都该懂的 CAP 定理

在可用性的描述，还值得一提的是关于什么算有效的响应。要返回有效的响应，不能超时，也不能出错，结果不一定是正确的，比如返回了旧数据，但是客户端接收到后是能进行正常业务处理的。

P：分区容错性

讲完 C 和 A 之后，最后再讲一下 P：分区容错性。由于分布式系统多个节点往往部署在多个网络环境下进行相互通信，就难免出现一些网络故障，如网络丢包，网络消息延迟，网络中断等情况，会导致节点间的通信出现问题，数据同步操作无法完成，分区容错性就要求了系统即使在网络分区出现的情况下，能仍继续对客户端提供服务。

架构师都该懂的 CAP 定理

因为分布式系统与单机不同，它涉及到了多节点间的通信和数据交互，避免不了网络问题，如果没有分区容错性，就意味着系统不允许出现节点间的通信出现任何错误，错误就意味着系统不可用，这在绝大数系统中无法接受的。因此对节点间的分区故障容错是必须要考虑的，也是 CAP 定理中分区容错性通常首先要保证的原因。

如何应用 CAP 定理

了解完 CAP 定理的一致性（C），可用性（A）和分区容错性（P）之后，我们再来看下如何使用这个定理。CAP 定理指明了 C，A，P三个属性无法同时满足，而在必有网络交互和数据同步的情况下，就一定会有延迟和数据丢失的情况，对于这种情况我们又必须接受且保证系统不能挂掉。所以分区容错性是必须要保证的，剩下的就是在一致性（C）和可用性（A）之间做选择了。选择了一致性，保证数据正确性，但也意味系统可能存在不可用的情况；而选择可用性，保证服务的高可用，但也意味数据可能出现不一致性的情况。接下来就探讨下应用采用 CP 架构，AP 架构所各自的特点，以及如何根据不同的分布式场景选择适合的架构策略。

CP

对于 CP 架构的分布式系统来说，为了保证一致性，当出现网络分区后，如果节点 1 上数据 X 已经更新为 2，但由于节点间数据同步的通道已经中断，节点 1 数据无法同步到节点 2，节点 2 上的数据 X 还是 1。此时如果客户端访问节点 2 的数据 X，节点 2 就需要返回错误，提示系统发生了错误，直到节点间的数据保持同步。当然这样的处理方式明显违背了可用性的要求，因此在 CAP 定理只能满足 CP。

架构师都该懂的 CAP 定理

如果一个分布式场景需要很强的一致性，或者能容忍系统长时间无响应但是数据要保持一致的情况，就比较适合使用 CP 架构设计对应的分布式系统。这样的系统一旦发生网络分区会导致数据无法同步情况，就要牺牲系统的可用性，直到节点数据达到一致后再响应。在开源社区中采用 CP 架构的应用不少，比如 Redis，HBase，MongoDB，ZooKeeper，Etcd，Consul 等都是放弃了一定可用性而选择 CP 属性。

AP

如果采用 AP 架构设计的分布式系统，为了保证可用性，当网络分区发生后，同样节点 1 上数据 X 已经更新为 2，但由于节点间数据同步的通道已经中断，节点 1 数据无法同步到节点 2，节点 2 上的数据 X 还是 1。这是客户端访问节点 2 获取数据 X 时，收到是正常的响应，旧数据 X = 1，而实际上当前最新的数据 X 已经是 2 了，这里就不满足一致性的要求了，因此在 CAP 定理只能满足 AP。

架构师都该懂的 CAP 定理

同样适合 AP 的场景有很多，比如一些查询系统，电商系统的商品查询等，大多数为了保证系统的可用性，而牺牲一定的数据一致性，这样也保证了用户体验，在开源界中采用 AP 模型的典型应用有 Eurka，Cassandra。

必须三选二吗

提到了 CAP 定理，大多数人都认为无论什么情况，分布式系统只能在 C 和 A 中选择一个。但这里的前提是系统发生了网络分区情况，如果系统没有发生网络分区的情况，也就是说 P 不存在的时候，我们就没有必要放弃 C 或者 A，因此进行架构设计时也应该考虑没有分区情况下如何保证 CA。除此之外，一个分布式系统不一定只能从 AP 与 CP 中做选择，内部不同模块所应对的场景也不同，完全有可能是一个模块采用 AP 架构，另一个模块采用 CP 架构。作为优秀的架构师，不应该受到大多数人对 CAP 定理所认识的局限，设计出符合自身业务场景的分布式系统才是重中之重。

总结

本文主要了解和认识 CAP 定理，以及每个 C，A，P 的含义，以及 CAP 定理的应用。掌握 CAP 定理，对架构师来说非常重要。因为对于分布式系统来说，网络故障在所难免，如何在出现网络故障的时候，维持系统按照正常的行为逻辑运行就显得尤为重要。一个合格的架构师需要是能结合实际的业务场景和具体需求，基于 CAP 定理来进行权衡和设计可用且稳定的分布式系统。