大名鼎鼎的Cap理论究竟是什么

1. CAP理论的由来

在正式介绍CAP理论之前，先来了解一下CAP的由来。CAP其实是一个学术界的概念，而并非工程实践领域的概念。1985年，Lynch教授提出了一个影响深远的概念，引发了IT界的广泛关注，但在当时还并不是CAP理论。他指出，如在一个不稳定（要么消息错乱，要么消息丢失）的网络环境里（异构模型），想始终保持数据一致是不可能的，这个概念为后来CAP理论的发展奠定了重要基础。
显然这个概念告知了IT业界的工程师，在分布式环境下，既想提供超高可用服务，又想提供高质量（一致性保证）服务，是不现实的，只能有所妥协
但是究竟该如何妥协，具体措施是什么，在CAP理论出来之前，并没有一个明确的方向性的指导。所以在设计实现分布式系统时会显得很混乱。可能在分布式系统中，不同的子模块有着不同的设计标准，对同一个系统而言，这显然不是很合理
比如在一个由两个模块构成的分布式系统中，这两个模块A和B之间能够互相通信
A模块的设计原则是：A发送请求给其他模块，如果节点间出现了故障，会选择不断的重试，一直等到节点通信恢复。可以理解为提供高质量服务

B模块的设计原则是：B发送请求给其他模块，如果节点间出现了故障，会选择直接断开，并记下当前状态，等待后续处理，可以理解为提供高可用服务

显然，系统中如果出现了通信故障，A往B发请求，会出现不断重试，而B往A发请求，则会出现直接断开的情况，整个系统会很混乱。
所以，IT界的研究者们长期以来一直在探索指导原则来指导分布式系统的设计，经过15年的努力，终于在2000年，Eric Brewer教授在PODC会议上首次提出了CAP理论。然而，当时这一理论还没有被正式证明，所以只能称为CAP猜想
这个猜想一经提出，就在业界引起了极大的关注，因为它为分布式系统设计提供了一个简单而有力的框架。到了2002年，Seth Gilbert和Nancy Lynch通过理论证明了CAP猜想的正确性，从而使CAP理论正式确立，并成为分布式系统设计中的重要理论基础之一

2. 什么是CAP理论

CAP理论就是是2000 年时，Eric Brewer 教授在 PODC 会议上提出的一套关于分布式系统设计的理论，CAP指出， 在一个分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个目标无法同时满足，最多只能同时满足其中的两个

2.1 数据一致性（C）

CAP理论中的一致性也叫数据一致性，是指在分布式系统中的所有节点，在同一时间点上拥有相同的数据副本。比如某个节点数据有更新，那么其他的节点数据要跟着更新，要求所有的读请求都必须读到这个新数据 一致性两个最重要的核心是：

1. 什么时候数据会发生变更？ 数据的处理无非就是增删改查，查询操作是不会导致数据发生变化的，只有增，删，改才会导致数据服务上的数据变更，这三种操作可以统一为写操作，所以只有数据服务发生些请求的时候才会导致数据发生变更

2. 数据一致性改变 当数据服务有多个节点的时候，当数据服务接收到写请求时，怎样判定数据服务上所有的节点都一起发生了变更呢？当然有的分布式系统由不同的策略配置，比如msyql的主从集群，当配置为全同步时，即每次写数据只有当主库把数据都同步到从库后，才会返回成功，这样返回写成功后，数据就发生了一致性改变。如果不是这种配置策略，比如半同步，只有部分从库同步完了数据，也会返回成功，那么从从库读数据的话，可能就会读取不到新值。就不能称之为数据一致性改变
   假设有一个一主两从的mysql集群系统，在网络通信正常情况下，如果经过一次写请求后，两个从库节点都发生了数据变化。然后，读请求把这些变化后的数据都读取到了，我们就把这次数据修改称为数据发生了一致性改变

   

   假设系统内部发生了通信问题，主库和从库2之间的通信发生了故障，而主库和从库1之间的通信正常，那么写入操作成功之后，从库1可以读取到v1版本数据，而从库2无法读取到V1版本数据，地区到的还是旧数据。此时，系统中的节点就没有发生一致性改变

   

2.2 可用性（A）

可用性是指系统要处于100%的可用状态，对于每一个请求，正常节点要在合理的时间给出正确的响应，即系统能够正常提供服务
详细点说，这里的能够提供正常服务必须满足两个条件：

1. 必须在合理时间内给出相应，这个合理的时间是根据业务来定的。业务说要求200 毫秒内返回，合理的时间就是 200 毫秒，如果结果在 1 秒才返回，那么这个系统仍然是不满足可用性

2. 系统内只要正常的节点都要能够做出响应，返回结果。这里包含两种情况：

   • 如果系统内的某个节点或者是某些节点宕机了，但是其他的正常节点可以在合理的时间内做出响应

   • 节点正常，但是节点上的数据有问题，比如不是最新数据，如果有请求达到这个节点上了，依然不能拒绝请求，要正常返回这个旧数据

2.3 分区容错性（P）

分区容错性是指分布式系统能够在网络分区的情况下继续运行对外提供服务，即系统能够在节点之间进行通信的网络出现故障或延迟的情况下，保证系统的正常运行

2.3.1 什么是网络分区

网络分区只在分布式集群中，在分布式系统中，多个节点之间的网络本来是连通的，但是由于某些故障导致节点之间网络不通了，形成不同的子集，子集中节点之间网络互通，而子集与子集之间网络不通，整个网络就形成了几块区域，就是网络分区

3. CAP 为什么不能同时满足

这个问题看似是论证一致性、可用性、分区容忍性为什么只能选择其中的两个同时满足，其实并非如此。因为在分布式系统中分区容错性（Partition-tolerance ） 是不得不选择的。假设不考虑分区容错性，那就相当于把数据只存放在一个节点上，因为数据依旧集中在一个地方，一旦这个节点出现故障，整个系统毫无疑问会随之瘫痪，这在实际的生产环境中通常是不可接受的，而且数据集中在一个地方，这本身也与分布式相矛盾 所以，简单来说就是：在分布式系统中，分区容错性（ P ）是一定要满足的，剩下的一致性（ C ）和可用性（ A ）只能满足其一。因此，分布式架构不可能选择 CA 架构，只能选择 CP架构 或者 AP 架构
论证：
可以用反证法来论证，首先构造一个单机系统假设有如下请求调用关系：

Client1可以发送x=2的写指令到 Server1 更新 X 的值为2，Client2从 Server1读取该值，在单机情况下，不存在网络分区，通过事务机制，可以保证 Client2可以读取到X的最新值2，不存在一致性的问题
假设在系统中增加一组节点，如下图所示：

由于存在分区容错性，所以存在server2写入X=2失败，而server1写入X=2成功，那么此时client2和client3就会读取到不一样的值，client2读取到X=2，而client2读取到X=3，此时系统可用，但是违背了一致性，保证了A，但是违背了C，属于AP架构。假设此时要保持 X 值的一致性，server1和server2的Write 操作必须同时成功，系统必须等待server2也写入成功，在失败的这段时间里，系统是不可用状态， 这样的话就保证了一致性C，但是也降低了系统的可用性，违背了A，此时属于CP架构。由此可见，在分布式系统中，无法同时满足 CAP 定律中的“一致性”“可用性”和“分区容错性”三者

4. CAP该怎么选择

CAP理论强调一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个目标无法同时满足，最多只能同时满足其中的两个，那究竟该选择哪两个呢？
其实从上一小节CAP的论证知道，在分布式系统中分区容错性（Partition-tolerance ） 是不得不选择的，所以选择上只能是AP或者是CP，那对于业务而言，这两个架构该如何选择呢？任何方案选型都要根据业务场景出发，看业务场景适合哪种，就选哪种，一般而言：

4.1 CP 使用场景

比较典型的 CP 系统是分布式数据库，数据的一致性是最基本的要求。在极端情况时，优先保证数据的强一致性，代价就是放弃系统的可用性。例如，类似HBase 这种分布式存储系统，以及 ZooKeeper 这种分布式协调系统。另一个常见场景就是金融领域，为了资金安全一般需要确保强一致性

4.2 AP 使用场景

AP则是适应于目前大多数对于用户体验要求高的互联网应用场景，比如社交媒体，内容分发业务，像微博、Instagram。用户量大，主机众多，分布式部署，而且集群的规模越来越大，节点故障、网络故障时有发生，要保证系统的可用性，保障 AP 放弃 CP 是常见的一种做法

5. CAP的不足

CAP最大的不足其实也就是一致性（Consistency）、可用性（Availability）的强取舍问题。 在实际应用中，一致性和可用性并不只是简单的二选一问题，而是取决于各自的优先级。当我们强调一致性时，并不意味着系统的可用性会完全丧失。比如，在Zookeeper中，只有在主节点出现问题时，系统才可能会出现短暂的不可用状态，但在其他时间，系统通过各种方式来保证其可用性。同样，强调可用性时，通常也会采用技术手段来确保数据最终能够保持一致性。CAP定理并没有详细说明这些细节。其实简单来说，就是在设计分布式系统时，对于一致性和可用性希望有一些折中的手段，而不是选择了其中一个特性，就要完全舍弃另一个特性

学习交流

如果您觉得文章有帮助，请帮忙转发给更多好友，或关注公众号：IT杨秀才，持续更新更多硬核文章，一起聊聊互联网网那些事儿!