深入理解分布式、微服务中CAP定律和BASE理论

灰太狼 2023-07-23 07:57 94阅读 0赞

## 一、背景 ##

随着互联网的快速蔓延，各种传统项目(单体应用的架构)已经不能够满足当前各种复杂的需求场景，都逐渐向分布式服务、微服务做转换，而如今分布式、微服务架构已经普遍存在互联网公司的项目中，像大型电商网站等几乎都是分布式、微服务架构的。因此分布式和微服务架构就显得尤为重要了，这也是对一个架构师考验的提升。

分布式和微服务系统的最大难点，就是各个节点之间的状态如何保持同步，同时这也是理解分布式、微服务的起点思想，在设计和部署分布式系统时，所有分布式及微服务系统的架构设计都离不开`CAP定律`和`BASE理论`，而且必须遵循`CAP定律`和`BASE理论`，在C、A二者之间做取舍。 那么下面我们就来探讨下经典的`CAP定律`和`BASE理论` 以及现实项目场景中常见的CAP定律组合。

## 二、CAP定律 ##

### 1. 什么是CAP定律 ###

**CAP理论是分布式架构中重要理论，分布式系统的架构设计需遵循这一原则。**

*  **一致性(Consistency) ：** 即所有节点在同一时间具有相同的数据。
 *  **可用性(Availability) ：** 保证每个请求不管成功或者失败都有响应。
 *  **分隔容忍(Partition tolerance) ：** 系统中任意信息的丢失或失败不会影响系统的继续运作

`CAP`定律的内容是指的是在一个分布式系统中、`Consistency（一致性）`、`Availability（可用性）`、`Partition tolerance（分区容错性）`，三者不可得兼，`CAP`即三个英文单词的缩写，在分布式及微服务系统中统称为`CAP定律`或 `CAP理论`。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70]  
上图是一个经典的CAP定律解释图，下面我们来详细的解释下微服务、分布式经典的CAP定律相关概念。

### 2. Consistency（一致性） ###

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）  
**白话理解：**  
在设计或者部署一个分布式系统时，假设存在两个Redis库，分别是Redis主和Redis从库，用户在往数据库插入一笔记录 ，那么会在保存到数据库的同时也会实时的插入到Redis缓存中，并且主从库保持同步，如果这时候向数据库查询，在网络延迟的情况下，在同一时刻，Redis主和Redis从库查询到的数据应该是一致性的，每个节点的数据是相同的，不能允许有脏读。

### 3. Availability（可用性） ###

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）  
**白话理解：**  
假设在分布式部署中，有以下集群部署节点，如果`Tomcat1`出现故障，`Nginx`会自动做故障转移，自动将请求转移到`Tomcat2`和`Tomcat3`，`Nginx`故障转移可帮助我们实现集群环境的可用性![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70 1]

### 4. Partition tolerance（分区容错性） ###

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。  
**白话理解：**  
分区容错性是指系统能够容忍节点之间的网络通信的故障，假设我们有一台`Tomcat`服务器，部署在全国各地，像浙江节点、上海节点、武汉节点，但是可能出现其中某个节点由于网络故障不能使用，无法进行通讯；一般来说，现实中分区容错是无法避免的，因此可以认为 `CAP`的 `P`总是成立。`CAP`定理告诉我们，剩下的 `C` 和 `A` 无法同时做到。

### 5. 常见的CAP定律组合 ###

在分布式、微服务系统中，`CAP`定律只能在`A`和`C`之间做取舍，三者无法同时兼顾，其中可以容忍网络之间出现的通讯故障，只能`CP`和`AP`二选一。

*  **CP：** 当网络出现故障之后，只能保证数据一致性，但是不能保证可用性(`Zookeeper`集群过半数节点宕机时保证了数据一致性，为CP实现者），意味着服务不能用；
 *  **AP：** 当网络出现故障之后，不能保证数据一致性， 但是能保证可用性(比如`Eureka`的采用去中心化思想和自我保护机制，实现了`AP`)，意味着可允许短暂的数据不一致性问题，但最终需达到一致，其他节点可正常提供服务，如此保证了可用性但牺牲了一致性；

## 三、BASE理论 ##

`BASE`是`Basically Available`（基本可用）、`Soft state`（软状态）和 `Eventually consistent`（最终一致性）三个短语的缩写。`BASE`理论是对`CAP`中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于`CAP`定理逐步演化而来的。**`BASE`理论的核心思想是：** **即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。**

> **注意：** 在分布式系统中，不可能存在强一致性问题

### 1、基本可用 ###

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

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

### 2、软状态 ###

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

### 3、最终一致性 ###

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

## 四、一致性问题 ##

### 1. 一致性基本思想 ###

**`在分布式系统中，无法保证强一致性，因为短暂的数据存在延迟是允许的，但是最终数据一定要保持数据一致性。`**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70 2]

### 2. 强制一致性 ###

第一步在修改数据库的name = 李四的时候，第二步读取的name内容；如果要一定读取到name为李四而不是张三的话，那么数据库之间的通讯要非常迅速或者说第二步需要等待第一步更新同步完成之后再去做查询，这种流程我们称为强一致性，但是在分布式系统中这种强一致性是不可能存在的，各个服务之间在网络通讯的情况下，肯定存在延迟或者故障的。

### 3. 弱一致性 ###

允许数据库之间同步数据存在短暂的延迟，第二步可以读取name内容为张三而不是必须为李四；这种例子我们可以称作为弱一致性；

### 4. 最终一致性 ###

允许第二步读取name为张三，中间允许数据库存在短暂延迟、但是最终的读取数据结果必须为李四，所以这种例子我们称作为最终一致性；

## 五、Eureka、Zookeeper、Consul区别 ##

### 1. CAP定律 ###

*  C(一致性) 各个节点数据必须统一保持一致；
 *  A(可用性) 保证服务的高可用 必须返回响应结果
 *  P(分区容错) 网络分区可能会造成脑裂问题，部分server与集群其他节点失去联系 无法组成一个群体；  
    不能三者兼顾 只能实现取舍 CP、AP、CA

### 2. Eureka与Zookeeper区别； ###

*  **相同点：**
    
     *  都是可以实现服务注册与发现 ；
 *  **不同点：**
    
     *  SpringCloud中采用Eureka作为注册中心；
     *  Dubbo中采用Zookeeper作为注册中心；
     *  Zookeeper如果有过半数服务宕机了，可能存在无法使用，但保证了一致性，短暂牺牲可用性`(保证CP)`；
     *  Eureka如果有服务宕机了，保证其他服务可用即可，保证了可用性，短暂牺牲一致性`(保证AP)`；

### 3. 所有服务注册中心相同原理 ###

**原理：** 我可以允许暂短读取到原来的老数据服务注册地址信息，但是必须保证注册中心可用，最终需一致性；

### 4. Zookeeper作为注册中心原理： ###

`保证CP（一致性）`，Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果。当我们在集群集群环境中，如果某个节点发生了宕机的情况，需要重新实现选举策略，选举的过程中需要一些时间。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，`Zookeeper` 底层采用`zab`协议保持集群之后的每个节点数据一致性，这就导致`Zookeeper`不能正常使用。如果`Zookeeper`集群中半数以上服务器节点不可用，那么将无法处理该请求。因此，Zookeeper 不能保证服务可用性，但保证了数据的一致性。

### 5. Eureka作为注册中心原理： ###

`保证AP（可用性）`，`Eureka`采用去中心化思想，如果使用`Eureka`实现集群，它的每个节点都是相等的；没有主从概念 ，采用相互注册原理 ，如果客户端访问的`eureka`宕机之后会自动切换其他`eureka`节点；只要能够有一台`eureka`服务正常使用，整个服务注册中心就使用；

### 6. Consul强一致性C带来的是： ###

*  服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
 *  Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

## 六、Nacos与Eureka区别 ##

### 1. 从CAP模式上的区别 ###

*  `eureka`采用`AP`设计理念实现注册中心。
 *  `nacos` 底层默认采用`AP`模式，从`1.0`版本以后采用`AP`\+`CP`混合模式实现注册中心，既支持`AP`也支持`CP`，可切换成`CP`模式，`CP`模式时底层使用`Raft`算法进行选举。

### 2. 从实现高可用集群的协议区别 ###

*  `Eureka`实现高可用是采用去中心化思想，没有主从之分，也就是没有`Leader`角色，每个节点都是相等，采用相互注册原理。
 *  `Nacos`从1.0版本支持`CP`和`AP`混合模式集群，默认是采用`Ap`保证服务可用性; `CP`的形式底层集群采用`raft`协议保证数据的一致性的问题，选举`Leader`角色。

## 七、主流的注册中心产品 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70]: /images/20230528/3ec53aadb4f949a6b7143ca97450a417.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70 1]: /images/20230528/18dcc9e0af314463a4ba4748d72a1e8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70 2]: /images/20230528/142184383a4b4a75899058d7b6b623d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RoaW5raW5nY2Fv_size_16_color_FFFFFF_t_70_pic_center]: /images/20230528/210b85a6aef142499507804a96e68fd2.png