分布式基础之CAP理论&BASE理论

1.CAP理论

1.1） 含义

C（Consistency一致性）、Availability（可用性）、Partition Tolerance（分区容错性）

CAP 是 Consistency 、Availability、Partition tolerance 的首字母缩写。所谓CAP原则，简单的说就是不可能存在CAP，即如下图所示，CAP 三个指标只能实现其中两个，而永远无法三者兼具。

 

1.2 ）具体意义

一致性（Consistency）: 所有节点访问同一份最新的数据副本
可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
分区容错性（Partition tolerance）: 分布式系统出现网络分区的时候，仍然能够对外提供服务。(网络分区的概念：分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。)
所谓的三选二：当网络出现分区的时候，P一定要选，CA可以适当的偏向。当网络没有出现分区，CA就没有取舍的必要。（比如 ZooKeeper、HBase 就是 CP 架构，Cassandra、Eureka 就是 AP 架构，Nacos 不仅支持 CP 架构也支持 AP 架构。）

为什么只能同时满足2个

1）如果要满足一致性，并且高可用（CA）

表示必须在短的时间内，得到正确的结果。这就不能允许任何部分有故障（分区容错），因为如果有部分故障，那么其他部分就会：

• 要么接口等很久才得到数据，不满足可用性
• 要么会得到错误的数据，不满足一致性
  比如：没有分区容错性的模式，大多数单体服务都满足这个要求：单机的redis、mysql、oracle等。
  当把mysql和oracle做成多节点之后，具备了分区容错性（P），那将必须在AP或CP模式中选一个。
  

2）如果要满足一致性，并且分区容错（CP）

那表示服务部署在多个节点上，还要总是返回最新且正确的数据。那在部分节点故障时，其他部分就只有等待或请求失败，也就是说系统不是高可用的。

这种模式的其实比较少。比如ZooKeeper，它具有这样的特点：

• 可以多节点部署，单个节点故障不会导致整个系统崩溃，所以它是分区容错的（P）
• 当领导者（Leader）挂掉后，整个系统进入恢复模式，此时是不可用的，直到新的Leader被选举出来。所以ZooKeeper的数据总是一致的（C），但不能保证可用性（A）

3）如果要满足可用性，并且分区容错（AP）---广泛采用的模式

也就是服务部署在多个节点，并且当部分故障时其他节点仍能快速响应。那这个响应的结果，就不能保证是最新且正确的。也就是可能会不一致。

 比如redis集群：

• 集群中的任意节点故障，其他节点仍然可以使用，所以它是分区容错的（P）
• 即使有单点故障，导致数据没有正确广播而产生不一致（C），但仍然能够快速读写数据（A）

2.Base理论

2.1 含义

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

2.2具体意义

核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。
基本可用（允许在故障时牺牲部分非核心功能）
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但这绝不等价于系统不可用。
软状态（数据同步允许一定的延迟）
软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性（不要求数据实时一致）
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别：
1）强一致性 ：系统写入了什么，读出来的就是什么。
2）弱一致性 ：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
3）最终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
实现最终一致性的方法

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

总结

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

CAP 原则，分布式系统参考的三个重要指标。具体是指 Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性。

CAP 原则指出，在一个分布式系统中，不可能同时满足三者，而分区容错性一般是必须具备的重要指标，这也是分布式系统的初衷，因此，实际的业务架构设计中，往往都是对 C 一致性 和 A 可用性的权衡和取舍。

三种类型组合的常见案例：

1、CA ：破坏了分布式系统的设计初衷，单体应用。
2、CP ：传统数据库如 MySQL、各种涉及到银行、金融的交易系统。要求较高的一致性，舍弃用户体验。
3、AP ：电商系统，秒杀等业务场景。但数据会实现最终一致性，追求用户体验的响应性，舍弃一部分实时的一致性，如 Redis 。

BASE 理论，是对CAP实践的进一步指导方针。

基本可用（Basically Available）：顾名思义，即系统允许牺牲一部分用户体验，但决不允许系统无法响应，甚至崩溃。

软状态（Soft state）：允许系统中的备份数据存在中间状态，但也必须是不影响整体系统功能的前提下，即数据备份允许延迟。

最终一致性（Eventually consistent）：在软状态之上增加了时限，要努力达到数据最终是一致的。5 种最终一致性：因果、读自写、会话、单调读、单调写。
注意：分布式系统其实最优先考虑的是分区容错（P），其次是可用性（A），而能够忍受一定程度的数据不一致，这对自建分布式系统也有很大的指导意义。