参考：

java guide : https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html

凤凰架构：https://icyfenix.cn/distribution/consensus/

 

CAP

CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能同时满足以下三点中的两个：

  • 一致性（Consistency） : 所有节点访问同一份最新的数据副本
  • 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
    • 如果放弃可用性（CP without A），意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制地延长。A 可用性通常是建设分布式的目的。
  • 分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。
    • 如果放弃分区容忍性（CA without P），意味着我们将假设节点之间通信永远是可靠的。永远可靠的通信在分布式系统中必定不成立的，这不是你想不想的问题，而是只要用到网络来共享数据，分区现象就会始终存在。P 是分布式网络的天然属性。

什么是网络分区？

分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络问题，或者部分节点挂掉了）某些节点之间不连通了，整个网络就分成了几块区域，这就叫 网络分区。

只能 AP 或 CP 而不是 3 选 2

3 选 2 是有误导性的。因为如果放弃分区容忍性（CA without P），意味着我们将假设节点之间通信永远是可靠的。永远可靠的通信在分布式系统中必定不成立的，这不是你想不想的问题，而是只要用到网络来共享数据，分区现象就会始终存在。P 是分布式网络的天然属性。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。 

在 CAP 理论诞生 12 年之后，CAP 之父也在 2012 年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

简而言之就是：CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

 

选择放弃一致性的 AP 系统目前是设计分布式系统的主流选择，因为 A（Available） 通常是建设分布式的目的，如果可用性随着节点数量增加反而降低的话，很多分布式系统可能就失去了存在的价值。

而银行、证券这些涉及金钱交易的服务，宁可中断也不能出错，需要选择 保证一致性C 放弃可用性A 的 CP 系统，否则多数系统是不能容忍节点越多可用性反而越低的。

  • ZooKeeper、HBase 就是 CP 架构（Zookeeper 在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的）
  • Cassandra、Eureka 就是 AP 架构 （Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。Eureka只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的）
  • Nacos 不仅支持 CP 架构也支持 AP 架构。

另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证 P 的时候，C 和 A 能够同时保证。



BASE

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中牺牲掉一致性的 AP 方案的一个补充。

  • Basically Available（基本可用）
  • Soft-state（软状态） 
  • Eventually Consistent（最终一致性）

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

AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

1.基本可用（Basically Available）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

什么叫允许损失部分可用性呢？

  • 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
  • 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

2.软状态（Soft-state）

指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3.最终一致性（Eventually Consistent）

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

分布式一致性的 3 种级别：

  1. 强一致性：系统写入了什么，读出来的就是什么。

  2. 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。

  3. 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

那实现最终一致性的具体方式是什么呢? 《分布式协议与算法实战》open in new window 中是这样介绍：

  • 读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。
  • 写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。
  • 异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。

比较推荐 写时修复，这种方式对性能消耗比较低。