浅谈Nacos中的CAP

蔚落 2023-07-22 13:24 14阅读 0赞

# 浅谈Nacos中的CAP #

每天多学一点点~  
话不多说，这就开始吧…

### 文章目录 ###

*  浅谈Nacos中的CAP
 *  1.前言
 *  2.CAP理论和BASE理论
 *  3.Nacos中的CAP
 *  4.Nacos中AP模式源码分析
 *  5.常见的面试题
 *  6.结语

# 1.前言 #

说起CAP原则，大家都不陌生。只要是个分布式系统，都应该满足。之前写过Zk的CAP，今天来谈谈nacos中是如何实现CAP的。

[Zookeeper集群选举机制以及数据同步机制][Zookeeper]  
[Nacos源码环境搭建和源码流程图][Nacos]

# 2.CAP理论和BASE理论 #

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

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：

*  一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
 *  可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
 *  分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

一般分布式系统中，肯定是优先办证P，剩下的就是C和A的取舍。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70]

**BASE**是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。  
**简单来说BASE就是CAP的折中，C A P我三个都要，但不用100%保证每一次原则。**  
![AP集群][AP]

# 3.Nacos中的CAP #

首先，nacos保证了P，**官方推荐使用A，即AP，保证其高可用**。而与之典型的几个注册中心

*  zookeeper(CP 集群leader挂了会重新选举，此时暂停对外服务)。
 *  mysql(单机版CA)
 *  eureka集群(AP)
 *  eureka集群(AP)
 *  redis集群(AP)

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

看过ribbon源码可知，如果发现连接失败，**则会自动切换至其他的节点，只要有一台还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）**

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其他的节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：  
1.Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务  
2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）  
3.当前网络稳定时，当前实例新的注册信息会被同步到其它节点中 因此，Eureka可以很好的应对因网络故障导致节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

而nacos和eureka和类似，上文也说过，有服务健康检查和心跳机制，具体请看上一张源码流程图分析。

# 4.Nacos中AP模式源码分析 #

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

# 5.常见的面试题 #

1.  什么是脑裂：  
    集群（M-S的情况）通常是发生在节点通信不可达(分区)的情况下，集群会分裂成不同的小集群，小集群各自选举出多个master节点的情况。
2.  nacos和zookeeper是如何避免脑裂的？  
    leader选举，要求节点的投票数量>总节点数量/2，即过半数，有这个选举原则保证了集群出现分区，无论如何最多只能有一个小集群选出leader。
3.  M-S 模式的集群节点个数为何推荐是奇数个？  
    首先，偶数个节点的集群一旦出现对半分区(比如4个节点分区成两个节点和两个节点的情况)，整个集群无法选举出leader，集群无法提供服务。  
    其次，在容错能力相同的情况下，奇数节点比偶数节约资源。比如，5个节点挂了2个还能选出leader，而6个节点最多也只能挂2个节点才能保证选举出leader。

# 6.结语 #

**世上无难事，只怕有心人，每天积累一点点，fighting！！！**

[Zookeeper]: https://blog.csdn.net/weixin_42437633/article/details/101850593
[Nacos]: https://blog.csdn.net/weixin_42437633/article/details/105336354
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70]: /images/20230528/0b2c0033e13c4271b00e2f882b36bb08.png
[AP]: /images/20230528/37fa73db76e44721a601e9bd24fa9ad2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 1]: /images/20230528/e2b203c29c4d4f81954558e177113b16.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 2]: /images/20230528/80ef9dae39a2486aa8289129c21f0038.png