Spring Cloud面试篇-编程知识

面试篇-nacos面试题

1. springboot常见组件

注册中心组件：Eureka、Nacos
负载均衡组件：Ribbon
远程调用组件：OpenFeign
网关组件：Zuul、Gateway
服务保护组件：Hystrix、Sentinel
服务配置管理组件：SpringCloudConfig、Nacos

2. nacos注册表的结构

回答: 分级存储模型。下图是nacos服务的分级存储模型

对上图的解释: Nacos采用了数据的分级存储模型，最外层是Namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），Cluster下是不同的实例（Instance）。对应到Java代码中，Nacos采用了一个多层的Map来表示。结构为Map<String, Map<String, Service>>，其中最外层Map的key就是namespaceId，值是一个Map。内层Map的key是group拼接serviceName，值是Service对象。Service对象内部又是一个Map，key是集群名称，值是Cluster对象。而Cluster对象内部维护了Instance的集合

3. nacos解决高并发

nacos如何解决高并发的注册压力？
回答: Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放入一个阻塞队列就立即响应给客户端。然后利用线程池读取阻塞队列中的任务，异步来完成实例更新，从而提高并发写能力

4. nacos并发读写冲突

Nacos如何避免并发读写冲突问题？
回答: Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了

5. nacos与eureka的区别

接口方式：Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能
实例类型：Nacos的实例有永久和临时实例之分；而Eureka只支持临时实例
健康检测：Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测；Eureka只支持心跳模式
服务发现：Nacos支持定时拉取和订阅推送两种模式；Eureka只支持定时拉取模式

面试篇-sentinel面试题

1. 线程隔离的方式

线程隔离有两种方式实现
●线程池隔离（Hystix默认采用）
●信号量隔离（Sentinel默认采用）

	优点	缺点	场景
线程池隔离	支持主动超时，支持异步调用	线程的额外开销比较大	低扇出
信号量隔离	轻量级，无额外开销	不支持主动超时，不支持异步调用	高频调用，高扇出

2. 限流相关的算法

限流：对应用服务器的请求做限制，避免因过多请求而导致服务器过载甚至宕机。限流算法常见的包括三种
●计数器算法，又包括窗口计数器算法、滑动窗口计数器算法
●令牌桶算法（Token Bucket）
●漏桶算法(Leaky Bucket)
固定窗口计数器算法概念如下:
一、将时间划分为多个窗口(下图的蓝虚线)，窗口时间跨度称为Interval，本例中为1000ms
二、每个窗口维护一个计数器，每有一次请求(下图的绿块)就将计数器加一，限流就是设置计数器阈值(下图的红虚线)，本例为3秒
三、如果计数器超过了限流阈值，则超出阈值的请求都被丢弃(下图的橙块)
四、缺点: 紫色部分的情况，虽然两个窗口都能容纳3个请求，但是在那1秒你实际要应对6个请求，就会超出阈值设定的3秒，给服务器造成压力

滑动窗口计数器算法会将一个窗口划分为n个更小的区间，如下:
一、窗口时间跨度为1秒(下图的每两个绿虚线块)，区间数量 n = 2 (每秒有两个小窗口，即有两个绿虚线块)，则每个小区间时间跨度为500ms
二、限流阈值(下图的红虚线)依然为3，时间窗口(有两个小窗口，共表示1秒) 内请求(绿块)超过阈值时，超出的请求被限流
三、窗口会根据请求的当前时间来移动，窗口范围是从'当前请求时间减时间跨度' 之后的第一个时区开始，到所在时区结束
四、滑动窗口是通过把单个窗口细分为多个窗口，作用是尽可能避免固定窗口的问题
五、缺点: 只要是窗口就会存在请求超出阈值但被放行的结果。例如1250ms~2100ms，间隔了850毫秒，但是放行了4个请求，不符合1秒最多3个请求的阈值

令牌桶算法如下:
一、以固定的速率(相当于限流)生成令牌，存入令牌桶中，如果令牌桶满了以后，多余令牌丢弃
二、请求进入后，必须先尝试从桶中获取令牌，获取到令牌后才可以被处理
三、如果令牌桶中没有令牌，则请求等待或丢弃
四、桶里面放的是令牌

漏桶算法如下:
一、将每个请求视作"水滴"放入"漏桶"进行存储
二、"漏桶"以固定速率向外"漏"出请求来执行，如果"漏桶"空了则停止"漏水”
三、如果"漏桶"满了则多余的"水滴"会被直接丢弃
四、可以理解成请求在桶内排队等待。有利于应对突发请求
五、漏铜算法是用来优化令牌桶算法的，漏铜算法的桶里面放的是请求

Sentinel在实现漏桶时，采用了排队等待模式：让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。并发的多个请求必须等待，预期的等待时长 =最近一次请求的预期等待时间 + 允许的间隔。如果请求预期的等待时间超出最大时长，则会被拒绝。例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待超过2000ms的请求会被拒绝并抛出异常。如下图

3. 限流算法的对比

注意: 固定窗口并没有在内

	滑动时间窗口	令牌桶	漏桶
能否保证流量曲线平滑	不能，但窗口内区间越小，流量控制越平滑	基本能，在请求量持续高于令牌生成速度时，流量平滑。但请求量在令牌生成速率上下波动时，无法保证曲线平滑	能，所有请求进入桶内，以恒定速率放行，绝对平滑
能否应对突增流量	不能，徒增流量，只要高出限流阈值都会被拒绝	能，桶内积累的令牌可以应对突增流量	能，请求可以暂存在桶内
流量控制精确度	低，窗口区间越小，精度越高	高	高