前言

CAP一张图

概述：互联网最重要任务莫过于海量数据处理，即大规模分布式系统，分布式是互联网的核心技术！！！

一、概念

CAP原则又称CAP原理，指的是在一个分布式系统，(指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
也就是说在分布式系统的设计中，没有一种设计可以同时满足这3个特性，要么CA，要么CP，要么AP！

1.1 关键词解读

上述中我们提及了2个关键词：

1. 互联和共享数据的分布式系统（CAP原则探讨的对象）

   分布式系统并不一定会互联和共享数据。
   例如 Memcache 的集群，相互之间就没有连接和共享数据，因此 Memcache 集群这类分布式系统就不符合 CAP 理论探讨的对象；而 MySQL 集群就是互联和进行数据复制的，所以才是 CAP 理论探讨的对象。（传统的关系型数据库DBMS：Oracle、MySQL都是CA。）

2. 数据读写

   CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。

1.2 关于CAP（拆分解读）

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否有同样的值，即写操作之后的读操作，必须返回该值。

  注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。

• 高可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

• 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

1.3 CAP原理精髓

CAP原理的精髓：就是一个数据分布式系统不可能同时满足C和A和P这3个条件。（CAP理论提出就是针对分布式数据库环境的，所以，P这个属性必须容忍它的存在，而且是必须具备的。）

所以系统架构师在设计系统时，不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。由于网络的不可靠性，大多数开源的分布式系统都会实现P，也就是分区容忍性，之后在C和A中做抉择。

---

二、CAP模拟场景举例理解

以电商环境为例

假设某电商公司，在北京、杭州、上海三个城市建立了仓库，同时建立了对应的服务器{A, B, C}用于存储商品信息。比如，某电吹风在北京仓库有 20 个，在杭州仓库有 10 个，在上海仓库有 30 个。那么，CAP 这三个字母在这个例子中分别代表什么呢？

• 首先，我们来看一下C。C 代表 Consistency，一致性，是指所有节点在同一时刻的数据是相同的，即更新操作执行结束并响应用户完成后，所有节点存储的数据会保持相同。在电商系统中，A、B、C 中存储的该电吹风的数量应该是 20+10+30=60。假设，现在有一个北京用户买走一个电吹风，服务器 A 会更新数据为 60-1=59，与此同时要求 B 和 C 也更新为 59，以保证在同一时刻，无论访问 A、B、C 中的哪个服务器，得到的数据均是 59。

• 接着，看一下 A。A 代表 Availability，可用性，是指系统提供的服务一直处于可用状态，对于用户的请求可即时响应。在电商系统中，用户在任一时刻向 A、B、C 中的任一服务器发出请求时，均可得到即时响应，比如查询商品信息等。

• 最后，我们看一下 P。P 代表 Partition Tolerance，分区容错性，是指在分布式系统遇到网络分区的情况下，仍然可以响应用户的请求。网络分区是指因为网络故障导致网络不连通，不同节点分布在不同的子网络中，各个子网络内网络正常。在电商系统中，假设 C 与 A 和 B 的网络都不通了，A 和 B 是相通的。也就是说，形成了两个分区{A, B}和{C}，在这种情况下，系统仍能响应用户请求。

---

三、CAP原理证明

重温概念

CAP原则：在分布式系统中 C（一致性）、A（可用性）、P（分区容错性） 这三个特征不能同时满足，只能满足其中两个；

为什么不能同时满足（下面举例说明）

如下图所示，有两台服务器Server1、Server2，它们分别部署了数据库 DB1 和 DB2，这两台机器组成一个服务集群，DB1 和 DB2 两个数据库中的数据要保持一致，共同为用户提供服务。

• 用户 User1 可以向 Server1 发起查询数据的请求；
• 用户 User2 可以向服务器 Server2 发起查询数据的请求，它们共同组成了一个分布式系统。
  
  以此系统为例，分别满足 C、A 和 P 指的是：
• 在满足一致性 C 的情况下，Server1 和 Server2 中的数据库始终保持一致，即 DB1 和 DB2 内容要始终保持相同；
• 在满足可用性 A 的情况下，用户无论访问 Server1 还是 Server2，都会得到即时响应；
• 在满足分区容错性 P 的情况下，Server1 和 Server2 之间即使出现网络故障也不会影响 Server1 和 Server2 分别处理用户的请求。

当用户发起请求时，收到请求的服务器会及时响应，并将用户更新的数据同步到另一台服务器，保证数据一致性。具体的工作流程，如下图和流程所示：（在网络环境稳定、系统无故障的情况下的工作流程）

• 用户 User1 向服务器 Server1 发起请求，将数据库 DB1 中的数据 a 由 1 改为 2；

• 系统会进行数据同步，即图中的 S 操作，将 Server1 中 DB1 的修改同步到服务器 Server2 中，使得 DB2 中的数据 a 也被修改为 2；

• 当 User2 向 Server2 发起读取数据 a 的请求时，会得到 a 最新的数据值 2。
  
  在实际场景中，网络环境不可能百分之百不出故障，比如网络拥塞、网卡故障等，会导致网络故障或不通，从而导致节点之间无法通信，或者集群中节点被划分为多个分区，分区中（内）的节点之间可通信，分区之间不可通信。

3.1 必须满足分区容错性P下的处理方式

这种由网络故障导致的集群分区情况，通常被称为“网络分区”。在分布式系统中，网络分区不可避免，因此分区容错性 P 必须满足。否则user1向server1已经做了更改，而user2从server2请求的时候还是之前的数据，所以一般来说，分布式系统必须满足分区容错性P。

接下来，我们就来讨论一下在满足分区容错性 P 的情况下，一致性 C 和可用性 A 是否可以同时满足。

假设Server1 和 Server2 之间网络出现故障，User1 向 Server1 发送请求，将数据库 DB1 中的数据 a 由 1 修改为 2，而 Server2 由于与 Server1 无法连接导致数据无法同步，所以 DB2 中 a 依旧是 1。这时，User2 向 Server2 发送读取数据 a 的请求时，Server2 无法给用户返回最新数据，那么该如何处理呢？

这里阐述两种处理方式

• 第一种处理方式是，保证一致性 C，牺牲可用性 A：Server2 选择让 User2 的请求阻塞，一直等到网络恢复正常，Server1 被修改的数据同步更新到 Server2 之后，即 DB2 中数据 a 修改成最新值 2 后，再给用户 User2 响应。
  
• 第二种处理方式是，保证可用性 A，牺牲一致性 C：Server2 选择将旧的数据 a=1 返回给用户，等到网络恢复，再进行数据同步。
  -

总结
除了以上这两种方案，没有其他方案可以选择。可以看出：在满足分区容错性 P 的前提下，一致性 C 和可用性 A 只能选择一个，无法同时满足。

3.2 不是必须满足分区容错性P

还是上面的例子，我们分3个场景分析：

• 在保证C（一致性）和P（分区容错性）的情况下

  为了保证数据一致性，server1需要将数据复制给server2，即server1和server2需要进行通信。但是由于网络是不可靠的，我们系统又保证了分区容忍性，也就是说这个系统是可以容忍网络的不可靠的。这时候server2就不一定能及时的收到server1的数据复制消息，当有请求向server2访问a数据时，为了保证数据的一致性，server2只能阻塞等待数据真正同步完成后再返回，这时候就没办法保证高可用性了。

  所以，在保证C和P的情况下，是无法同时保证A的。

• 在保证A（高可用性）和P（分区容错性）的情况下

  为了保证高可用性，server1和server2都有在有限时间内返回。同样由于网络的不可靠，在有限时间内，server2有可能还没收到server1发来的数据更新消息，这时候返回给客户端的可能是旧的数据，和访问server1的数据是不一致的，也就是违法了C（一致性）。

  所以，在保证A和P的情况下，是无法同时保证C的。

• 在保证A（高可用性）和C（一致性）的情况下

  如果要保证高可用和一致性，只有在网络情况良好且可靠的情况下才能实现。这样server1才能立即将更新消息发送给server2。但是我们都知道网络是不可靠的，是会存在丢包的情况的。所以要满足即时可靠更新，只有将server1和server2放到一个区内才可以，也就丧失了P（分区容错性）这个保证。其实这时候整个系统也不能算是一个分布式系统了。

  所以，在保证A和P的情况下，是无法同时保证C的。

3.3 总结

如上所述，分布式系统是无法同时满足CAP三个特性的。

---

四、CAP取舍策略（如何选择策略及应用）

CAP三个特性，没有谁优谁劣，只是在不同的分布式场景适用不同的策略，而取舍策略就是帮助我们面对不同的分布式场景时，知道如何权衡这三个特征，
举例：对于涉及钱的交易时，数据的一致性至关重要，因此保 CP 弃 A 应该是最佳选择。

而对于其他场景，大多数情况下的做法是选择 AP 而牺牲 C（强一致性），因为很多情况下不需要太强的一致性（数据始终保持一致），只要满足最终一致性即可；

• 最终一致性：不要求集群中节点数据每时每刻保持一致，在可接受的时间内最终能达到一致就可以了；

• 强一致性：任何一次读都能读到某个数据的最近一次写的数据，即复制是同步的；

• 弱一致性：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性；

注：关于一致性的具体描述，请参考这篇帖子：

CAP三个特性只能满足其中两个，那么取舍的策略排列组合后也就共有三种：CP、CA、AP

4.1 CA无P

在分布式系统中，现在的网络基础设施无法做到始终保持稳定，网络分区（网络不连通）难以避免。牺牲分区容错性 P，就相当于放弃使用分布式系统。因此，在分布式系统中，这种策略不需要过多讨论。

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。单点系统满足 CA 特性：比如 关系型数据库 DBMS（比如 MySQL、Oracle）部署在单台机器上，因为不存在网络通信问题，所以保证 CA 就可以了。

4.2 CP无A

如果一个分布式场景需要很强的数据一致性，或者该场景可以容忍系统长时间无响应的情况下，保 CP 弃 A 这个策略就比较适合。

若不要求A（高可用性），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一个保证 CP 而舍弃 A 的分布式系统，一旦发生网络分区会导致数据无法同步情况，就要牺牲系统的可用性，降低用户体验，直到节点数据达到一致后再响应用户。

设计成CP的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase、ZooKeeper等。对于这些分布式数据库来说，数据的一致性是最基本的要求。

4.3 AP无C

如果一个分布式场景需要很高的可用性A，或者说在网络状况不太好的情况下，该场景允许数据暂时不一致，那这种情况下就可以牺牲一定的一致性C了。

目前，采用保 AP 弃 C 的系统也有很多，比如 ==CoachDB、Eureka、Cassandra、DynamoDB ==等。

网络分区出现后，各个节点之间数据无法马上同步，为了保证高可用，分布式系统需要即刻响应用户的请求。但此时可能某些节点还没有拿到最新数据，只能将本地旧的数据返回给用户，从而导致数据不一致的情况。

适合保证 AP 放弃 C 的场景有很多。比如，很多查询网站、电商系统中的商品查询等，用户体验非常重要，所以大多会保证系统的可用性，而牺牲一定的数据一致性。典型的应用就如抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。
举例：

假如，上海的网络出现了问题，与北京和杭州网络均不通，此时北京的用户通过北京服务器 A 下单购买了一个电吹风，电吹风数量减少到 59，并且同步给了杭州服务器 B。也就是说，现在用户的查询请求如果是提交到服务器 A 和 B，那么查询到的数量为 59。但通过上海服务器 C 进行查询的结果，却是 60。
待网络恢复后，服务器 A 和 B 的数据会同步到 C，C 更新数据为 59，最终三台服务器数据保持一致，用户刷新一下查询界面或重新提交一下查询，就可以得到最新的数据。而对用户来说，他们并不会感知到前后数据的差异，到底是因为其他用户购买导致的，还是因为网络故障导致数据不同步而产生的。

这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞，因为如果等到数据一致之后再给用户返回的话，用户的响应太慢，可能会造成严重的用户流失。

4.4 总结

五、其他

5.1 事务的ACID与分布式系统的CAP

5.1.1 事务的ACID

1.Atomicity（原子性）
一个事务中的所有操作，要么全部完成，要么全部不完成，不会在中间某个环节结束。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

2.Consistency（一致性）
在事务开始之前和事务结束以后，数据库的完整性没有被破坏。

3.Isolation（隔离性）
数据库允许多个并发事务同时对数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

4.Durability（持久性）
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

5.1.2 区别

可以看到，ACID 中的 A（Atomicity）和 CAP 中的 A（Availability）意义完全不同，而 ACID 中的 C 和 CAP 中的 C 名称虽然都是一致性，但含义也完全不一样。ACID 中的 C 是指数据库的数据完整性，而 CAP 中的 C 是指分布式节点中的数据一致性。

ACID 的应用场景是数据库事务，CAP 关注的是分布式系统数据读写；

5.1.3 CAP 和 ACID 的“C、A”是一样的吗？

首先，我们看一下 CAP 中的 C 和 ACID 中的 C 是否一致。

• CAP 中的 C 强调的是数据的一致性，也就是集群中节点之间通过复制技术保证每个节点上的数据在同一时刻是相同的。
• ACID 中的 C 强调的是事务执行前后，数据的完整性保持一致或满足完整性约束。也就是不管在什么时候，不管并发事务有多少，事务在分布式系统中的状态始终保持一致。
• 总结：事务中的一致性，是指满足完整性约束条件，CAP中的一致性，是指读写一致性。

其次，我们看一下 CAP 中的 A 和 ACID 中的 A。

• CAP 中的 A 指的是可用性（Availability），也就是系统提供的服务一直处于可用状态，即对于用户的请求可即时响应。
• ACID 中的 A 指的是原子性（Atomicity），强调的是事务要么执行成功，要么执行失败。

因此，CAP 和 ACID 中的“C”和“A”是不一样的，不能混为一谈。

5.2 关于BASE 理论

BASE是对CAP中一致性C 和高可用性A权衡的结果

5.2.1概念

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写；

5.2.2 核心思想

核心思想：即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

5.2.3 关于BASE

1. Basically Available（基本可用）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

2. Soft state（软状态）

软状态也称弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3. Eventually consistent（最终一致性）

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

5.3 BASE理论和CAP原则的区别与联系

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。是对一致性C 和高可用性A权衡的结果

前面在剖析 CAP 理论时，提到了其实和 BASE 相关的两点：

• CAP 理论是忽略延时的，而实际应用中延时是无法避免的。
  这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。

• AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性。

  这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。

综合上面的分析，ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

5.4 CAP原则注意事项

1. CAP关注的粒度是数据（对数据的读写操作），而不是整个系统；

2. CAP取舍策略不是一成不变的：在 CAP 理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择不同的策略（CP 还是 AP），而不是直接限定整个系统所有数据都是同一策略。

3. CAP 是忽略网络延迟的。

   当事务提交时，数据能够瞬间复制到所有节点。但实际情况下，从节点 A 复制数据到节点 B，总是需要花费一定时间的。如果是跨地域的机房，例如北京机房同步到广州机房，耗费的时间就可能是几十毫秒。这就意味着，CAP 理论中的 C 在实践中是不可能完美实现的，在数据复制的过程中，节点 A 和节点 B 的数据并不一致。

4. 取舍（放弃）并不等于什么都不做，需要为分区恢复后做准备

   CAP 理论告诉我们三者只能取两个，需要“牺牲”另外一个，这里的“牺牲”是有一定误导作用的，因为“牺牲”让很多人理解成什么都不做。实际上，CAP 理论的“牺牲”只是说在分区过程中我们无法保证 C 或者 A，但并不意味着什么都不做。因为在系统整个运行周期中，大部分时间都是正常的，发生分区现象的时间并不长。例如，99.99% 可用性（俗称 4 个 9）的系统，一年运行下来，不可用的时间只有 50 分钟；99.999%（俗称 5 个 9）可用性的系统，一年运行下来，不可用的时间只有 5 分钟。分区期间放弃 C 或者 A，并不意味着永远放弃 C 和 A，我们可以在分区期间进行一些操作，从而让分区故障解决后，系统能够重新达到 CA 的状态。

六、总结

1. CAP顺口溜：三者不可共存，通常选AP

• C要求数据完全一致
• A要求返回及时
• P要求分布式和数据同步

2. 一致性高，可用性低
   一致性低，可用性高

3. 取舍策略
   CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
   CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
   AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。