分布式CAP原则与BASE理论

àì夳堔傛蜴生んèń 2023-03-12 14:26 12阅读 0赞

# CAP #

## 含义: ##

CAP原则又称CAP定理，指的是在一个[分布式系统][Link 1]中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

**一致性（C）：**在[分布式系统][Link 1]中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

**可用性（A）：**在集群中一部分节点故障后，[集群][Link 2]整体是否还能响应[客户端][Link 3]的读写请求。（对数据更新具备高可用性）

**分区容忍性（P）：**以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

![format_png][]

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足   。

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：  
  
**CA：**如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库RDBMS：Oracle、MySQL就是CA。  
  
**CP ：**如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。  
  
** AP ：**要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

因此在进行分布式架构设计时，必须做出取舍（根据实际项目要求,选择合适的策略）。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启[服务器][Link 4]，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的  。

# BASE理论 #

## 含义: ##

BASE理论是由eBay架构师提出的。是对 **CAP 理论的延伸**，是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致（Strong Consistency，CAP 的一致性就是强一致性），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

**基本可用(Basically Available)：** 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。  
**软状态(Soft State)：** 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。

注：**硬状态:**相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

**最终一致性(Eventual Consistency)：** 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

而在实际工程实践中，最终一致性分为5种：

**1. 因果一致性（Causal consistency）**

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

**2. 读己之所写（Read your writes）**

读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

**3. 会话一致性（Session consistency）**

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

**4. 单调读一致性（Monotonic read consistency）**

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

**5. 单调写一致性（Monotonic write consistency）**

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

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

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的(通过binlog日志文件复制,肯定会存在网络传输,传输需要时间)，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

# ACID 和 BASE 的区别与联系： #

ACID 是传统数据库常用的设计理念，追求强一致性模型。BASE 支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性,Redis等众多系统构建与这个理论之上。

ACID 和 BASE 代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此 ACID 和 BASE 又会结合使用。

# 总结: #

###     任何理论的存在必有其价值以及使用场景,不会存在任何完美适用于任何场景的理论。因此,在项目设计架构时,根据业务本身的核心需求,知晓哪些是必要的,哪些能容忍,这些需要容忍的方面会不会对整体项目使用产生过大影响(注：如果已经足够影响整体使用了,就应该考虑这样的设计是否合适),其实就是 类似于 "术业有专攻" ,选择合适的设计方案去处理就OK 。 ###

[Link 1]: https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/4905336
[Link 2]: https://baike.baidu.com/item/%E9%9B%86%E7%BE%A4/5486962
[Link 3]: https://baike.baidu.com/item/%E5%AE%A2%E6%88%B7%E7%AB%AF/101081
[format_png]: /images/20230312/42c2721ab0a44f7bafe9071919875201.png
[Link 4]: https://baike.baidu.com/item/%E6%9C%8D%E5%8A%A1%E5%99%A8/100571