gatway限流和sentinel限流有什么区别?
-
gatway: gatway采用的是基于redis的令牌桶算法(由服务端决定生成token的速度,然后请求从令牌桶中获取token,生成token的速度会慢慢递增防止请求一下增大打死服务器)
-
sentinel: 默认限流是滑动窗口算法,排队等待是漏桶算法,热点参数限流是令牌桶算法。
linux的常用命令和docker的常用命令?
linux:
- tail -f server.log 查看日志
- tail -f log_file | grep ‘xxxxxx’ 查看包含特定内容的日志
- ls-查看目录
- mkdir创建目录
- rm 删除(rm -rf递归删除)
- mv移动
- cp拷贝
- pwd查看当前目录
- vim编辑
- cat 查看
- tar -zxvf 解压
- ifconfig查看网络
- ps -ef 查看进程
- lsof -i查看端口
dokcer: - docker stats 查看cpu占用率
- docker images查看镜像
- docker pull拉取镜像
- docker rmi删除镜像
- docker run运行镜像
- docker ps显示当前运行的容器
- docker stop 停止容器
- docker kill强制停止
openfeign怎么进行远程调用的?
通过发送http请求进行通信(调用接口中定义的方法,OpenFeign 会根据方法的注解信息生成对应的 HTTP 请求。)
openfeign相当于nacosclient+rabbin+http请求
seate的事务参与者和事务协调者之间通信?
通过netty框架进行通信;
nginx是服务端负载均衡,rabbin是客户端负载均衡
什么是微服务,什么是分布式?
微服务:每个模块都是一个单独的服务,需要单独部署,运行在一个单独的容器中,每个服务都需要统一管理。每个服务都可以连接自己的数据库,使用不同的语言开发,服务和服务之间使用轻量级的通讯框架进行通讯。
分布式:是指将一个系统或应用程序分布在多个计算机或服务器上,并通过网络进行通信和协调;
通常微服务架构会采用分布式的方式实现,每个微服务可以独立地部署在不同的服务器上,它们之间通过网络进行通信,共同构成了一个分布式系统。分布式系统的核心思想是将系统分解为多个独立的组件,每个组件负责处理特定的功能,并通过网络进行通信,从而实现整个系统的协作工作。
分布式事务seata的模式有哪些,它的执行原理?
seata有AT,TCC,SAGA,XA四种事务模式;
执行流程:TM(事务的发起者)先向TC(事务协调者)注册一个xid(全局事务 ID),并返回,TM在调用RM(事务参与者)的时候,把xid在服务链路中
传递,到RM后先向TC注册一个事务分支,这个分支在xid下,RM执行本地事务,做一个反向操作在undo_log表中,并告诉给TC,TC收到所有结果再给RM发送提交操作,如果都成功则删除undo_log表中的记录,如果有一个失败,则给所有RM发送回滚消息,执行反向操作。
在分布式事务中,有些异常想回滚,有些异常不想回滚,要如何处理?
1,在 @GlobalTransactional 注解中,有一个 rollbackFor 参数,用于指定需要回滚的异常类型。你可以在这个参数中列出你希望回滚的异常类型,其他异常不会触发回滚。
gateway的工作原理?
gateway作为流量的统一入口,所有请求都会打到gateway,gateway进行解析和验证,根据所配置的断言规则,发送到不同的后端服务。
gateway是如何配合redis工作的,是怎么衔接工作的?
1,缓存,可以做缓存技术,将经常请求的数据缓存到redis中,避免每次请求直接后端服务,当接收到客户端请求时,Gateway 先检查 Redis 缓存中是否存在请求所需的数据,如果存在则直接返回给客户端,不再访问后端服务;如果不存在,则从后端服务获取数据,并将数据存储到 Redis 缓存中,然后再返回给客户端。
2,会话管理:Gateway 可以使用 Redis 作为会话存储,将用户的会话信息存储在 Redis 中。当用户发送请求时,Gateway 可以通过读取 Redis 中的会话信息来验证用户身份、权限等信息,而不需要每次都去查询数据库或调用其他服务进行验证。
微服务5大组件有哪些?
注册中心/配置中心 Nacos(阿里巴巴)
负载均衡 Ribbon
服务调用 Feign
服务保护(熔断降级) sentinel(阿里巴巴)
服务网关 Gateway
服务注册和发现是什么意思?Spring Cloud 如何实现服务注册发现?
我们当时项目采用的nacos作为注册中心,这个也是spring cloud体系中的一个核心组件
服务注册:服务提供者需要把自己的信息注册到nacos,由nacos来保存这些信息,比如服务名称、ip、端口等等
服务发现:消费者向nacos拉取服务列表信息,如果服务提供者有集群,则消费者会利用负载均衡算法,选择一个发起调用。
nacos与eureka的区别?
共同点
Nacos与eureka都支持服务注册和服务拉取,都支持服务提供者心跳方式做健康检测
区别
①Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除,非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
④Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式
Nacos集群后数据是如何做同步的?
Nacos集群有角色之分,分为Leader、Flollower角色,leader负责写然后广播给所有flollower,flollower负责读,底层是reft算法。
Nacos是如何完成选举的?
Leader会给Flollower发送心跳,每个节点自身都有超时时间,在这个超时时间内没有收到Leader的心跳,该节点就会变为候选者,然后它会发送投票信息给其他的节点,票数过多的成为Leader。
项目负载均衡如何实现的 ?
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单。
当发起远程调用时,ribbon先从注册中心拉取服务地址列表,然后按照一定的路由策略选择一个发起远程调用,一般的调用策略是轮询。
Ribbon负载均衡策略有哪些 ?
RoundRobinRule:简单轮询服务列表来选择服务器。
WeightedResponseTimeRule:按照权重来选择服务器,响应时间越长,权重越小。
RandomRule:随机选择一个可用的服务器。
ZoneAvoidanceRule:区域敏感策略,以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类,这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)。
如果想自定义负载均衡策略如何实现 ?
提供了两种方式:
1,创建类实现IRule接口,可以指定负载均衡策略,这个是全局的,对所有的远程调用都起作用。
2,在客户端的配置文件中,可以配置某一个服务调用的负载均衡策略,只是对配置的这个服务生效远程调用。
feign调用需不需要经过网关?
不需要,因为网关是对外的服务,外部发送的请求才会走网关,feign是服务和服务之间的调用;
feign实现原理?
1,给feign接口创建一个动态代理,这个代理使用JDk动态代理;
2,在服务中使用的时候注入的代理对象;
什么是服务雪崩,怎么解决这个问题?
服务雪崩是指一个服务失败,导致整条链路的服务都失败的情形,一般我们在项目解决的话就是两种方案,第一个是服务降级,第二个是服务熔断,如果流量太大的话,可以考虑限流
服务降级:服务自我保护的一种方式,或者保护下游服务的一种方式,用于确保服务不会受请求突增影响变得不可用,确保服务不会崩溃,一般在实际开发中与feign接口整合,编写降级逻辑,调用本地降级方法,返回一个兜底数据。
服务熔断:熔断器机制(关闭,打开,半开),默认情况下熔断器是关闭的状态,满足条件(出现故障的率,超时时间)熔断器会启动打开,熔断器打开后会所有的请求过来后直接调用本地降级返回拿到兜底数据返回(注意这里不在进行远程调用了)提供了响应时间,每过一段时间熔断器会进入半开状态,这种状态下会放一部分请求过去,测试下服务是否正常。如果还是出现故障熔断器继续进入全开状态,如果服务正常熔断器关闭。
你们的微服务是怎么监控的?
我们项目中采用的skywalking进行监控的
1,skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢,我们可以针对性的分析和优化。
2,我们还在skywalking设置了告警规则,特别是在项目上线以后,如果报错,我们分别设置了可以给相关负责人发短信和发邮件,第一时间知道项目的bug情况,第一时间修复。
你们项目中有没有做过限流 ? 怎么做的 ?
我当时做的xx项目,采用就是微服务的架构,因为xx因为,应该会有突发流量,最大QPS可以达到2000,但是服务支撑不住,我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100,为了解决这些突发流量,所以采用了限流。
【版本1】
我们当时采用的nginx限流操作,nginx使用的漏桶算法来实现过滤,让请求以固定的速率处理请求,可以应对突发流量,我们控制的速率是按照ip进行限流,限制的流量是每秒20。
【版本2】
我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流,使用的是令牌桶算法,可以根据ip或路径进行限流,可以设置每秒填充平均速率,和令牌桶总容量。
限流常见的算法有哪些呢?
比较常见的限流算法有漏桶算法和令牌桶算法
漏桶算法是把请求存入到桶中,以固定速率从桶中流出,可以让我们的服务做到绝对的平均,起到很好的限流效果。
令牌桶算法在桶中存储的是令牌,按照一定的速率生成令牌,每个请求都要先申请令牌,申请到令牌以后才能正常请求,也可以起到很好的限流作用。
它们的区别是,漏桶和令牌桶都可以处理突发流量,其中漏桶可以做到绝对的平滑,令牌桶有可能会产生突发大量请求的情况,一般nginx限流采用的漏桶,spring cloud gateway中可以支持令牌桶算法。
什么是CAP理论?
CAP主要是在分布式项目下的一个理论。包含了三项,一致性、可用性、分区容错性。
一致性(Consistency)是指更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致(强一致性),不能存在中间状态。
可用性(Availability) 是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。
为什么分布式系统中无法同时保证一致性和可用性?
首先一个前提,对于分布式系统而言,分区容错性是一个最基本的要求,因此基本上我们在设计分布式系统的时候只能从一致性(C)和可用性(A)之间进行取舍。
如果保证了一致性(C):对于节点A和B,当往A里写数据时,B上的操作必须被暂停,只有当A同步数据到B时才能对B进行读写请求,在B被暂停操作期间客户端提交的请求会收到失败或超时。显然,这与可用性是相悖的。
如果保证了可用性(A):A在写的同时,B在读这样就会造成数据不一致,这就违背了一致性的要求。
什么是BASE理论?
BASE是CAP理论中AP方案的延伸,核心思想是即使无法做到强一致性(CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。它的思想包含三方面:
1、Basically Available(基本可用):基本可用是指分布式系统在出现不可预知的故障的时候,允许损失部分可用性,但不等于系统不可用。
2、Soft state(软状态):即是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent(最终一致性):强调系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
Redission如何实现分布式锁?
在分布式的情况下本地锁会失效,本地锁只能锁本地的服务器,所以需要分布式来管理;
利用redis的setnx命令和lua脚本实现。
你们采用哪种分布式事务解决方案?
我们当时是xx项目,主要使用到的seata的at模式解决的分布式事务
seata的AT模型分为两个阶段:
1、阶段一RM的工作:① 注册分支事务 ② 记录undo-log(数据快照)③ 执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作:删除undo-log即可
3、阶段二回滚时RM的工作:根据undo-log恢复数据到更新前
at模式牺牲了一致性,保证了可用性,不过,它保证的是最终一致性
分布式服务的接口幂等性如何设计?
我们当时有一个xx项目的下单操作,采用的token+redis实现的,流程是这样的
第一次请求,也就是用户打开了商品详情页面,我们会发起一个请求,在后台生成一个唯一token存入redis,key就是用户的id,value就是这个token,同时把这个token返回前端。
第二次请求,当用户点击了下单操作会后,会携带之前的token,后台先到redis进行验证,如果存在token,可以执行业务,同时删除token;如果不存在,则直接返回,不处理业务,就保证了同一个token只处理一次业务,就保证了幂等性。
xxl-job路由策略有哪些?
xxl-job提供了很多的路由策略,我们平时用的较多就是:轮询、故障转移、分片广播…
xxl-job任务执行失败怎么解决?
有这么几个操作
第一:路由策略选择故障转移,优先使用健康的实例来执行任务
第二,如果还有失败的,我们在创建任务时,可以设置重试次数
第三,如果还有失败的,就可以查看日志或者配置邮件告警来通知相关负责人解决
如果有大数据量的任务同时都需要执行,怎么解决?
我们会让部署多个实例,共同去执行这些批量的任务,其中任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片,按照取模的方式分摊到各个实例执行就可以了。文章来源:https://www.toymoban.com/news/detail-855835.html
后记
👉👉💕💕美好的一天,到此结束,下次继续努力!欲知后续,请看下回分解,写作不易,感谢大家的支持!! 🌹🌹🌹文章来源地址https://www.toymoban.com/news/detail-855835.html
到了这里,关于JAVA面试八股文之微服务相关的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!