在一个分布式系统中，数据一致性（Consistency）、系统可用性（Availability）以及分区容错性（Partition Tolerance）这三个分布式系统指标最多只能同时实现其中的两个，三者不可兼得，这就是CAP原理，也被称作CAP定理。

1. 数据一致性（Consistency）

Every read receives the most recent write or an error.

一致性是说，每次请求获取的数据都是最新的数据或者返回错误，而不应该返回过期的数据，这就要求每个区的数据是一致的。

当区之间的通信出现问题时：

• 如果返回错误，系统的可用性（Availability）就有问题（系统不能提供正常数据）；

• 如果各区返回自己的数据，数据就有可能不一致。

例如：

保证系统可用性（Availability）



• 当客户端对v0​修改成v1​，为了满足系统可用性，Partition1会将v0​​修改成v1​，客户端得到最新数据v1​，后面接入到Partition1的请求，得到的也是最新的数据v1​；

• 由于Partition1与Partition2之间无法通信，Partition2仍是数v0​，当请求接入到Partition2时，得到的就是过期的数据v0​，数据不一致。

保证数据一致性（Consistency）



• 由于Partition1与Partition2之间无法通信，为了数据能够保持一致，对于客户端的修改请求，返回错误，系统暂时处于不可用状态，但是Partition1和Partition2的数据仍然保持一致是v0​。

2. 系统可用性（Availability）

Every request receives a (non-error) response, without the guarantee that it contains the most recent write.

可用性是说，每次的请求都应当能够接收到一个响应，而不是返回一个错误或者是失去响应，但是并不保证数据是最新的。

3. 分区容错性（Partition Tolerance)

The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.

大多数分布式系统都分布在多个子网络中，每个子网络就是一个区（Partition），而分区之间的通信可能失败，当出现这种情况时系统应当是仍然可以操作的。

通常认为，分区间的网络通信是不可靠的，很有可能通信失败，所以在做系统设计时，必须要考虑分区容错。CAP原理告诉我们，由于分区容错无法避免，那么数据的一致性（Consistency）和系统可用性（Availability）无法同时满足。

也就是说，当出现消息丢失或延迟时：

• 要保证数据的一致性，在这段时间系统的可用性就无法满足，否则数据就会出现不一致；

• 要想系统可用同时数据还要一致，那么就只能有一个区（Partition），然而对于分布式系统来说这点显然是不可能的。

4. CAP总结

为什么在分布式系统中，数据一致性（Consistency）与系统可用性（Availability）不能同时成立，答案也很简单，就是子网络区（Partition）之间网络的不可靠性，即会出现分区容错。

所以在设计分布式系统时，就需要权衡数据一致性（Consistency）和系统可用性（Availability），根据实际的业务场景设置一个合理目标。

5. 解决方案——BASE理论

BASE理论是由eBay架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统打到最终一致性。



既然数据一致性（Consistency）和系统可用性（Availability）不能够同时满足，做到数据的强一致性（Strong Consistency），那么就需要一种权衡方案，所以这时候BASE理论就诞生了。

BASE理论是基于对大规模互联网系统分布式实践的实践总结，基于 CAP 定理逐步演化而来的。每个应用都可以根据自身的业务特点，采用适当的方式使系统达到最终一致性（Eventual consistency）。

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

5.1 基本可用（Basically Available）

假设系统出现了故障，但是还可以提供服务，相比较正常情况：

• 请求响应时间上的损失，即原本可以在1s内返回结果，而基本可用可在2s内返回结果

• 功能上的损失，即正常情况下业务可以顺利开展，而基本可用一方面可以是部分功能受损，另一方面可以是功能降级

5.2 软状态（Soft State)

软状态是相对硬状态而言的，硬状态是指系统中各节点上的数据都是一致的，而软状态则允许系统中的数据存在中间状态，而这些中间状态并不影响系统的整体可用性，也就是说在分布式系统中多个节点的数据允许存在数据延迟。

5.3 最终一致性（Eventually Consistent）

最终一致性是指系统能够保证数据在没有新的更新操作的情况下，数据最终一定能够达到一致的状态。

对于数据的软状态来说，不能一直都处于软状态，必须有个时间限制，即在时限到达后，各节点的数据应该能够保持数据的一致性。而这个时限与网络延迟、系统负载、数据复制方案设计等因素有关。

在项目实践中，最终一致性主要分为以下5种情况：

• 因果一致性（Causal Consistency）

因果一致性是指，在节点A数据更新后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值；而与节点A无因果关系的节点C的数据访问则没有这样的限制。

• 读己之所写（Read Your Writes）

在节点A更新了一个数据后，在节点A上访问到的该数据一定是更新之后的最新值，而不会是历史值，其实这也算是一种因果一致。

• 会话一致性（Session Consistency）

会话一致性是对系统数据的访问过程限定在了一个会话当中，在一个有效的会话中实现“读己之所写”，即数据更新后，客户端在一个会话中读取到的值始终是该数据的最新值。

• 单调读一致性（Monotonic Read Consistency）

单调读一致性是指如果一个节点返回了一个数据的某个值后，在后续的任何数据访问，该节点都不应该返回比该数据更旧的值。

• 单调写一致性（Monotonic Write Consistency）

单调写一致性是指，一个系统需要保证来自同一节点的写操作能够被顺序地执行。