面试题个人汇总

2023-07-20 06:30| 来源: 网络整理| 查看: 265

1. 什么是服务雪崩？什么是服务限流？服务雪崩：服务A调用服务B，服务B调用服务C，当大量请求突然请求服务A（服务A本身可以抗住这些请求），但是服务C存在请求堆积，从而会使服务B请求堆积，从而服务A不可用。服务限流：在高并发情况下为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统不被大量请求压垮。 2. 什么是服务降级、什么是熔断服务降级：解决系统资源不足和海量业务请求之间的矛盾。在暴增的流量请求下，对一些非核心业务、非关键业务进行有选择性的放弃，一次来释放系统资源，保证核心业务的正常运行。服务降级不是一个常态策略，而是应对非正常情况下的应急策略。服务降级的结果，通常是对一些业务请求返回一个统一的结果，可以理解是一种快速失败FailOver的策略。一般通过配置中心配置开关实现开启降级。服务熔断：保护的是业务系统不被外部大流量或者下游系统的异常而拖垮。如果开启了熔断，订单服务可以在下游调用出现部分异常时，调节流量请求，比如在出现了10%的失败后，减少50%的流量请求，如果继续出现50%的异常，则减少80%的流量请求。在检测到下游服务正常后，先恢复30%的流量，然后恢复50%的流量，接下来是全部流量。 3. springcloud核心组件及其作用

Eureka ：服务注册与发现

注册：每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址，端口号，版本号，通信协议等。Eureka将每个服务维护在一个服务清单中（双层map，第一层key是服务名，第二层key是服务名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用的服务，Eureka集群各节点相互注册，每个实例中都有一样的服务清单。

发现： Eureka注册的服务之间调用不需要指定服务地址，而是通过服务名想注册中心咨询，并获取所有服务实例清单（缓存到本地），然后实现服务的请求访问。

Ribbon ：

服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台（被调用方的服务地址有多个），Ribbon也是通过http发起请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然Ribbon不用去具体请求服务实例的ip地址或者域名，但是每调用一个接口都还要手动发起http请求。

Feign ：

基于Feign的动态代理机制，根据注解和选择的机器，拼接请求url地址，发起请求，简化服务间的调用，在Ribbon的基础上进行了进一步的封装。单独抽取成一个组件，即是Spring Cloud Feign。在引入Spring Cloud Feign后，只需要创建一个接口并用注解的方式来配置它，即可完成服务提供方的接口绑定。

Hystrix ：

发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现不同服务调用的隔离，通过统计接口超时次数返回默认值，实现服务熔断和降级。

Zuul ：

如果前端，移动端需要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务。通过与Eureka整合，将自身注册为Eureka下的应用，从Eureka下获取所有服务的实例，来进行服务的路由。Zuul还提供了一套关于过滤器机制，开发者可以自己指定那些规则的请求需要进行校验逻辑，只有通过校验逻辑的请求才会被路由到具体服务实例上，否则返回错误提示。

4. 什么是Hystrix？简述实现机制

分布式容错框架

阻止故障的连锁反应，实现熔断。快速失败，实现优雅降级。提供实时的监控和告警。

资源隔离：

线程隔离： Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其它线程池造成影响。信号量隔离：客户端需要依赖服务发起请求是，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限制和防止服务雪崩的目的。

Hystrix流程：

通过HystrixCommand或者HystrixObservableCommand将所有的外部系统（或者依赖）包装起来，整个包装对象是单独运行在一个线程池之中（命令模式）超时请求应该超过开发者定义的阈值为每个依赖关系维护一个小的线程池（或信号量），如果它变满了，那么依赖关系的请求将被立即拒绝，而不是排队等待统计成功，失败（有客户端抛出的异常），超时和线程拒绝打开断路器可以在一段时间内停止对特定服务的所有请求，入股服务的错误百分比达到阈值，手动或自动的关闭断路器当请求被拒绝，连接超时或者断路器打开，直接执行fallback逻辑近乎实时监控指标和配置变化 5. 高并发场景下如何实现系统限流

限流一般需要结合容量规划和压测来进行，当外部请求接近或者达到系统的最大阈值时，触发限流，采取其他的手段来进行降级，保护系统不被压垮。常见的降级策略包括延迟处理，拒绝服务，随即拒绝等。

计数器法：

将时间划分为固定的窗口大小，例如1s在窗口时间段内，每来一个请求，对计数器加1当计数器达到设定限制后，该窗口时间内的之后的请求都被丢弃处理该窗口时间结束后，计数器清零，从新开始计数

滑动窗口计数法：

将时间划分为细粒度的区间，每个区间维持一个计数器，每进入一个请求则计数器加1多个区间组成一个时间窗口，每流逝一个区间时间后，则抛弃最老的一个区间，纳入新区间若当前窗口的区间计数器总和超过设定的限制数量，则本窗口内的后续请求都被丢弃

漏桶算法：如果外部请求超出当前阈值，则会在容器里积蓄，一直到溢出，系统不关注溢出的流量。从出口处限制请求速率，并不存在计数器法的临界问题，请求曲线始终是平滑的。无法应对突发流量，相当于一个空桶加固定处理线程。

令牌桶算法：假设一个大小恒定的桶，这个桶的容量和设定的阈值有关，桶里放着很多令牌，通过一个固定的速率往里边放入令牌，如果桶满了，就把令牌丢掉，最后桶里可以保存的最大令牌数永不超过桶的大小。当有请求进入时，就尝试从桶里取走一个令牌，如果桶里是空的，那么这个请求就会被拒绝。

6. SOA、分布式、微服务之间有什么关系和区别？分布式：分布式架构是指将单体架构的各个部分拆分，然后部署不同的机器或者进程中去，SOA和微服务基本上都是分布式架构SOA ：一种面向服务的架构，系统上的所有服务都注册在总线上，当调用服务时，从总线上查找服务信息，然后调用微服务：一种更彻底的面向服务的架构，将系统各个功能个体抽成一个个小的应用程序，基本保持一个应用对应一个服务的架构 7. 雪花算法原理

在这里插入图片描述第一位固定为0，41位时间戳，10位workId，12位系列号，位数可以有不同实现。

优点：

每个毫秒值包含的id值很多，不够可以变动位数来增加，性能好（依赖于workId的实现）时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个id是趋势递增的能够根据业务昌吉数据库节点布置灵活调整bit位划分，灵活度高

缺点：

强依赖于机器时钟，如果时钟回拨，会导致重复的id生成，所以一般基于此的算法发现时钟回拨，都会触发异常，阻止id生成，可能会导致服务不可用。 8. 为什么Zookeeper可以用来作为注册中心

可以利用Zookeeper的临时节点和watch机制来实现注册中心的自动注册和发现，另外Zookeeper中的数据都是存在内存的，并且Zookeeper底层采用了NIO，多线程模型，所以Zookeeper的性能也是比较高的，所以可以用来作为注册中心，但是如果考虑到注册中心的可用性的话，Zookeeper则不适合，因为Zookeeper是侧重CP的，注重的是一致性，所以集群数据不一致时，集群将不可用，所以用redis，eureka，nacos来作为注册中心将更合适。

9. 数据库实现分布式锁的问题及解决方案

利用唯一约束键存储key，insert成功则代表获取锁成功，失败则获取失败，操作完成需要删除锁。

问题：

非阻塞。锁获取失败后没有排队机制，需要自己编码实现阻塞，可以使用自旋，操作完成需要删除锁不可重入。如果加锁的方法需要递归，则第二次插入会失败，可以使用记录线程标识解决重入问题死锁。删除锁失败，则其他线程没有本法获取锁，可以设置超时时间，使用定时任务检查数据库单点故障。数据库高可用 10. 数据一致性模型有哪些强一致性：当更新操作完成后，任何多个后续进程的访问都会返回最新的更新过的值，这种是对用户体验最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据CAP理论，这种实现需要牺牲可用性。弱一致性：系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会据图承诺多久之后可以读到。用户读到某一操作对系统的更新需要一段时间，即不一致性窗口。最终一致性：弱一致性的特例，强调的是所有的数据副本，在经过一段时间同步之后，最终都能够达到一个一致的状态，因此，最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。到达最终一致性的时间，就是不一致窗口时间，在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

最终一致性模型根据器提供的不同保证可以划分为更多的模型，包括因果一致性和会话一致性。

因果一致性：要求有因果关系的操作顺序得到保证，非因果关系的操作顺序则无所谓。

会话一致性：将对系统数据的访问过程框定在了一个会话当中，约定了系统能够保证在同一个有效的会话中实现“读己之所写”的一致性，就是在一次访问中，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据的最新值。实际开发中有分布式的session一致性问题，可以认为是会话一致性的一个应用。

11. 什么是分布式事务？有哪些实现方案？本地消息表：创建订单时，将减库存消息加入在本地事务中，一起提交到数据库存入本地消息表，然后调用库存系统，如果调用成功则修改本地消息状态为成功，如果调用库存系统失败，则由后台定时任务从本地消息表中取出未成功的消息，重试调用库存系统。消息队列：目前RocketMQ支持事务消息，工作原理： 1. 生产者订单系统先发送一条half消息到Broker，half消息对消费者而言是不可见的 2. 再创建订单，根据创建订单成功与否，想Broker发送commit或者rollback 3. 并且生产者订单系统还可以提供Broker回调接口，当Broker发现一段时间half消息没有收到任何操作命令，则会主动调此接口来查询订单是否创建成功 4. 一旦half消息commit了，消费者库存系统就会来消费，如果消费成功，则消息销毁，分布式事务结束 5. 如果消费失败，则根据重试策略进行重试，最后还失败则进入死信队列，等待进一步处理Seata：阿里开源分布式事务框架，支持AT,TCC等多种模式，底层都是基于两阶段提交来实现的 12. 什么是ZAB协议

ZAB协议是Zookeeper用来实现一致性的原子广播协议，该协议描述了Zookeeper是如何实现一致性的，分为三个阶段：

领导者选举阶段：从Zookeeper集群中选出一个节点作为Leader，所有的写请求都会有Leader节点来处理数据同步阶段：集群中所有节点的数据要和Leader节点保持一致，如果不一致则要进行同步请求广播阶段：当Leader节点接收到写请求时，会利用两阶段提交来广播该写请求，使得该写请求像事务一样在其他节点上执行，达到节点上的数据实时一致

注意：Zookeeper只是尽量在达到强一致性，实际依然是最终一致

13. 什么是RPC

RPC，表示远程过程调用，对于java这种面向对象语言，也可以理解成远程方法调用，RPC调用和HTTP调用是有区别的，RPC表示的是一种调用远程方法的方式，可以使用HTTP协议，或者直接基于TCP协议来实现RPC。在java中，我们可以通过直接使用某个服务接口的代理对象来执行方法，而底层则通过构造HTTP请求来调用远程的方法，所以，有一种说法是RPC协议是http协议之上的一种协议。

14. 如何实现接口幂等性唯一id，每次操作，都根据操作和内容生成唯一id，在执行之前先判断id是否已经存在，如果不存在则执行后续操作，并且保存到数据库或者redis等服务端提供发送token的接口，业务调用接口前先获取token，然后调用业务接口请求时，把token携带过去，服务器判断token是否已经存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis的token删除建去重表，增加版本号，当版本号符合时，才能更新数据状态控制，例如订单有状态，已支付，未支付，支付失败等，当处于未支付的时候才允许修改为支付成功 15. 什么是BASE理论

由于不能同时满足CAP，所以出现了BASE理论

BA：Basically Available，表示基本可用，表示可以允许一定程度上的不可用，比如系统故障，请求时间变长，或者由于系统故障导致部分非核心功能不可用，都是允许的S：Soft state：表示分布式系统可以处于一种中间状态，比如数据正在同步E：Eventually consistent，表示最终一致性，不要求分布式系统数据实时达到一致，允许在经过一段时间后再达到一致，在达到一致的过程中，系统也是可用的 16. Dubbo的工作流程

在这里插入图片描述

start：启动spring容器时，自动启动dubbo的providerregister：dubbo的provider在启动后会去注册中心注册内容，注册的内容包括：ip，端口，接口列表（接口类，方法），版本，provider的协议subscribe：订阅，当consumer启动时，自动去registry获取到所已注册的服务的信息notify：通知，当provider的信息发生变化时，自动有registry想consumer推送通知invoke：consumer调用provider中方法（同步请求，消耗一定性能，但是必须是同步请求，因为需要介绍调用方法后的结果）count：每隔2分钟，provider和consumer自动向monitor发生访问次数，monitor进行统计 17. Redis的分布式锁的实现

Redis分布式锁

【本文地址】

面试题个人汇总

面试题个人汇总

今日新闻

推荐新闻