微服务（学习）

1.Spring Cloud 5大组件有哪些？
一般认为的Spring Cloud五大组件是 
Eureka / nacos : 注册中心
Ribbon  : 负载均衡
Feign     : 远程调用
Hystrix :  服务熔断
Zuul/Gateway  : 网关
2.服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？
我理解的是主要三块大功能，分别是服务注册 、服务发现、服务状态监控
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
3.nacos与eureka的区别？
选择nacos还要一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：
共同点:Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式；Eureka的心跳是30秒一次，Nacos则是5秒一次
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除；Eureka如果90秒未收到心跳，则认为服务疑似故障，可能被剔除。Nacos中则是15秒超时，30秒剔除。
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时；Eureka每隔60秒执行一次服务检测和清理任务；Nacos是每隔5秒执行一次。Eureka只能等微服务自己每隔30秒更新一次服务列表；Nacos即有定时更新，也有在服务变更时的广播推送
④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式⑤Eureka仅有注册中心功能，而Nacos同时支持注册中心、配置管理
4.项目负载均衡如何实现的 ? 
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现  , Feign的底层已经自动集成了Ribbon  , 使用起来非常简单。当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询
Ribbon负载均衡策略
RoundRobinRule：简单轮询服务列表来选择服务器
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
RandomRule：随机选择一个可用的服务器
ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)

5.如果想自定义负载均衡策略如何实现 ? 
提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用

6.什么是服务雪崩，怎么解决这个问题？
服务雪崩是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如果流量太大的话，可以考虑限流
服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑。
服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求

7.你们项目中有没有做过限流 ? 怎么做的 ?

采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20

采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法，可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量

比较常见的限流算法有漏桶算法和令牌桶算法
漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果

令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用

它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法

8.什么是CAP理论？
CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性
一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
9.为什么分布式系统中无法同时保证一致性和可用性？
首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。
如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。
如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。
10.什么是BASE理论？
BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：
1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
你们采用哪种分布式事务解决方案？
seata的at模式解决的分布式事务
seata的AT模型分为两个阶段：
1、阶段一RM的工作：① 注册分支事务  ② 记录undo-log（数据快照）③ 执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作：删除undo-log即可
3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前
at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性
分布式服务的接口幂等性如何设计？
项目的下单操作，采用的token+redis实现的，流程是这样的
第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端
第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性
xxl-job路由策略有哪些？
xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播…
xxl-job任务执行失败怎么解决？
有这么几个操作
第一：路由策略选择故障转移，优先使用健康的实例来执行任务
第二，如果还有失败的，我们在创建任务时，可以设置重试次数
第三，如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决
如果有大数据量的任务同时都需要执行，怎么解决？
我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了

面试题1：
Eureka和Zookeeper注册中心的区别	Zookeeper是保证CP   当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
	Eureka是保证AP Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况： 1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用) 3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中 因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
面试题2
令牌桶算法
	说明： - 以固定的速率生成令牌，存入令牌桶中，如果令牌桶满了以后，多余令牌丢弃 - 请求进入后，必须先尝试从桶中获取令牌，获取到令牌后才可以被处理 - 如果令牌桶中没有令牌，则请求等待或丢弃
	基于令牌桶算法，每秒产生的令牌数量基本就是QPS上限。 当然也有例外情况，例如： - 某一秒令牌桶中产生了很多令牌，达到令牌桶上限N，缓存在令牌桶中，但是这一秒没有请求进入。 - 下一秒的前半秒涌入了超过2N个请求，之前缓存的令牌桶的令牌耗尽，同时这一秒又生成了N个令牌，于是总共放行了2N个请求。超出了我们设定的QPS阈值。 因此，在使用令牌桶算法时，尽量不要将令牌上限设定到服务能承受的QPS上限。而是预留一定的波动空间，这样我们才能应对突发流量。
漏桶算法	漏桶算法与令牌桶相似，但在设计上更适合应对并发波动较大的场景，以解决令牌桶中的问题。
	简单来说就是请求到达后不是直接处理，而是先放入一个队列。而后以固定的速率从队列中取出并处理请求。之所以叫漏桶算法，就是把请求看做水，队列看做是一个漏了的桶。
	说明： 将每个请求视作"水滴"放入"漏桶"进行存储； "漏桶"以固定速率向外"漏"出请求来执行，如果"漏桶"空了则停止"漏水”； 如果"漏桶"满了则多余的"水滴"会被直接丢弃。
	漏桶的优势就是流量整型，桶就像是一个大坝，请求就是水。并发量不断波动，就如图水流时大时小，但都会被大坝拦住。而后大坝按照固定的速度放水，避免下游被洪水淹没。
面试3
Dubbo 协议（RPC）相比RESTful 协议速度更快
结论	RPC基于TCP连接在性能上通常优于基于HTTP的RPC实现，原因在于： 更小的协议开销 更高效的连接管理 更直接的数据传输方式 更多的性能优化空间 更低的实时性延迟
补充	TCP和HTTP区别 HTTP和TCP分别属于不同的网络层次，服务于不同的目的。HTTP是一个应用层协议，用于传输网页数据和资源；TCP是一个传输层协议，提供可靠的数据传输服务。HTTP在实际应用中依赖于TCP协议来实现数据的可靠传输。理解两者的区别和联系，有助于更好地设计和优化网络应用。