我对spring springcloud的简单理解

总长大人好

已于 2022-08-29 17:24:18 修改

阅读量313

点赞数

CC 4.0 BY-SA版权

文章标签： java 面试 spring

于 2022-08-28 20:22:30 首次发布

本文链接：https://blog.csdn.net/zcg13767706322/article/details/126197110

1.说说你对Spring IOC的理解?

1）IOC就是控制反转，是指创建对象的控制权的转移，以前创建对象的主动权和时机是由自己把控的，而现在这种权力转移到Spring容器中，并由容器根据配置文件去创建实例和管理各个实例之间的依赖关系，对象与对象之间松散耦合，也利于功能的复用。DI依赖注入，和控

制反转是同一个概念的不同角度的描述，即应用程序在运行时依赖IoC容器来动态注入对象需要的外部资源。

（2）最直观的表达就是，IOC让对象的创建不用去new了，可以由spring自动生产，使用java的反射机制，根据配置文件在运行时动态的去创建对象以及管理对象，并调用对象的方法的。

（3）Spring的IOC有三种注入方式：构造器注入、setter方法注入、根据注解注入。

IoC让相互协作的组件保持松散的耦合，而AOP编程允许你把遍布于应用各层的功能分离出来形成可重用的功能组件

总体来说，构造方法注入和setter方法注入因为其侵入性较弱，且易于理解和使用，所以是现在使用最多的注入方式。而接口注入因为侵入性较强，近年来已经不流行了。

@ComponentScan用于声明扫描策略，通过它的声明，容器就知道要扫描哪些包下带有声明的类，也可以知道哪些特定的类是被排除在外的。
@Component、@Repository、@Service、@Controller用于声明Bean，它们的作用一样，但是语义不同。@Component用于声明通用的Bean，@Repository用于声明DAO层的Bean，@Service用于声明业务层的Bean，@Controller用于声明视图层的控制器Bean，被这些注解声明的类就可以被容器扫描并创建。
@Autowired、@Qualifier用于注入Bean，即告诉容器应该为当前属性注入哪个Bean。其中，@Autowired是按照Bean的类型进行匹配的，如果这个属性的类型具有多个Bean，就可以通过@Qualifier指定Bean的名称，以消除歧义。
@Scope用于声明Bean的作用域，默认情况下Bean是单例的，即在整个容器中这个类型只有一个实例。可以通过@Scope注解指定prototype值将其声明为多例的，也可以将Bean声明为session级作用域、request级作用域等等，但最常用的还是默认的单例模式。
@PostConstruct、@PreDestroy用于声明Bean的生命周期。其中，被@PostConstruct修饰的方法将在Bean实例化后被调用，@PreDestroy修饰的方法将在容器销毁前被调用。

spring bean 容器的生命周期流程如下：

1、Spring 容器根据配置中的 bean 定义中实例化 bean。

2、Spring 使用依赖注入填充所有属性，如 bean 中所定义的配置。

3、如果 bean 实现BeanNameAware 接口，则工厂通过传递 bean 的 ID 来调用setBeanName()。

4、如果 bean 实现 BeanFactoryAware 接口，工厂通过传递自身的实例来调用setBeanFactory()。

5、如果存在与 bean 关联的任何BeanPostProcessors，则调用 preProcessBeforeInitialization() 方法。

6、如果为 bean 指定了 init 方法（的 init-method 属性），那么将调用它。

7、最后，如果存在与 bean 关联的任何 BeanPostProcessors，则将调用postProcessAfterInitialization() 方法。

8、如果 bean 实现 DisposableBean 接口，当 spring 容器关闭时，会调用 destory()。

9、如果为bean 指定了 destroy 方法（的 destroy-method 属性），那么将调用它。

2.说说你对spring AOP的理解

OOP面向对象，允许开发者定义纵向的关系，但并适用于定义横向的关系，导致了大量代码的重复，而不利于各个模块的重用。 AOP，一般称为面向切面，作为面向对象的一种补充，用于将那些与业务无关，但却对多个对象产生影响的公共行为和逻辑，抽取并封装为一个可重用的模块，这个模块被命名为“切面”（Aspect），减少系统中的重复代码，降低了模块间的耦合度，同时提高了系统的可维护性。可用于权限认证、日志、事务处理。AOP实现的关键在于代理模式，AOP代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；动态代理则以Spring AOP为代表。

（1）AspectJ是静态代理的增强，所谓静态代理，就是AOP框架会在编译阶段生成AOP代理类，因此也称为编译时增强，他会在编译阶段将

AspectJ(切面)织入到Java字节码中，运行的时候就是增强之后的AOP对象。

（2）Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是每次运行时在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。

Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理：

①JDK动态代理只提供接口的代理，不支持类的代理。核心InvocationHandler接口和Proxy类，InvocationHandler 通过invoke()方法反射

来调用目标类中的代码，动态地将横切逻辑和业务编织在一起；接着，Proxy利用 InvocationHandler动态创建一个符合某一接口的的实例,

生成目标类的代理对象。

②如果代理类没有实现 InvocationHandler 接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB（Code Generation

Library），是一个代码生成的类库，可以在运行时动态的生成指定类的一个子类对象，并覆盖其中特定方法并添加增强代码，从而实现AOP。CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为fifinal，那么它是无法使用CGLIB做动态代理的

3）静态代理与动态代理区别在于生成AOP代理对象的时机不同，相对来说AspectJ的静态代理方式具有更好的性能，但是AspectJ需要特定的编译器进行处理，而Spring AOP则无需特定的编译器处理。

AOP的术语：

连接点（join point）：对应的是具体被拦截的对象，因为Spring只能支持方法，所以被拦截的对象往往就是指特定的方法，AOP将通过动态代理技术把它织入对应的流程中。
切点（point cut）：有时候，我们的切面不单单应用于单个方法，也可能是多个类的不同方法，这时，可以通过正则式和指示器的规则去定义，从而适配连接点。切点就是提供这样一个功能的概念。
通知（advice）：就是按照约定的流程下的方法，分为前置通知、后置通知、环绕通知、事后返回通知和异常通知，它会根据约定织入流程中。
目标对象（target）：即被代理对象。
引入（introduction）：是指引入新的类和其方法，增强现有Bean的功能。
织入（weaving）：它是一个通过动态代理技术，为原有服务对象生成代理对象，然后将与切点定义匹配的连接点拦截，并按约定将各类通知织入约定流程的过程。
切面（aspect）：是一个可以定义切点、各类通知和引入的内容，SpringAOP将通过它的信息来增强Bean的功能或者将对应的方法织入流程。

3.怎么保证MQ中的消息不会丢失?

其中的每一步都可能导致消息丢失，常见的丢失原因包括：

发送时丢失：
- 生产者发送的消息未送达exchange
- 消息到达exchange后未到达queue
MQ宕机，queue将消息丢失
consumer接收到消息后未消费就宕机

针对这些问题，RabbitMQ分别给出了解决方案：

1.生产者确认机制

RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。这种机制必须给每个消息指定一个唯一ID。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。

返回结果有两种方式：

publisher-confirm，发送者确认
- 消息成功投递到交换机，返回ack
- 消息未投递到交换机，返回nack
publisher-return，发送者回执
- 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因

2. mq持久化

生产者确认可以确保消息投递到RabbitMQ的队列中，但是消息发送到RabbitMQ以后，如果突然宕机，也可能导致消息丢失。

要想确保消息在RabbitMQ中安全保存，必须开启消息持久化机制。

交换机持久化

事实上，默认情况下，由SpringAMQP声明的交换机都是持久化的。

队列持久化

RabbitMQ中队列默认(原生)是非持久化的，mq重启后就丢失。

SpringAMQP中可以通过代码指定交换机持久化：

事实上，默认情况下，由SpringAMQP声明的队列都是持久化的。

消息持久化

默认情况下，SpringAMQP发出的任何消息都是持久化的，不用特意指定。

交换机与队列都不能是自动删除

3.消费者确认机制

none模式下，消息投递是不可靠的，可能丢失
auto模式类似事务机制，出现异常时返回nack，消息回滚到mq；没有异常，返回ack
manual：自己根据业务情况，判断什么时候该ack

一般，我们都是使用默认的auto即可

4.失败重试机制

开启本地重试时，消息处理过程中抛出异常，不会requeue到队列，而是在消费者本地重试
重试达到最大次数后，Spring会返回ack，消息会被丢弃

开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理

4.什么是消息堆积？有哪些后果？怎么解决？-

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

会导致大量的消息丢失问题而且还会导致消息堆积过多影响消息的消费导致后续的消息不能及时消费大量的进入死信队列

解决消息堆积有两种思路：

增加更多消费者，提高消费速度。也就是我们之前说的work queue模式
扩大队列容积，提高堆积上限

要提升队列容积，把消息保存在内存中显然是不行的。

队列过长的话会占用系统较多内存，RabbitMQ为了释放内存，会将队列消息转储到硬盘，称为 page out 。如果队列很长，Page out 操作会消耗较长时间，且page out 过程中队列不能处理消息。因此会出现间歇性的暂停状态、并发时出现波浪性的忽高忽低现象
队列过长同时会加长RabbitMQ重启时间，因为启动时候需要重建索引。
队列过长还会导致集群之间节点同步消息时间变长。

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：

接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储

惰性队列的缺点:

基于磁盘存储，消息时效性会降低
性能受限于磁盘的IO

5.es介绍, 什么是倒排索引(结构)?

elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容。一个开源的分布式搜索引擎，可以用来实现搜索、日志统计、分析、系统监控等功能 elasticsearch底层是基于lucene来实现的但是相比lucene elasticsearch 有以下几点优势 1.支持分布式,可水平扩展 2.提供Restful接口,可被任何语言调用

面试官：想了解你对基础概念的认知。

解答：通俗解释一下就可以。

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。

而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。

有了倒排索引，就能实现 o（1）时间复杂度的效率检索文章了，极大的提高了检索效率

学术的解答方式：

倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分组成——词典和倒排表。

加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。

lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：

1、空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；

2、查询速度快。O(len(str))的查询时间复杂度。

6.说说spring事务有哪7种传播方式？

1、Propagation.REQUIRED，支持当前事务

事务传播特征：

当A有事务时，B会加入到A事务中，一起commit，这个时候A、B中发生异常，事务都会回滚。
当A没有事务时，B会新建事务单独执行，这个时候B发生异常，B回滚，A不回滚。

2、Propagation.SUPPORTS，支持当前事务

事务传播特征：

当A有事务时，B会加入到A事务中，一起commit，这个时候A、B中发生异常，事务都会回滚。
当A没有事务时，B会以非事务的方式执行。

3、Propagation.MANDATORY，支持当前事务，强制性的，要求调用方必须支持事务

事务传播特征：

当A有事务时，B会加入到A事务中，一起commit，这个时候A、B中发生异常，事务都会回滚。
当A没有事务时，会抛出异常，org.springframework.transaction.IllegalTransactionStateException: No existing transaction found for transaction marked with propagation ‘mandatory’

4、Propagation.REQUIRES_NEW，不支持当前事务

事务传播特征：

当A有事务时，B会将A事务挂起，新建事务，这个时候A、B中发生异常，是互不影响的。
当A没有事务时，B新建事务。

5、Propagation.NOT_SUPPORTED，不支持当前事务

事务传播特征：

当A有事务时，B会将A事务挂起，以非事务方式运行。
当A没有事务时，以非事务方式运行。

6、Propagation.NEVER，不支持当前事务，强制性的

事务传播特征：

当A有事务时，会抛出异常
当A没有事务时，以非事务方式运行。

7、Propagation.NESTED，嵌套事务

当A有事务时，A发生异常，A、B都会回滚；当B发生异常并被A捕获时，A可以正常提交事务。
当A没有事务时，B新建事务，这个时候和REQUIRES_NEW是一样的。

7.什么情况下spring的事务@Transactional会失效

类上没有加@Service
事务方法是final
方法private失效
service中调用另一个方法(事务失效)
捕获异常没有抛出
抛出异常（但不在指定的异常范围内 rollbackFor=异常类型）Throwabe Exception

@Transactional只能放到方法上
mybatis整合时，批量操作时有可能事务问题，使用编程事务

8.数据同步的方式有哪些

直连同步：业务层操作数据成功远程调用es微服保存数据到es中

直连同步是指通过定义好的规范接口API和基于动态链接库的方式直接连接业务库，比如ODBC/JDBC等规定了统一的标准接口，不同的数据库基于这套标准提供规范的驱动，从而支持完全相同的函数调用和SQL实现。比如经常使用的Sqoop就是采取这种方式进行批量数据同步的。

直连同步的方式配置十分简单，很容易上手操作，比较适合操作型业务系统的数据同步，但是会存在以下问题：

数据同步时间：随着业务规模的增长，数据同步花费的时间会越来越长，无法满足下游数仓生产的时间要求。

性能瓶颈（关键）：直连数据库查询数据，对数据库影响非常大，容易造成慢查询，如果业务库没有采取主备策略，则会影响业务线上的正常服务，如果采取了主备策略，虽然可以避免对业务系统的性能影响，但当数据量较大时，性能依然会很差。

异步：RabbitMQ，数据库操作成功发消息给mq, 由es微服消费消息，把数据保存es里

canel: 监听mysql binlog触发create/update/delete，调用es微服进行数据同步

频繁的磁盘io, 使用定时任务（数据延迟），通过记录上一次同步时间，数据一旦发生变更都是更新时间，定时扫描数据库时使用时间>上次更新时间，同步到es里

9.什么是微服务雪崩？有哪些处理方案?

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。

那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

解决雪崩问题的常见方式有四种：

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

仓壁模式（线程池隔离）：

仓壁模式来源于船舱的设计船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例：当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

流量控制：限制业务访问的QPS（每秒处理请求的多少），避免服务因流量的突增而故障。

10.线程隔离有哪些方案有哪些？区别是什么？

线程池隔离：给每个服务调用业务分配一个线程池，利用线程池本身实现隔离效果

信号量隔离：不创建线程池，而是计数器模式，记录业务使用的线程数量，达到信号量上限时，禁止新的请求。

信号量隔离的特点是？

基于计数器模式，简单，开销小

线程池隔离的特点是？

基于线程池模式，有额外开销，但隔离控制更强

区别:

1. 信号量(多线程下包下的工具类，主要通过计数器来统计共享的线程)、高扇出、低消耗。不支持主动超时、不支持异步调用
sentinel
2. 线程池低扇出高消耗、主动超时、异步调用
hystrics

11.说说熔断器的工作原理（有哪些状态，是怎么转换的）

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

状态机包括三个状态：

closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态
open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态5秒后会进入half-open状态
half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态

断路器熔断策略有三种：慢调用、异常比例、异常数

12.SpringBoot自动配置原理

1.测试代码,启动加载到启动类,则会加载启动类上的注解@SpringBootApplication

2.加载注解@SpringBootApplication,就会加载三个注解@SpringBootConfiguration, @EnableAutoConfiguration,@ComponentScan

3.@SpringBootConfiguration因为有@Configuration注解所以本身就是一个配置类,@ComponentScan是用于扫描包的作用 ,所以在只要;类在该类的包下及其子包下就可以被扫描到spring容器中.

4.@EnableAutoConfiguration自动配置 ,里面有AutoConfigurationImportSelector类,通过这个类中的ImportSelect的实现类可以读取META-INF/spring.factorys的配置文件到EnableAutoConfiguration的配置项得到spring自带的一百多项全限定字符串串数组和该配置类上的注解进行过滤是通过@conditional注解中的condition接口实现类的matches方法进行判断,如果返回值是true则保留,如果是false则过滤掉最后得到Autoconfiguration类的全限定字符串,然后在通过

反射获取类字节码就可以解析bean注解创建bean对象,把对应的bean的注册到spring容器中,使用的时候直接@Autowied注入即可 .这就springboot的自动配置原理.

13.讲讲你对CAP的理解

C: 分布式下，数据存储分主从集群，当对主写操作时，数据要及时同步给从，才可保证客户端读到的数据是一致的.
A: 分布式下，当网络分区发生时，各个分区能正常对外提供服务，而不是拒绝或阻塞
P: 分区容错性：网络故障时，会导致分区。分区发生也要保证对外可用。由于分布式下使用网络通讯，网络故障无法避免
cp 独立的分区要拒绝或阻塞请求，数据不一致，为了保证数据一致，等网络恢复
ap 失去了数据的一致，分区发生时，数据无法同步到另一个分区，分区不能拒绝或阻塞请求(保证可用性)，数据不一致

Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

ES 分片集群，用的就是CP。数据写时，先写给主，再同步给从，之后再响应客户端
Nacos: 临时实例 AP，非临时 CP

14.seata的工作原理哪三角色？分别做什么？怎么工作

TC：事务协调者
TM: 事务管理器
RM: 资源管理器
1. TM @GlobalTransactional 实现AOP，业务方法，执行之前，进行全局事务的注册, xid
2. TM把xid传递下去本地事务通过ThreadLocal，远程调用则通过请求头与mvc拦截器
3. RM通过Threadlocal 获取xid, 它就是这个xid分支事务，向TC注册自己为xid的分支事务，且执行业务代码
4. 随着远程调用，每个微服按RM流程的走
5. @GlobalTransactional 业务代码执行完了，TM向TC汇报，业务做完了，可以提交或回滚了
6. TC 通过xid检查各分支事务的状态，如果没有异常则通知所有的RM提交，有一个异常则通知所有RM回滚

15.什么是事务悬挂、空回滚、幂等(有哪些解决方案)

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

执行cancel操作时，应当判断try是否已经执行，如果尚未执行，则应该空回滚。

业务悬挂： cancel先执行再执行try，预留的资源没有被释放
允许空回滚：cancel时判断xid是否存在预留资源，不存在则添加记录标识已经执行过cancel，而不执行补偿业务
业务悬挂：空回滚时添加标识已经执行过cancel,判断是否存在补偿业务标识，存在则不执行业务。

幂等：方法无论执行多少次，结果都一样
判断预留资源状态，如果不是预期的则不处理
每次处理时添加标记(xid 存入redis), 当再执行时，先判断redis是否存在，存在则代表重复不执行

16. 说说你对redis持久化的理解?

Redis有两种持久化方案：

RDB持久化
AOF持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

RDB持久化在四种情况下会执行：

执行save命令
执行bgsave命令
Redis停机时
触发RDB条件时

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

RDB的缺点？

RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
fork子进程、压缩、写出RDB文件都比较耗时

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no