CAP理论

系列文章目录

---

---

前言

分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。

分布式系统的最大难点，就是各个节点的状态如何保持一致。CAP理论是在设计分布式系统的过程中，处理数据一致性问题时必须考虑的理论。

---

一、传统ACID

在介绍CAP前，我们先回顾下事务的四个特性

ACID，是指在可靠数据库管理系统(DBMS)中，事务(transaction)所应该具有的四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability).

特性	描述
原子性	原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生，即通常所说的全部或者全都不（all-or-nothing）原则。
一致性	事务前后数据的完整性必须保持一致，即事务是一段从某个数据库一致性状态映射到另一个一致性状态的程序。
隔离性	事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离，即一个正在执行的事务在它提交之前其处理结果不能对其他并发事务可见。
持久性	持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响，即在数据库中永久性地保存事务的处理结果，不会因为故障而被擦除。

---

二、CAP理论

1985年Lynch证明了异步通信中不存在任何一致性的分布式算法（FLP Impossibility）的同时，人们就开始寻找分布式系统设计的各种因素。一致性算法既然不存在，但若能找到一些设计因素，并进行适当的取舍以最大限度满足实现系统需求成为当时的重要议题。比如，在CAP之前研究者就已经发现低延迟和顺序一致性不可能同时被满足【8】。
2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！
这个猜想首次把一致性、可用性和分区容错三个因素提炼出来作为系统设计的重要特征，断言用此三者可以划分所有的分布式系统，并指明这三个特征之间的不可能性关系。Brewer猜想比单纯的“低延迟和顺序一致性不能被同时满足”的结论更具体，对实际系统的构建也更具有可操作性！
Brewer教授当时想象的分布式场景是webservice，一组websevrice后台运行着众多的server，对service的读写会反应到后台的server集群，并对CAP进行了定义：
C（一致性）：所有的节点上的数据时刻保持同步
A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

---

2002年，Lynch与其他人证明了Brewer猜想，从而把CAP上升为一个定理【2】。但是，她只是证明了CAP三者不可能同时满足，并没有证明任意二者都可满足的问题，所以，该证明被认为是一个收窄的结果。
Lynch的证明相对比较简单：采用反正法，如果三者可同时满足，则因为允许P的存在，一定存在Server之间的丢包，如此则不能保证C，证明简洁而严谨。
在该证明中，对CAP的定义进行了更明确的声明【2】：
C：一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。写后面的读一定能读到前面写的内容。所有的读写请求都好像被全局排序。
A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性）
P：允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

2.1、一致性

在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。

任何一个读操作总是能读取到之前完成的写操作结果，也就是在分布式环境中，多点的数据是一致的。

我们通常情况下在数据库中存在的脏数据就属于数据没有具有一致性的表现。而在分布式系统中，经常出现的一个数据不具有一致性的情况是读写数据时缺乏一致性。比如两个节点数据冗余，第一个节点有一个写操作，数据更新以后没有有效的使得第二个节点更新数据，在读取第二个节点的时候就会出现不一致的问题出现。

上面描述的一致性和 ACID 事务中的一致性是两回事。事务中的一致性包含了实际工程对状态的后续处理。但是 CAP 定理并不涉及到状态的后续处理，对于这些问题，后续出现了 BASE 理论等工程结论去处理，目前，只需要明白 CAP 定理主要描述的是状态。

---

2.2、可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。

1、如果节点不能正常接收请求了，比如宕机了，系统崩溃了，而其他节点依然能正常接收请求，那么，我们说系统依然是可用的，也就是说，部分宕机没事儿，不影响可用性指标。
2、如果节点能正常接收请求，但是发现节点内部数据有问题，那么也必须返回结果，哪怕返回的结果是有问题的。比如，系统有两个节点，其中有一个节点数据是三天前的，另一个节点是两分钟前的，如果，一个读请求跑到了包含了三天前数据的那个节点上，抱歉，这个节点不能拒绝，必须返回这个三天前的数据，即使它可能不太合理。

对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。

通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)36524*60 = 5.256 min，这是一个极高的要求。

好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。

---

2.3、分区容错性

分布式系统在遇到网络分区故障（如断网）时，仍能够提供满足一致性或可用性服务。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络） 中，由于一些特殊的原因导致这些子网络出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。 需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

分区指的是，你整个分布式系统不再是连通的。 比如节点分成了两组，彼此之间无法通信。
这种情况，比其中一组全宕机更复杂。因为两组都可能独立对外提供服务。

换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不阻塞（可以使用降级或熔断）。

分区容错性与可用性区别：
可用性关注的是"有限时间内"和"返回结果"，分区容错性关注的是调用不会被阻塞

---

三、CAP理论应用

根据CAP理论，一个分布式系统不可能同时满足C、A、P这三个特性。显然多个节点组成的集群，无法同时满足一致性和可用性，（即保证数据一致又保障有效时间范围内响应，多个节点数据同步需要时间），常见的三种模型：CA, AP，CP。

对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。

---

3.1、CA模型

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

传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

---

3.2、AP模型

要高可用并允许分区，则需放弃一致性。一旦分区节点之间失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

因此，这也是大多数网站架构的首选。

---

3.3、CP模型

如果不要求A（高可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

---

四、base理论

对于本地事务或集中式的事务处理系统，很显然我们应该采用已被证明成熟的 ACID 模型，但当系统不再是一个简单的集中式系统，其访问量巨大且系统结构复杂，导致它必须设计成分布式的架构，对于这样的分布式系统，结点的分布会导致它调用的成本和时间代价非常高。

如果采用传统的 ACID 本地事务的话，所出现的情况就是系统可用性和强一致性之间的冲突。

BASE理论是基于CAP定理逐步演化而来的，BASE 的基本思想是牺牲强一致性，采用基本可用原则（Basically Available）、软状态（Soft state）和最终一致性（Eventually Consistent）来获得可用性和可靠性。其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

ACID 和 BASE 代表了两种截然相反的设计哲学,他们都是关注后续状态变化，CAP理论关注状态。 ACID 注重一致性，是数据库理论的经典设计思路。现代大规模跨区域分布的系统，包括云计算在内，同时运用了这两种思路。

原则	描述
基本可用(Basically Available)	在分布式系统部分损坏的时候，允许部分内容不可用，但是其他部分仍然可用。另外，需要把系统中的所有功能点进行优先级的划分，像资金划拨这样的功能在一致性上不能做出任何让步，必须选择强一致性。而例如邮件发送、通知这样的功能，可以对系统做一个选择，降低其一致性的特性，使其具有高度可用性；
软状态(Soft state)	系统可以有一段时间处于不同步的异步状态，系统内的状态对用户来说是一个完整的系统，从用户的角度系统是提供强一致性的，但是对于系统内部的状态，可以采用柔性的策略，假如系统内分布了 A、B、C 三个功能模块，我们允许它们在某一时刻三个模块的状态可以不一致。通过业务和技术的手段，如异步机制来保证系统通过柔性状态达到最终一致；
最终一致性(Eventually Consistent)	允许数据在一段时间内的不一致，只要保证最终一致就可以了。

各个原则对比，适用场景

原则	描述
基本可用(Basically Available)	出现不可预知故障的时候，允许损失部分可用性(响应时间上和功能上 的损失)，比如：在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态(Soft state)	允许系统中的数据存在中间状态，不影响整体系统使用，数据同步存在延时
最终一致性(Eventually Consistent)	所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态

---

五、实战案例

5.1、消息异步解耦

通过消息解耦流程，可以充分利用服务集群其他节点，增加处理速度，这是典型的AP+base理论场景。

---

5.2、zookeeper

zookeeper是强CP的，Kakfa Broker集群受Zookeeper管理。

kafka的leader选举， 服务的注册与发现

所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功(共同注册/controller，但最终只有一个成功)，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，。也就是为/Controller节点在ZooKeeper注册Watch。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去 Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower 。

与Eureka对比【AP设计】

Zookeeper为CP设计，Eureka为AP设计。作为服务发现产品，可用性优先级较高，一致性的特点并不重要，宁可返回错误的数据，也比不反回结果要好得多。服务列表变更：Zookeeper服务端会有通知，Eureka则通过长轮询来实现。

---

5.2、Nacos

Nacos支持AP与CP模式的切换

CP与AP的适用场景
CP：如果需要在服务级别编辑或者存储配置信息的时候，CP就是必须的，CP模式下则支持注册持久化实例，是以Raft协议为集群运行模式，该模式注册实例之前必须先注册服务，如果服务不存在，则会返回错误
AP：如果不需要存储服务级别信息且服务实例通过nacos-client注册，并能够保持心跳上报，AP模式只支持注册临时实例

---

总结

例如：以上就是今天要讲的内容，本文仅仅简单介绍了CAP理论，总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

参考资料：
1、CAP理论概述
2、CAP理论中的P到底是个什么意思
3、[分布式]：分布式系统的CAP理论