分布式系统的 CAP 理论和BASE理论分析

什么是CAP理论？

在一个分布式系统中，一致性(Consistency)、可用性(Availability)和分区容错性（Partition Tolerance）这三个目标无法同时满足，最多只能满足其中两个

数据一致性（C）

概念：分布式系统中的所有节点，在同一时间点上拥有相同的数据副本，比如某个节点数据有更新，那么其他节点数据要跟着更新，要求所有的读请求都必须读到这个新数据一致性

核心要点：

1. 增删改时才会使数据变更影响一致性
2. 数据一致性改变
   当有多个节点时，如果判定数据服务上所有的节点一起发生变更，有的分布式系统有不同的策略配置
   比如mysql的主从集群，当配置为全同步时，每次写数据只有当主库把数据同步到所有从库后才会返回成功（一致性改变）；配置为半同步，只有部分从库同步完数据也会返回成功，这种可能会造成数据不一致

可用性（A）

概念： 可用性是指系统要处于100%的可用状态，对于每一个请求，正常节点要在合理的时间给出正确的响应，即系统能够正常提供服务

核心要点：

1. 合理时间内给出响应：合理的时间是根据业务来定的。业务说要求200ms返回，合理的时间就是200ms，结果是在300ms返回。这个系统仍然是不满足可用性。
2. 系统内只要正常的节点都要做出响应，返回结果，有两种情况：
   • 如果系统内的某个节点或者是某些节点宕机了，但是其他的正常节点可以在合理的时间内做出响应
   • 节点正常，但是节点上的数据有问题，比如不是最新数据，此时如果有请求到达了就要正常返回这个旧数据

分区容错性（P）

概念：分区容错性是指分布式系统能够在网络分区的情况下继续运行对外提供服务，即系统能够在节点之间进行通信的网络出现故障或延迟的情况下，保证系统的正常运行

核心要点：

网络分区只在分布式集群中，在分布式系统中，多个节点之间的网络本来是连通的，但是由于某些故障导致节点之间网络不同了，形成了子集，而子集间网络不同，整个网络就形成了几块区域，就是网络分区

CAP无法同时满足

分布式系统中分区容错性是必要的，因为不考虑分区容错性会存在单点故障问题

由于存在分区容错性，所以存在server2写入x=2失败，而server1写入X=2 成功，那么此时client2和client3就会读取到不一样的值，client2读取到 x=2，而client2读取到 x=3，此时系统可用，但是违背了一致性保证了A，但是违背了C，属于AP架构。假设此时要保持X值的一致性server1和server2的Write 操作必须同时成功，系统必须等待server2也入成功，在失败的这段时间里，系统是不可用状态，这样的话就保证了一致性C，但是也降低了系统的可用性，违背了A，此时属于CP架构。
由此可见，在分布式系统中，无法同时满足 CAP 定律中的“一致性"可用性”和“分区容错性”三者

CAP的选择场景

CP使用场景：

分布式数据库，数据的一致性是最基本的要求；例如Redis这种分布式存储系统以及ZooKeeper这种分布式协调系统。另一个场景就是金融领域，为了资金安全一般需要确保强一致性

AP使用场景：

AP则是适应于用户体验要求高的互联网应用场景，比如社交媒体，内容分发，像微博。用户量大，主机众多，分布式部署，而且集群的规模越来越大，节点故障、网络故障时有发生，要保证系统的可用性，保障AP放弃CP是最常见的做法

CAP不足

CAP最大不足就是CA的取舍问题，实际应用中不是简单二选一，而是会希望各自折中，取舍部分功能。比如，在Zookeeper中，只有在主节点出现问题时，系统才可能出现短暂的不可用状态

BASE理论

BASE理论时对CAP理论的进一步扩展，核心思想是：即使无法实现强一致性，应用程序也可以通过适当的方法达到最终一致性
BASE理论更具工程实践意义的理论，为AP系统提供了整体的工程实践思想。

数据一致性分类：

1. 强一致性：

数据更新操作完成之后，数据立即生效，后续的所有访问当中都能得到最新的结果

2. 弱一致性：

数据更新操作完成后，不要求立即可以读到最新写入的值，能容忍在更新发生之后，部分情况下无法访问到新数据的情况

3. 最终一致性：

数据更新操作完成之后，能容忍更新后一段时间内无法访问到最新数据，不需要实时保证系统数据的强一致性，但是经过一段时间的同步之后，最终可以达到一个一致的状态。所以，最终一致性可以看作是弱一致性的一个特例

BASE理论

BASE理论：“Basically Avaiable, Soft state, Eventual consistency”
基本可用，软状态，最终一致性

基本可用(Basically Available)：

系统在遇到不可预知的故障时，允许损失部分可用性，也就是说即使系统不能完全正常工作，但是仍然有部分功能可用。换句话说，至少能够提供部分服务。例如，响应时间比平时长或者某些功能功能暂时不可用
部分可用：：

• 响应性能变弱：正常情况下请求响应为0.3s，但是出现了某个故障之后，虽然可以正常响应，但是响应时长变为了3s
• 系统功能有损：比如双十一活动时，评论模块出现故障，但不会影响交易、商品等核心模块的流程使用

软状态(Soft state)

允许系统中的数据存在中间状态，这种状态可能是不一致的，但这种中间状态的存在不会影响系统的整体可用性，因为数据在不同节点之间的同步可能存在延迟（通过一些机制如重试、补偿事务等达到一致）

最终一致性(Eventual Consistency)

系统不要求数据实时地达到一致性（存在网络的复制和传播延迟），而是允许数据在一段时间后最终达到一致状态。这意味着在经过一定的时间之后，所有副本的数据会最终到达一致的状态

实际应用体现：

1. 分布式缓存中的缓存降级：缓存系统出现故障，降级为直接访问数据源
2. 服务治理中的：通过服务注册与发现、熔断降级等机制确保服务的可用性和稳定性
3. 分布式数据库中的多节点：通过数据复制，某个节点出现故障，其他节点仍然可以提供服务；主从节点间异步复制提高写入性能（消息队列实现消息传递同理）