CAP理论 和 Base理论

“我正在参加「掘金·启航计划」”

CAP理论

CAP理论是分布式系统设计中的重要概念，它涉及到三个关键属性：

• 一致性（Consistency）：在分布式系统中的所有节点中，数据的状态是一致的。即使在并发读写操作的情况下，所有节点都会看到相同的数据。

• 可用性（Availability）：分布式系统在面对用户请求时，能够提供可用的响应，即系统始终对外提供服务并响应用户的请求。

• 分区容忍性（Partition Tolerance）：分布式系统在面对网络分区（节点之间无法相互通信）时，仍然能够继续运行，并保持一致性和可用性。

根据CAP理论，无法同时满足一致性、可用性和分区容忍性这三个属性。在设计分布式系统时，需要在这三者之间进行权衡和取舍。

证明CAP理论

CAP理论可以通过反证法来证明。如果假设CAP三者都可以同时满足，就意味着系统可以在出现网络分区时保持一致性和可用性。然而，由于网络分区的存在，节点之间可能会发生消息丢失，导致无法保证一致性。因此，CAP理论得出结论，不可能同时满足这三个属性。

不同模型的代表

根据CAP理论，有两种典型的分布式系统架构模型：

• CP架构：在CP架构中，一致性是首要考虑的属性，系统在面对网络分区时会牺牲可用性。典型代表是ZooKeeper，它用于解决分布式集群中的协调和一致性问题。

• AP架构：在AP架构中，可用性是首要考虑的属性，系统可以在面对网络分区时继续提供可用的服务，但可能导致数据的一致性延迟。典型代表是Redis和Eureka，Redis是一个分布式缓存系统，Eureka是Spring Cloud微服务架构中的服务发现组件。

CAP在系统设计中的应用

CAP理论在系统设计中具有重要的指导作用，它提醒我们不要浪费精力设计完美满足三者的分布式系统。根据具体的业务需求和场景，可以根据CAP理论进行取舍和权衡。

一些应用CAP理论的常见场景包括：

• 在强一致性要求较高的场景，如电商交易系统的库存管理，可以选择CP架构，确保数据的一致性。

• 在强一致性要求较低，但可用性要求

较高的场景，如社交媒体应用的消息推送，可以选择AP架构，保证系统的可用性。

• 在涉及数据复制和同步的情况下，需要考虑如何在系统中实现一致性和可用性。

• 在设计容错机制和故障处理策略时，需要考虑网络分区对系统的影响，保证系统的可用性和一致性。

• 在选择数据一致性模型时，可以根据CAP理论选择适合的模型，如强一致性、最终一致性或因果一致性等。

总结：CAP理论指出在分布式系统中无法同时满足一致性、可用性和分区容忍性，需要在设计中进行权衡。CP和AP是CAP理论的两种典型应用模型，分别追求一致性和可用性。在实际系统设计中，可以根据具体的业务需求和场景，结合CAP理论进行选择和优化。

分布式系统的基础——CAP 理论， 包括 CAP 分别代表什么含义、如何证明、CAP 不同模型的典型代表， 以及 CAP 在系统设计中有哪些应用。

CAP理论

分区容忍性具体是指“当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行”， 即系统容忍网络出现分区，并且在遇到某节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。

在分布式系统中，由于系统的各层拆分，P 是确定的， CAP 的应用模型就是 CP 架构和 AP 架构。 分布式系统所关注的，就是在 Partition Tolerance 的前提下，如何实现更好的 A 和更稳定的 C。

CAP 理论的证明

CAP 理论的证明有多种方式，通过反证的方式是最直观的。反证法来证明 CAP 定理，最早是由 Lynch 提出的，通过一个实际场景，如果 CAP 三者可同时满足，由于允许 P 的存在，则一定存在 Server 之间的丢包，如此则不能保证 C。

在分布式系统中，由于系统的各层拆分，P 是确定的，CAP 的应用模型就是 CP 架构和 AP 架构。分布式系统所关注的，就是在 Partition Tolerance 的前提下，如何实现更好的 A 和更稳定的 C。

我们在系统中增加一组节点，因为允许分区容错，Write 操作可能在 Server 1 上成功，在 Server 2 上失败，这时候对于 Client 1 和 Client 2，就会读取到不一致的值，出现不一致的情况。如果要保持 X 值的一致性，Write 操作必须同时失败， 也就是降低系统的可用性。

可以看到，在分布式系统中，无法同时满足 CAP 定律中的“一致性”“可用性”和“分区容错性”三者。

在该证明中，对 CAP 的定义进行了更明确的声明：

Consistency，一致性被称为原子对象，任何的读写都应该看起来是“原子”的，或串行的，写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序；

Availability，对任何非失败节点都应该在有限时间内给出请求的回应（请求的可终止性）；

Partition Tolerance，允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。

一致性 可用性 分区容错性

CAP 理论的应用

分区容忍性具体是指“当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行”，

即系统容忍网络出现分区，并且在遇到某节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。

CAP 理论的应用 CAP 理论提醒我们，在架构设计中，不要把精力浪费在如何设计能满足三者的完美分布式系统上，而要合理进行取舍，CAP 理论类似数学上的不可能三角，只能三者选其二，不能全部获得。

不同业务对于一致性的要求是不同的。

举个例来讲，在微博上发表评论和点赞，用户对不一致是不敏感的，可以容忍相对较长时间的不一致，只要做好本地的交互，并不会影响用户体验；而我们在电商购物时，产品价格数据则是要求强一致性的，如果商家更改价格不能实时生效，则会对交易成功率有非常大的影响。

需要注意的是，CAP 理论中是忽略网络延迟的，也就是当事务提交时，节点间的数据复制一定是需要花费时间的。即使是同一个机房，从节点 A 复制到节点 B，由于现实中网络不是实时的，所以总会有一定的时间不一致。

CP 和 AP 架构的取舍

在通常的分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（Replica），网络分区是既成的现实，于是只能在可用性和一致性两者间做出选择。CAP 理论关注的是在绝对情况下，在工程上，可用性和一致性并不是完全对立的，我们关注的往往是如何在保持相对一致性的前提下，提高系统的可用性。

业务上对一致性的要求会直接反映在系统设计中，典型的就是 CP 和 AP 结构。

CP 架构：对于 CP 来说，放弃可用性，追求一致性和分区容错性。

我们熟悉的 ZooKeeper，就是采用了 CP 一致性，ZooKeeper 是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题。其核心算法是 Zab，所有设计都是为了一致性。在 CAP 模型中，ZooKeeper 是 CP，这意味着面对网络分区时，为了保持一致性，它是不可用的。关于 Zab 协议，将会在后面的 ZooKeeper 课时中介绍。

AP 架构：对于 AP 来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的 Base 也是根据 AP 来扩展的。

和 ZooKeeper 相对的是 Eureka，Eureka 是 Spring Cloud 微服务技术栈中的服务发现组件，Eureka 的各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性。

总结：CP和AP的选择要根据使用场景来决定的。对于分布式服务注册发现的组件，服务端和客户端可以选择长连接，对于一致性要求不必那么高，AP就很合适。对于类似库存、交易等分布式锁场景，要求数据必须准确，就要用CP了。

CAP的内容就是提出了一个不可能三角，并且说明这个三角不成立，所以CAP定义中一致性和可用性的标准非常高，比如一致性是"all nodes see the same data at the same time"，可用性指"Reads and writes always succeed"。分区不一定是每个分区都有一份数据，主备本身就是数据分区了

Q能否总结下hbase、zk、redis等属于cp还是ap，多谢！ 是ap还是cp要看具体的应用场景，比如Redis不同的集群方案可以实现不同的一致性模型。

有个三个疑问

1. P表示容许有个别节点故障，C表示所有节点的数据又强一致。那么CP是怎么实现的呢？
2. "由于允许 P 的存在，则一定存在 Server 之间的丢包，如此则不能保证 C。"如何理解？
3. A、P怎么感觉是一回事？还是说P表示每个节点要有副本，A表示只要有响应就行，不管节点性质(主节点，从节点)?

假设有多个数据分区，为了满足CP，写入之后花很长同步，并且不提供服务。因为不同分区之间通过网络传输，网络传输不是绝对可靠的。

“不同数据一致性模型有哪些应用”？ 对于 CAP 来说，放弃强一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择。

在工程实践中，基于 CAP 定理逐步演化，就提出了 Base 理论。

那么 Base 理论有哪些内容，Base 理论下的一致性模型又有哪些呢？ Base 理论 Base 是三个短语的简写，即基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。

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

接下来我们着重对 Base 理论中的三要素进行讲解。 三个要素详解 基本可用基本可用（Basically Available） 基本可用比较好理解，就是不追求 CAP 中的「任何时候，读写都是成功的」，而是系统能够基本运行，一直提供服务。 基本可用强调了分布式系统在出现不可预知故障的时候，允许损失部分可用性，相比正常的系统，可能是响应时间延长，或者是服务被降级。 举个例子，在双十一秒杀活动中，如果抢购人数太多超过了系统的 QPS 峰值，可能会排队或者提示限流，这就是通过合理的手段保护系统的稳定性，保证主要的服务正常，保证基本可用。

软状态软状态（Soft State） 软状态可以对应 ACID 事务中的原子性，在 ACID 的事务中，实现的是强制一致性，要么全做要么不做，所有用户看到的数据一致。其中的原子性（Atomicity）要求多个节点的数据副本都是一致的，强调数据的一致性。

原子性可以理解为一种“硬状态”，软状态则是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性最终一致性（Eventually Consistent）。 数据不可能一直是软状态，必须在一个时间期限之后达到各个节点的一致性，在期限过后，应当保证所有副本保持数据一致性，也就是达到数据的最终一致性。

在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型、不同数据复制方案设计等因素。

全局时钟和逻辑时钟 接下来我会分析不同数据一致性模型的分类，在这之前，我们先来看一个分布式系统中的全局时钟概念。

分布式系统解决了传统单体架构的单点问题和性能容量问题，另一方面也带来了很多新的问题， 其中一个问题就是多节点的时间同步问题：不同机器上的物理时钟难以同步，导致无法区分在分布式系统中多个节点的事件时序。

没有全局时钟，绝对的内部一致性是没有意义的，一般来说，我们讨论的一致性都是外部一致性，而外部一致性主要指的是多并发访问时更新过的数据如何获取的问题。

和全局时钟相对的，是逻辑时钟，逻辑时钟描绘了分布式系统中事件发生的时序，是为了区分现实中的物理时钟提出来的概念

一般情况下我们提到的时间都是指物理时间，但实际上很多应用中，只要所有机器有相同的时间就够了，这个时间不一定要跟实际时间相同。 更进一步解释：如果两个节点之间不进行交互，那么它们的时间甚至都不需要同步。 因此问题的关键点在于节点间的交互要在事件的发生顺序上达成一致，而不是对于时间达成一致。

逻辑时钟的概念也被用来解决分布式一致性问题，这里我们不展开，感兴趣的可以找一些相关的资料来学习。

不同数据一致性模型 一般来说，数据一致性模型可以分为强一致性和弱一致性，强一致性也叫做线性一致性，除此以外，所有其他的一致性都是弱一致性的特殊情况。 弱一致性根据不同的业务场景，又可以分解为更细分的模型，不同一致性模型又有不同的应用场景。

在互联网领域的绝大多数场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。

对于一致性，可以分为从服务端和客户端两个不同的视角，上面提到了全局时钟概念，这里关注的主要是外部一致性。

强一致性 当更新操作完成之后，任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。

弱一致性 系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。用户读到某一操作对系统数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。

最终一致性 最终一致性是弱一致性的特例，强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

到达最终一致性的时间 ，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

最终一致性模型根据其提供的不同保证可以划分为更多的模型，包括因果一致性和会话一致性等。

因果一致性

因果一致性要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。

进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程 A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值。

因果一致性的应用场景可以举个例子，在微博或者微信进行评论的时候，比如你在朋友圈发了一张照片，朋友给你评论了，而你对朋友的评论进行了回复，这条朋友圈的显示中，你的回复必须在朋友之后，这是一个因果关系，而其他没有因果关系的数据，可以允许不一致。

会话一致性

会话一致性将对系统数据的访问过程框定在了一个会话当中，约定了系统能保证在同一个有效的会话中实现“读己之所写”的一致性，就是在你的一次访问中，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

实际开发中有分布式的 Session 一致性问题，可以认为是会话一致性的一个应用。

CAP 及 Base 的关系 Base 理论是在 CAP 上发展的，CAP 理论描述了分布式系统中数据一致性、可用性、分区容错性之间的制约关系，当你选择了其中的两个时，就不得不对剩下的一个做一定程度的牺牲。

Base 理论则是对 CAP 理论的实际应用，也就是在分区和副本存在的前提下，通过一定的系统设计方案，放弃强一致性，实现基本可用，这是大部分分布式系统的选择，比如 NoSQL 系统、微服务架构。在这个前提下，如何把基本可用做到最好，就是分布式工程师们追求的

除了 CAP 和 Base，上面还提到了 ACID 原理，ACID 是一种强一致性模型，强调原子性、一致性、隔离性和持久性，主要用于在数据库实现中。Base 理论面向的是高可用、可扩展的分布式系统，ACID 适合传统金融等业务，在实际场景中，不同业务对数据的一致性要求不一样，ACID 和 Base 理论往往会结合使用。

base 是对ap方案的补充吗？可以这样理解吗？ 可以这么理解，base是对cap的延伸，如果觉得有必要，可以去翻翻cap相关的论文，会帮助从应用角度理解定理

当比较CAP理论和BASE理论时，我们可以整理成以下的大纲和正文，并提供格式漂亮的Markdown文档以及对比CAP理论和BASE理论的图表。

概要

• CAP理论和BASE理论是在分布式系统设计中涉及到的两个重要理论。
• CAP理论描述了分布式系统中数据一致性、可用性和分区容错性之间的制约关系。
• BASE理论是基于CAP理论发展而来，强调最终一致性和基本可用性。

CAP理论

• CAP理论的核心思想是在分布式系统中，无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个目标。
• 一致性指的是在更新操作完成后，多个进程的访问都会返回最新的更新过的值。
• 可用性指的是系统能够基本运行，一直提供服务，即使在出现不可预知故障的情况下，可以损失部分可用性。
• 分区容错性指的是系统可以继续运行，即使网络中的某些部分发生故障或无法通信。
• 根据CAP理论，当选择其中两个目标时，就不得不对剩下的一个目标做出牺牲。

BASE理论

• BASE是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）的缩写。
• BASE理论的核心思想是系统可以放弃强一致性，通过一定的设计方案实现基本可用性和最终一致性。
• 基本可用性强调系统在出现故障时可以损失部分可用性，例如响应时间延长或服务降级。
• 软状态允许系统中的数据存在中间状态，而不影响系统的整体可用性。
• 最终一致性要求在一定时间期限内，系统中的所有数据副本能够达到一致的状态。

CAP理论与BASE理论的对比

	CAP理论	BASE理论
一致性	强一致性	最终一致性
可用性	有时会牺牲可用性	强调基本可用性
分区容错性	分区容忍	分区容错性
关注点	数据强一致性	最终数据一致性，基本可用性