CAP定理与 BASE 理论

---

最近在总结之前面试腾讯财付通岗位时，面试官考察注册中心的知识点，但写着写着发现有很多功能点需要基础理论支撑、铺垫，如果都写在一篇里篇幅略大，因此决定先总结分布式系统中常用到的理论，方便后续面试经验的理解。

什么是 CAP ？

CAP 理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中：

• 一致性（Consistency）
• 可用性（Availability）
• 分区容错性（Partition tolerance）

最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足 CA，要么 CP，要么 AP，无法同时满足 CAP。

　　

分区容错性：指的分布式系统中的某个节点或网络分区出现了故障时，整个系统仍然能对外提供满足一致性和可用性的服务，也就是说部分故障不影响整体使用。

实际上，我们在设计分布式系统时会考虑到 BUG、硬件、网络等各种原因造成的故障，所以即使部分节点或网络出现故障，我们要求整个系统还能继续使用，如果不不能继续使用，则相当于只有一个分区，就谈不上后续的一致性和可用性了。

可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。

一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。

如何理解 CAP 定理？

首先在保证了分区容错性的前提下，意味着若某个节点故障了，用户还可以继续访问，但这时用户在访问过程中就会出现一致性和可用性不能同时满足的情况，如下图：

假设分布式系统有 S0、S1 两个节点，节点中的变量初始值都是 v0，现在有一个客户端向系统写入了新值 v1，这里假设直接写的是节点 S0，写完之后客户单再去读取这个值，但此时读到了 S1 节点的。

由于 S1 节点与 S0 节点失去连接，这时 S0 节点上的数据还未同步到 S1 节点，因此客户端读取到的是修改之前的值 v0，这就出现不满足一致性的情况了，即满足了可用性，失去了一致性。

类似的，如果系统保证了强一致性，那么在客户端往 S0 节点写完数据后，S0 向 S1 节点同步数据出现了问题，此时如果客户端再去读取 S1 节点的数据，客户端就会一直处于等待阻塞状态，因为系统内各节点数据未同步上，需要等同步上才能使用，即满足了一致性，而失去了可用性。

当考虑多个客户端访问的情景时，一致性与可用性可以这么理解：假设客户端1 向 S0 修改某个值的时候, 写操作还未完成，客户端2就发起来对该值的读操作，但读取的是 S1 节点，这时如果要满足一致性，那么就得让客户端1暂时无法使用，如果要让客户端2可使用，那么获取到的数据不是最新的，系统就不满足一致性。

CAP 三者不可兼得，如何取舍？

1、CA：优先保证一致性和可用性，放弃分区容错，这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。

2、CP：优先保证一致性和分区容错性，放弃可用性。

在数据一致性要求比较高的场合，例如：Zookeeper、Hbase 等是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。

3、AP：优先保证可用性和分区容错性，放弃一致性。在Spring Cloud 体系中使用的 Eureka 注册中心就是这种架构，但放弃一致性只是指放弃强一致性，保证最终一致性。

上面我们提到 CAP 不可能同时满足，而分区容错又是分布式系统必须的。而 BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

什么是 Base 理论

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

Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

Basically Available(基本可用)

基本可用就是假设系统某个模块出现了不可预知的故障，但其他模块依旧可用，例如商城双十一活动时，评论模块出现故障，但不会影响交易、商品等核心模块的流程使用。

Soft State（软状态）

软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时，MySQL Replication 的异步复制就是其中一种体现，还有订单的“支付中”、“数据同步中”等状态，待数据最终一致后状态变更为“成功”状态。

它相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

Eventually Consistent（最终一致性）

上面讲到的软状态不可能一直是软状态，必须有时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性，因此所有客户端对系统的数据访问最终都能够获取到最新的值，而这个时间期限取决于网络延时，系统负载，数据复制方案等因素。

在CAP中的一致性要求在任何时间查询每个节点数据都必须一致，它强调的是强一致性，而最终一致性是允许在一段时间内每个节点的数据不一致，但是经过一段时间每个节点的数据必须一致，它强调的是最终数据的一致性。

在实际情景中，最终一致性分为 5 种：

1. 因果一致性（Causal consistency）

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

2. 读己之所写（Read your writes）

节点 A 更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。

3. 会话一致性（Session consistency）

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

4. 单调读一致性（Monotonic read consistency）

单调读一致性是指如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

5. 单调写一致性（Monotonic write consistency）

指一个系统要能够保证来自同一个节点的写操作被顺序的执行。

对于上面的 5 种最终一致性，在实际系统中往往会结合使用，以构建一个具有最终一致性的分布式系统。

实际上，不只是分布式系统使用最终一致性，在关系型数据库的某个功能上，也是使用最终一致性的，比如数据备份、数据库主从复制等过程是需要时间的，在这个复制过程中，业务读取到从服务器的值是旧的。经过一定时间后，主从服务器才会达成数据一致性，这也算是一个最终一致性的经典案例。

5. 总结

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。