浅谈Nacos中的CAP
浅谈Nacos中的CAP
每天多学一点点~
话不多说，这就开始吧…
1.前言
说起CAP原则，大家都不陌生。只要是个分布式系统，都应该满足。之前写过Zk的CAP，今天来谈谈nacos中是如何实现CAP的。
Zookeeper集群选举机制以及数据同步机制
Nacos源码环境搭建和源码流程图
2.CAP理论和BASE理论
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：
- 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
- 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
- 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
一般分布式系统中，肯定是优先办证P，剩下的就是C和A的取舍。
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
简单来说BASE就是CAP的折中，C A P我三个都要，但不用100%保证每一次原则。
3.Nacos中的CAP
首先，nacos保证了P，官方推荐使用A，即AP，保证其高可用。而与之典型的几个注册中心
- zookeeper(CP 集群leader挂了会重新选举，此时暂停对外服务)。
- mysql(单机版CA)
- eureka集群(AP)
- eureka集群(AP)
- redis集群(AP)
看过ribbon源码可知，如果发现连接失败，则会自动切换至其他的节点，只要有一台还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其他的节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1.Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）
3.当前网络稳定时，当前实例新的注册信息会被同步到其它节点中 因此，Eureka可以很好的应对因网络故障导致节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
而nacos和eureka和类似，上文也说过，有服务健康检查和心跳机制，具体请看上一张源码流程图分析。
4.Nacos中AP模式源码分析
5.常见的面试题
- 什么是脑裂：
集群（M-S的情况）通常是发生在节点通信不可达(分区)的情况下，集群会分裂成不同的小集群，小集群各自选举出多个master节点的情况。 - nacos和zookeeper是如何避免脑裂的？
leader选举，要求节点的投票数量>总节点数量/2，即过半数，有这个选举原则保证了集群出现分区，无论如何最多只能有一个小集群选出leader。 - M-S 模式的集群节点个数为何推荐是奇数个？
首先，偶数个节点的集群一旦出现对半分区(比如4个节点分区成两个节点和两个节点的情况)，整个集群无法选举出leader，集群无法提供服务。
其次，在容错能力相同的情况下，奇数节点比偶数节约资源。比如，5个节点挂了2个还能选出leader，而6个节点最多也只能挂2个节点才能保证选举出leader。
