分布式系统的 CAP 定理与 BASE 理论

本文转载自微信公众号「码农私房话」，作者GoQeng。转载本文请联系码农私房话公众号。

最近在总结之前面试腾讯财付通考察注册中心的知识点，但写着写着发现有很多功能点需要基础理论铺垫，因此决定先总结分布式系统中常用的理论，方便后续对面试考察点的理解。

什么是 CAP ?

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

• 一致性(Consistency)
• 可用性(Availability)
• 分区容错性(Partition Tolerance)

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

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

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

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

如何理解 CAP ?

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

情景一：

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

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

情景二：

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

情景三：

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

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

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

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

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

什么是 BASE 理论 ?

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

Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。

其核心思想是：既然无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

Basically Available(基本可用)

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

Soft State(软状态)

软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

用户在商城下单时，因网络超时等因素，订单处于“支付中”的状态，待数据最终一致后状态将变更为“关闭”或“成功”状态。

Eventually Consistent(最终一致性)

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

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

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

1. 因果一致性(Causal consistency)

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

2. 读己之所写(Read your writes)

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

3. 会话一致性(Session consistency)

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

4. 单调读一致性( Read consistency)

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

5. 单调写一致性(Write consistency)

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

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

实际上，不只是分布式系统使用最终一致性，在关系型数据库的某个功能上，也是使用最终一致性的，比如数据备份、数据库主从复制等过程是需要时间的。

在复制过程中，业务读取从服务器的值是旧的，经过一定时间后，主从服务器才会达成数据一致性，这也是最终一致性的经典案例。

最后总结

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

本文转载自网络，原文链接：https://mp.weixin.qq.com/s/WrWgCzmwCOjUzsGH8oiCzg
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！