1. CAP 原理



1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）。它们的第一个字母分别是 C、A、P，Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。





• Consistency（一致性）：读操作一定能读到最新的值。

• Availability（可用性）：一个用户请求一定能收到响应。

• Partition tolerance（分区容错性）：分布式系统分布在多个子网络中，当部分子网络出现故障时，分布式系统依然能提供最初设计的一致性或者可用性服务。



任何分布式系统只可同时满足二点，没法三者兼顾。

2. CAP 原理证明

如下图所示，在网络中有两个节点分别为G1和G2，这两个节点上存储着同一数据的不同副本，现在数据是一致的，两个副本的值都为V0，A、B分别是运行在G1、G2上与数据交互的应用程序。





网络节点及数据分布图



在正常情况下，操作过程如下(如下图所示)：

• (1)A将V0更新，数据值为V1;

• (2)G1发送消息m给G2，数据V0更新为V1;

• (3)B读取到G2中的数据V1。



正常情况



如果发生网络分区故障，那么在操作的步骤(2)将发生错误：G1发送的消息不能传送到G2上。这样数据就处于不一致的状态，B读取到的就不是最新的数据，如下图所示。

网络分区故障



如果我们采用一些技术如阻塞、加锁、集中控制等来保证数据的一致，那么必然会影响到系统的可用性和分区容错性。

3. 常见 NoSQL 的 CAP 归类

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：



CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。



CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。



 AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。Cassandra就是这样的分布式数据库。典型的应用就如小米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。





4. 参考资料

• CAP为什么不能同时满足

• CAP 定理的含义