分布式CAP和BASE理论学习笔记

参考至：https://blog.csdn.net/solihawk/article/details/124442443

1. CAP理论

CAP理论是计算机科学家Eric Brewer在2000年提出的理论猜想，在2002年被证明并成为分布式计算领域公认的定理，其理论的基本观念是，在分布式系统中不可能同时满足以下三个特性：

• C：consistency一致性
• A：Availability可用性
• P：Partition Tolerance分区容错性
• 

1.1 Consistency一致性

CAP理论中的一致性指的是Serializability可线性化的意思，也就是非常特殊的强一致性，但是这里的Consistency和ACID中的一致性是两回事，事务中的一致性包含了对状态的后续处理而CAP定理并不涉及到状态的后续处理。因此CAP中的一致性指"all nodes see the same data at the same time"，即更新操作成功后，所有节点在同一时间的数据完全一致。对于一致性的理解，可以从客户端和服务端两个不同的视角来分析：

• 从客户端来看，一致性主要指的是多并发请求时更新过的数据如何获取的问题。如果更新过的数据需要立刻被后续的请求获取到就是强一致性，如果能容忍后续的请求部分或者全部访问不到则是弱一致性，如果经过一段时间后要求能访问到更新后的数据则是最终一致性。
• 从服务端来看，一致性则是数据更新后如何同步到整个分布式系统，以保证数据最终一致性。

举例：如果 B 操作在成功完成 A 操作之后，那么整个系统对 B 操作来说必须表现为 A 操作已经完成了或者更新的状态。

如果系统内部发生了故障从而导致系统的节点无法发生一致性变化，比如N2节点无法同步N1节点的数据。这也意味着客户端查询最新数据的时候，部分节点很可能会看到旧数据，或者说获取到不同版本的数据。此时，为了保证分布式系统对外的数据一致性，于是选择不返回任何数据。

1.2 Availability可用性

可用性指"reads and writes always succeed"，即要求系统内的节点们接收到了无论是写请求还是读请求，都要能处理并给回响应结果。同时有几点必须满足的条件：

1. 返回结果必须在合理的时间以内，这个合理的时间是根据业务来定的，如果超过业务规定的返回时间这个系统也就不满足可用性；
2. 系统能所有能正常接收请求的节点都能返回结果，如果节点宕机了不能正常接收请求但是其它节点可以正常返回，可以说系统依然是可用的，不影响可用性指标。如果所有节点都能返回，但是返回的数据不一致，其中一个节点是1天前的数据，另一个是1s前的，也称为系统可用的

1.3 Partition tolerance分区容错性（容忍网络断开）

分布式系统架构下会有多个节点，这些节点之间通过网络进行通信，但是当网络故障或其它原因节点之间通信出现异常，当前的分布式系统就出现了分区。分区容错性指"the system continues to operate despite arbitrary message loss or failure of part of the system"，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

2. CAP之间的取舍

根据CAP理论，在分布式系统中无法同时满足一致性、可用性和分区容错性，在实际应用中又如何来进行取舍。

2.1 CA模型

舍弃分区容错性意味着将所有的服务器搬到一个网络节点内，显然不满足分布式系统的可伸缩性扩展要求。因此在分布式系统中P是一个基本要求，不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。所以，对于分布式系统，我们只能能考虑当发生分区错误时，如何选择一致性和可用性。CA模型常见的例子包括单站点数据库、集群数据库、LDAP和XFS文件系统等，通常是通过两阶段提交和缓存验证协议实现的。

2.2 CP模型（常用）

舍弃A保证Consistency，不同节点之间需要保证数据的一致性，但是因为网络分区的不稳定，可能出现其它节点的数据没有及时更新。如果一个分布式系统不要求强的可用性，即允许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。这样的分布式系统一旦发生网络故障或者消息丢失等情况，就要牺牲用户体验，等数据一致后再让用户访问系统。CP模型下典型的场景是分布式数据库，通过悲观锁机制或少数分区不可用来优先保证数据一致性。像分布式缓存Redis、分布式协调中心Zookeeper，满足分布式系统下的数据一致性是最基本的要求。

2.3 AP模型

AP模型是在保证高可用和分区容错性的同时，舍弃数据一致性。为了保证高可用性，分布式系统下的不同节点需要立即返回结果给客户端，这样可能会出现不同节点之间的数据不一致，也就是会出现全局数据的不一致。也可以说是舍弃了数据的强一致性，保证的是数据的最终一致性（BASE理论）。AP模型使用的场景非常多，在一些高并发的系统中利用排队和乐观锁机制优先保证系统的可用性，避免造成系统的阻塞。

3. CAP理论的理解

CAP理论的三种特性不是Boolean类型，而是范围类型。比如对于可用性，与业务的时延要求有关，当业务的时延要求降低后，又能达到可用性要求。对于分区容错性，在Raft多数派选举机制下，当多数节点出现问题后才会投票确认分区出现故障。

3.1 CAP三选二的误导性

CAP理论中三个特性只能满足二个其实有一定的误导性。首先，在系统不存在分区P的情况下就没什么理由牺牲C和A。其次，C与A之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，甚至因为特定的数据或用户需求而有所不同。最后，这三种性质都可以在程度上衡量，并不是非黑即白的有或无。

可用性显然是在0%到100%之间连续变化的，一致性分很多级别（强一致性、弱一致性和最终一致性），连分区也可以细分为不同含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。

3.2 CAP理论下多副本分布式数据库

在分布式数据库系统中，分区容忍性是必须的，分区是始终会存在的，因此需要在一致性和可用性之间进行权衡。

• CP without A：分布式系统容许系统停机或者长时间无响应，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。传统的分布式数据库事务都属于这种模式，对于金融行业的分布式数据库产品而言，优先保证数据的一致性。
• AP without C：分布式系统中允许数据不一致，一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

3.3 CAP的不足

根据专家的分析，CAP并不是一个严谨的定律，并不是牺牲了Consistency，就一定能同时获得Availability和Partition Tolerance。CAP定理有以下不足：

1. CAP 定理本身是没有考虑网络延迟的问题的，它认为一致性是立即生效的，但是，要保持一致性，是需要时间成本的，这就导致往往分布式系统多选择AP方式
2. 由于时代的演变，CAP定理在针对所有分布式系统的时候，出现了一些力不从心的情况，导致很多时候它自己会把以前很严谨的数学定义改成了比较松弛的业务定义，类似于我们看到，CAP定理把一致性、可用性、分区容错都变成了一个范围属性，而这和CAP定理本身这种数学定理般的称呼是有冲突的，出现了不符合数学严谨定义的问题。
3. 在实践中以及后来CAP定理的提出者也承认，一致性和可用性并不仅仅是二选一的问题，只是一些重要性的区别，当强调一致性的时候，并不表示可用性是完全不可用的状态。比如，Zookeeper只是在master出现问题的时候，才可能出现几十秒的不可用状态，而别的时候，都会以各种方式保证系统的可用性。而强调可用性的时候，也往往会采用一些技术手段，去保证数据最终是一致的。CAP定理并没有给出这些情况的具体描述。
4. CAP理论从工程角度来看只是一种状态的描述，它告诉大家当有错的时候，分布式系统可能处在什么状态。但是，状态是可能变化的。状态间如何转换，如何修补，如何恢复是没有提供方向的。

4. BASE理论

在分布式系统中，面对CAP权衡时，通常的做法会选择AP舍弃C（舍弃强一致性但保证最终一致性），这其实也是分布式领域的另外一个理论，叫BASE理论。BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。BASE理论是对CAP理论的延伸，其核心思想是：

即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）

4.1 基本可用（Basically Available）

基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

• 响应时间上的损失：正常情况下的客户端请求0.5s即返回给用户结果，而基本可用的情况下可以在1秒甚至2s返回结果，超过一定阈值用户就接受不了
• 功能上的损失：在一个购物网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了促销活动期间，为了保障购物系统的稳定性，部分消费者可能会被引导到一个服务降级页面。

4.2 软状态（Soft State）

软状态是相对原子性来说的

• 原子性（硬状态）：要求多个节点的数据副本都是一致的，这是一种"硬状态"
• 软状态（弱状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延迟

比如在分布式数据库MySQL的复制中一般一份数据会有多个副本，允许不同节点间副本同步的延时就是软状态的体现

4.3 最终一致性（Eventual Consistency）

系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。最终一致性是弱一致性的特定形式，官方的定义是：

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

5.经典一致性算法

5.1 Paxos

Paxos是基于消息传递且具有高度容错特性的强一致性算法，开源的ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性问题

该算法的目标是：在不同的节点间，对一个key的取值达成共识（同一个值）。

5.2 Raft

Raft实现了和Paxos一样的功能，将分布式一致性分解为多个子问题：Leader选举（Leader election）、日志同步（Log replication）、安全性（Safety）、日志压缩（Log compaction）、成员变更（Membership change）等

6. 一致性哈希

https://itcgg.blog.csdn.net/article/details/124572825

传统哈希方法在增加或者减少服务器节点时，会导致哈希得到的结果不一致，从而将流量全导向后台服务器，造成缓存雪崩。一致性哈希，该算法可以有效解决分布式存储结构下动态增加和删除节点带来的问题。

​ 原理：构造出一个哈希环，将每个节点都放在一个哈希环上，当用户需要获取资源时，都在哈希环上顺时针查找，找到的第一个节点就是资源存储的位置，当新加入一个服务器节点时，只会使一部分缓存失效，不会像传统方法一样全部失效，当减少一个节点时，同理。

​ 缺点：容易造成哈希倾斜，节点并不会理想的均匀在哈希环上分布，负载均衡不均匀。

​ 解决方法：虚拟出多个节点，由一个真实服务器节点虚拟出多个虚拟节点分布在哈希环上，当请求资源时，先找到虚拟节点，再找到虚拟节点的真实节点，最后获取到资源。