Nacos面试

Nacos中的保护阈值的作用是什么?
假如现在有一个服务,本来有10个实例,但是现在挂掉了8个,剩下2个正常实例,此时本来由10个实例处理的流量,就全部交给这个两个正常实例来处理了,此时这两个实例很有可能是处理不过来的,最终导致被压垮,为了应对这种情况,Nacos提供了保护阈值这个功能,我们可以给某个服务设置一个0-1的阈值,比如0.5,那就表示,一旦实例中只剩下一半的健康实例了,比如10个实例,只剩下5个健康实例了,那么消费者在进行服务发现时,则会把该服务的所有实例,也包括不健康的实例都拉取到本地,然后再从所有实例中进行负载均衡,选出一个实例进行调用,在这种情况下,选出来的即可能是一个健康的实例,也可能是挂掉的实例,但是通过这种方式,很好的保护的剩下的健康实例,至少保证了一部分请求能正常的访问,而不至于所有请求都不能正常访问,这就是Nacos中的保护阈值,同时,这个功能在Spring Cloud Tencent中叫全死全活。

 

 

nocosCAP

Nacos的 CP 和 AP 架构的选择,取决于我们配置的服务实例是临时实例还是持久实例

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false   //false:持久化实例,使用 CP架构;true:临时实例,使用 AP架构


Nacos和Eureka区别

  Nacos Eureka
服务发现 Nacos采用定时拉取和订阅推送两种模式 Eureka只支持定时拉取模式
实例类型 Nacos有永久实例和临时实例两种 Eureka 只有临时实例
健康检测 Nacos对临时实例采用心跳检测,对永久实例采用主动请求 Eureka 只支持心跳模式

Nacos和Zookeeper、Consul、eureka服务发现和配置管理工具有什么区别 ?
Nacos、Zookeeper、Consul、Eureka 都是服务发现和配置管理工具

数据一致性:

Eureka是AP(可用性+分区容错)类型的,支持最终一致性。
Zookeeper 和 Consul是CP(一致性+分区容错)类型的,支持强一致性;
Nacos支持 CP+AP模式,即Nacos可以根据配置识别为CP模式或AP模式,默认是AP模式。如果注册Nacos的client节点注册时ephemeral=true,那么Nacos集群对这个client节点的效果就是AP 反之就是CP。
功能特性:

Nacos提供了服务发现、配置管理、动态DNS、流量管理等多个功能;
Zookeeper和Consul也支持服务发现和配置管理,但是不支持流量管理;
Eureka主要是服务发现工具,不支持配置管理和流量管理。
社区活跃度:

Nacos和Consul的社区活跃度较高,有较多的用户和贡献者;
Zookeeper由于已经比较成熟,社区活跃度相对较低,但是稳定性较高;
Eureka的社区活跃度已经较低,维护者已经停止更新。
生态支持:

Nacos和Consul都提供了对Kubernetes的原生支持,可以直接与Kubernetes集成;
Zookeeper和Eureka需要通过第三方工具才能与Kubernetes集成。

 

临时实例与永久实例

临时实例:

临时实例是Nacos的默认注册方式。当服务以临时实例的形式注册时,它仅会存在于Nacos的内存中,而不会持久化到磁盘上。这种实例的健康检查机制采用Client模式,即客户端主动向nacos上报其健康状态。默认的心跳间隔为5秒,如果nacos在15秒内未收到来自客户端的心跳,会将其标记为“不健康”状态;而在30秒内如果收到心跳,则会重新恢复为“健康”状态。如果超过30s未收到心跳,该实例将从服务器内存中清除。

临时实例的特性使其特别适合应对流量突增的场景,服务可以进行弹性扩容,当流量过去后,服务停掉即可自动注销。

例如在容器化的环境中,实例可能在某个容器中启动,并在容器关闭时自动注销。

如果nacos是集群部署,当服务提供者注册到Nacos集群时,它会将自身的信息(如IP地址、端口号、服务名称等)存储到集群中的所有节点中,以确保信息的一致性和高可用性。

永久实例:

永久实例在被删除之前会永久存在于Nacos的注册中心。实例启动时将实例的信息注册到nacos,实例的信息会写到数据库进行存储。永久实例不会主动向注册中心上报心跳。因此,注册中心需要主动进行探活来检查其健康状态。永久实例的好处是运维人员可以实时看到实例的健康状态,便于后续的警告、扩容等操作。此外,它还可以提供阈值保护,当不健康比例超过设定阈值时,会执行熔断降权策略。

是注册到Nacos中的,它们会一直存在,除非手动从Nacos中注销。永久实例通常用于具有长期生命周期的服务,例如基于物理服务器的服务。

 

实例类型的配置:

可以在服务的代码或配置文件中设置实例为临时实例还是永久实例。

spring.cloud.nacos.discovery.ephemeral=true # true为临时实例,false为永久实例




nacos就近访问

就近访问指的是在服务间调用时,Nacos优先选择同一个集群内的实例进行调用。

这种机制是通过设置实例的cluster-name来进行划分集群,并根据cluster-name来判断两个实例是否属于同一个集群。当服务A需要调用服务B时,Nacos会首先查看服务A的实例所属的集群,并在调用服务B时,倾向于选择与服务A相同集群的服务B实例进行调用。

这种就近访问的机制有助于减少网络延迟,提高服务调用的效率。

 

 

 

一、什么是CAP
是一种定理,多用于描述分布式架构,CAP这三个字母对应三种理念,且这三种理念只能两两组合,不能CAP三种理念同时共存(为什么?下面说)。

C:Consisteny(一致性)
A:Availability(可用性)
P:Partition Tolerance(分区容错性)

二、细说CAP
C:Consisteny(一致性),比如数据库是主从模式,一个写库请求进来了,master库完成了写入操作,但是再slave同步数据之前,另一个用户查了这条数据,结果没查到,但是也没报错,这就不是强一致性。虽然最终会同步成功,但这是最终一致性的体现。强一致性的体现在于我不管你因为什么没同步成功(可能网络延迟或其他等),只要没同步成功,我这个slave就不能对外提供服务。必须主从数据一致才可以提供服务。(很少有做到这点的)
A:Availability(可用性),还是上面的例子,就是保证了可用性。因为虽然主从没同步完成,但是我从库照样能提供服务而且及时响应结果。也就是说可用性保证服务可用,而不在乎数据是否一致。明显和C是冲突的,那CA怎么还能组合到一起?后面说。
P:Partition Tolerance(分区容错性),集群部署了三台服务。挂了一台,其他两台还能继续对外提供服务,这时候我就认为他是没问题的,也就是我能容忍你挂了一台,只要还有服务能对外提供请求即可。所以一般分区容忍性是必须的,一般都需要从C和A之间做选择。
三、CAP组合
1、CP
即一致性和分区容忍性。


把节点A和节点B理解成mysq主从的话,那么就是A和B之间不能互相通讯,网络出问题了,当有客户端向A写入msg1的时候,会直接失败,因为C要保证A和B两个节点之间的数据强一致性。
假如有另一个客户端向B节点进行读取msg2消息的时候,B返回是成功的,因为msg2节点是A和B之间网络通顺时存在的老数据,数据是一致的。这就是虽然你A不可用,但是我B还能提供服务,这就保证了分区容忍性。

2、AP
即可用性和分区容忍性。


节点A和B之间不能互相通讯,当有客户端向A节点写入msg1的时候,节点A允许 写入,请求操作成功,但此时由于A和B不能通信,所以导致B节点的msg1的数据是旧的,或者根本不存在。但是另一个客户端向B节点读取msg1的时候是可以成功的,要么读到的是旧数据要么读取不到。但是服务是可用的,只是数据可能有问题。这就保证了可用性,舍弃了强一致性。

 

 

是怎么理解CAP理论的?
CAP理论是分布式领域中最为重要的理论,CAP理论可以理解为目前硬件条件下对于分布式架构的一种限制,就是对于一个分布式系统,只能保证AP或CP,而不能同时保证CAP,首先对于一个分布式系统,P,也就是分区容错性是一定要保证的,对于一个分布式系统,得保证在网络出现分区后,分布式系统仍然能工作,所以得保证P,只不过当出现网络分区后,整个分布式系统如果想要保证数据一致性,那么就要损耗系统可用性,或者如果想要保证系统的可用性,就不能保证系统的一致性,这里说的是强一致性,因为如果网络出现问题,分布式系统中的数据就无法进行及时的同步,如果要求强一致性,那么就只能等网络好了之后,数据同步好了之后,才能提供给用户使用,同理,如果要求网络出现后问题,系统要能使用,那就可能数据会不一致,所以对于一个分布式系统,目前来说只能保证CP或AP

posted @ 2024-06-15 17:16  chenancwj  阅读(22)  评论(0编辑  收藏  举报