这是俺不会的

爱大宝贝(๑˙❥˙๑)

已于 2023-11-02 23:47:21 修改

阅读量93

点赞数 1

于 2023-10-24 17:15:30 首次发布

本文链接：https://blog.csdn.net/weixin_51435812/article/details/134016539

版权

springMvc

原文
springmvc的核⼼是什么，请求的流程是怎么处理的，控制反转怎
么实现的?
一、DispatcherServlet作用
DispatcherServlet是前端控制器设计模式的实现，提供Spring Web MVC的集中访问点，而且负责职责的分派，而且与Spring IoC容器无缝集成，从而可以获得Spring的所有好处。
在这里插入图片描述
springmvc是基于servlet的前端控制框架,核⼼是ioc和aop(基于spring实现)
核⼼架构的具体流程步骤如下：

1、用户发送请求至前端控制器DispatcherServlet。

2、 DispatcherServlet收到请求调用HandlerMapping处理器映射器。

3、处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。（HandlerExecutionChain 包含handler和interceptors。
处理器适配器去执行Handler，执行目标方法前后是需要执行拦截器的）

4、 DispatcherServlet调用HandlerAdapter处理器适配器。

5、 HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。

6、 Controller执行完成返回ModelAndView。

7、 HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。

8、 DispatcherServlet将ModelAndView传给ViewReslover视图解析器。

9、 ViewReslover解析后返回具体View。

10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。

11、 DispatcherServlet响应用户。

二、DispatcherServlet在web.xml中的配置

<servlet>
        <servlet-name>springmvc</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
        <servlet-name>springmvc</servlet-name>
        <url-pattern>/</url-pattern>
</servlet-mapping>

spring clud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

优点：
1.耦合度比较低。不会影响其他模块的开发。
2.减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。
3.配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
4.微服务跨平台的，可以用任何一种语言开发。
5.每个微服务可以有自己的独立的数据库也有用公共的数据库。
6.直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行
服务通信

缺点：
1.部署比较麻烦，给运维工程师带来一定的麻烦。
2.针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库。
3.系统集成测试比较麻烦
4.性能的监控比较麻烦。【最好开发一个大屏监控系统】

1.服务注册

CAP： C：一致性>Consistency; 取舍：(强一致性、单调一致性、会话一致性、最终一致性、弱一
致性) A：可用性>Availability; P：分区容错性>Partition tolerance;


nacos、ZooKeeper、eureka都可以做服务注册与发现功能，他们的区别：

 1. ZooKeeper中的节点服务挂了就要选举 在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的， 选举就是改微服务做了集群，必须有一台主其他的都是从

2. Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的

3. Eureka本质上是一个工程,而ZooKeeper只是一个进程

4. Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪

5. ZooKeeper保证的是CP，Eureka保证的是AP

nacos和eureka区别：

1：在提供者和注册中心之间。
（1）Eureka中会定时向注册中心发送心跳，如果在短期内没有发送心跳，则就会直接剔除。

（2）Nacos也会向注册中心发送心跳，但是它的频率要比Eureka快。在Nacos中又分为临时实例和非临时实例。如果是临时实例的话，短期内没有发送心跳，则会直接剔除。但是如果是非临时实例长时间宕机，不会直接剔除，并且注册中心会直接主动询问并且等待非临时实例。

2：在消费者和注册中心之间。
（1）Eureka会定时(默认30秒，超过90秒剔除)向注册中心定时拉去服务，如果不主动拉去服务，注册中心不会主动推送。

 （2）Nacos中注册中心会定时（默认为5秒）向消费者主动推送信息  ，这样就会保持数据的准时性。

2. 网关

关于网关->服务的负载均衡的想法_请求是先到网关还是负载均衡-CSDN博客](https://blog.csdn.net/LucifeR_Shun/article/details/103971846) 

### 为什么有了Ngnix还要用网关？

1. 统一入口：网关作为整个系统的入口，可以提供统一的API接口，对外隐藏后端微服务的具体实现细节。通过网关，客户端只需要与网关进行通信，无需直接与后端微服务进行交互，从而简化了客户端的调用方式。

2. 路由和过滤：网关可以根据不同的请求路径或请求头，将请求转发到不同的后端微服务。通过路由配置，可以实现动态的请求转发和灵活的服务组合。同时，网关还可以进行请求过滤、鉴权、限流等操作，保护后端微服务的安全性和稳定性。

3. 网关可以对请求的结果进行缓存，减少对后端微服务的请求压力，提高系统的性能和响应速度。同时，网关还可以管理和分发静态资源，例如图片、CSS和JavaScript文件等，从而减少对后端服务的请求，提高系统的效率。

4. 网关作为外部访问的唯一入口，若挂掉了，那全部的服务就无法访问了，为了防止这种情况出现，网关也应该和服务一样做集群。然而网关作为唯一入口，总不能让用户记住多个域名吧，所以在网关之上，我们加一层nginx做反向代理。这样做有什么好处呢？首先，如果我们使用nginx作为网关，则权限验证、日志管理等原来网关做的需要在nginx上实现，nginx不支持java开发，这会增加开发难度，所以nginx仅用做反向代理（负载均衡也可以），网关仍维持原功能。这样形成了下图的关系（服务、注册中心、配置中心这些也都是可以集群的省略不画）

3. Ngnix、Ribbon负载均衡策略

轮询
weight 权重
ip_hash：
ip_hash是将每个请求按照访问ip的hash结果进行分配，这种方式可以保证同一个用户会固定访问一个后端服务器。优点：可以保证session会话，解决服务器之间session不能共享的问题。
least_conn：
将请求转发给连接数较少的后端服务器。每个后端服务器配置可能不同，处理的请求也有可能不同，对于处理的请求有快有慢，least_conn是根据后端服务器的连接情况，动态的选择连接数量较少的一台服务器来处理当前的请求。

Ribbon: 内置了 7 种负载均衡策略:轮询策略、权重策略、随机策略、最小连接数策略、重试策略、可用性敏感策略、区域性敏感策略,并且用户可以通过继承 RoundRibbonRule 来实现自定义负载均衡策略。

4. RabbitMQ

详情

1. 消息丢失

在这里插入图片描述

生产者丢失
方案1 ：开启RabbitMQ事务
可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。

// 开启事务  
channel.txSelect();  
try {  
   // 这里发送消息  
} catch (Exception e) {  
   channel.txRollback(); 
// 这里再次重发这条消息
}
// 提交事务  
channel.txCommit();

缺点：

RabbitMQ 事务机制是同步的，你提交一个事务之后会阻塞在那儿，采用这种方式基本上吞吐量会下来，因为太耗性能。

方案2：使用confirm机制
事务机制和 confirm 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的

在生产者开启了confirm模式之后，每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq之中，rabbitmq会给你回传一个ack消息，告诉你这个消息发送OK了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试。而且你可以结合这个机制知道自己在内存里维护每个消息的id，如果超过一定时间还没接收到这个消息的回调，那么你可以进行重发。

//开启confirm  
channel.confirm();  
//发送成功回调  
public void ack(String messageId){
}
// 发送失败回调  
public void nack(String messageId){  
    //重发该消息  
}

针对RabbitMQ

主要需要应对三点：

要保证rabbitMQ不丢失消息，那么就需要开启rabbitMQ的持久化机制，即把消息持久化到硬盘上，这样即使rabbitMQ挂掉在重启后仍然可以从硬盘读取消息；

如果rabbitMQ单点故障怎么办，这种情况倒不会造成消息丢失，这里就要提到rabbitMQ的3种安装模式，单机模式、普通集群模式、镜像集群模式，这里要保证rabbitMQ的高可用就要配合HAPROXY做镜像集群模式；

如果硬盘坏掉怎么保证消息不丢失。

（1）消息持久化
RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外crash掉，消息就会丢失。

所以就要对消息进行持久化处理。如何持久化，下面具体说明下。要想做到消息持久化，必须满足以下三个条件，缺一不可。

Exchange 设置持久化

Queue 设置持久化

Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息

（2）设置集群镜像模式
先来介绍下RabbitMQ三种部署模式：

单节点模式：最简单的情况，非集群模式，节点挂了，消息就不能用了。业务可能瘫痪，只能等待。

普通模式：消息只会存在与当前节点中，并不会同步到其他节点，当前节点宕机，有影响的业务会瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）。

镜像模式：消息会同步到其他节点上，可以设置同步的节点个数，但吞吐量会下降。属于RabbitMQ的HA方案

消费者丢失

2. 消息积压

3. 消息的补偿机制

sprin gboot

1. 好处

1. 容易上手，提升开发效率，为 Spring 开发提供一个更快、更简单的开发框架。
2. 开箱即用，远离繁琐的配置。
3. 提供了一系列大型项目通用的非业务性功能，例如：内嵌服务器、安全管理、运行数据监
控、运行状况检查和外部化配置等。
4. SpringBoot总结就是使编码变简单、配置变简单、部署变简单、监控变简单等等

2.Spring Boot 的核心注解

@SpringBootApplication，它主要由三个注解组成：

@SpringBootConfiguration：标注当前类是 Spring Boot 的配置类，相当于传统的 XML 配置文件。
@EnableAutoConfiguration：开启 Spring Boot
的自动配置功能，根据依赖自动配置项目，也可以关闭某个自动配置的选项。
@ComponentScan：开启组件扫描，自动扫描当前类所在包及其子包下被
@Component、@Service、@Repository、@Controller 注解标记的类并纳入 Spring 容器中管理。

3. SpringBoot Starter的工作原理

我个人理解SpringBoot就是由各种Starter组合起来的，我们自己也可以开发Starter
在sprinBoot启动时由@SpringBootApplication注解会自动去maven中读取每个starter中的
spring.factories文件,该文件里配置了所有需要被创建spring容器中的bean，并且进行自动配置把
bean注入SpringContext中 //（SpringContext是Spring的配置文件）

Spring Boot Starter 是一种用于简化依赖管理和配置的方式。它通过提供一组预定义的依赖和默认的配置，使得开发者可以更快速、更方便地构建 Spring Boot 应用。

Spring Boot Starter 的工作原理可以简单概括为以下几个步骤：

自动装配：Spring Boot Starter 中的依赖通常会包含一个或多个自动配置类（AutoConfiguration），这些自动配置类使用了条件注解（@Conditional）来根据项目的依赖和配置情况进行自动配置。通过分析项目的依赖和配置，Spring Boot 可以自动决定哪些自动配置类需要生效。
条件化加载：Spring Boot Starter 中的自动配置类通常会使用条件注解（@Conditional）来控制自动配置的加载条件。条件注解可以根据一定的条件来判断是否需要加载该自动配置类。例如，只有当项目中存在某个特定的依赖时，才会加载对应的自动配置类。
自定义配置：Spring Boot Starter 通常会提供一些默认的配置，但也允许用户进行自定义配置。用户可以在项目的配置文件（如 application.properties 或 application.yml）中覆盖默认配置，或者通过编写自己的配置类来进行自定义配置。
自动装配顺序：Spring Boot Starter 中的自动配置类可以通过实现 Ordered 接口或使用 @Order 注解来指定加载顺序。这样可以确保某些自动配置类在其他自动配置类之前或之后进行加载，以满足特定的需求。

总的来说，Spring Boot Starter 的工作原理就是通过自动装配和条件化加载来自动配置项目，简化了依赖管理和配置的过程，使开发者可以更加专注于业务逻辑的实现。

4. SpringBoot事务的使用

首先使用注解EnableTransactionManagement开启事务之后，然后在
Service方法上添加注解Transactional便可。

5. 如何在 Spring Boot 启动的时候运行一些特定的代码

可以实现接口 ApplicationRunner 或者 CommandLineRunner，这两个接口实现方式一样，它们
都只提供了一个 run 方法

6. Spring Boot 有4种读取配置的方式

Spring Boot 可以通过 @PropertySource,@Value,@Environment, @ConfigurationPropertie注
解来绑定变量

7. SpringBoot的自动配置原理

主要是Spring Boot的启动类上的核心注解SpringBootApplication注解主配置类，有了这个主配置
类启动时就会为SpringBoot开启一个@EnableAutoConfiguration注解自动配置功能。

有了这个EnableAutoConfiguration的话就会：

从配置文件META_INF/Spring.factories加载可能用到的自动配置类
去重，并将exclude和excludeName属性携带的类排除
过滤，将满足条件（@Conditional）的自动配置类返回

8. Spring Boot 配置加载顺序

1.properties文件；
2.YAML文件；
3.系统环境变量；
4.命令行参数；
等等……

9. YAML 配置的优、劣势

配置有序，在一些特殊的场景下，配置有序很关键
简洁明了，他还支持数组，数组中的元素可以是基本数据类型也可以是对象
相比properties 配置文件，YAML 还有一个缺点，就是不支持 @PropertySource 注解导入自定义的 YAML 配置。

10. Spring Boot 中解决跨域问题

在 Spring Boot 中解决跨域问题可以通过以下几种方式：

使用 @CrossOrigin 注解：可以在 Controller 类或方法上使用 @CrossOrigin 注解来允许指定的域名或 IP 地址进行跨域访问。例如，可以在 Controller 类上添加 @CrossOrigin(origins = “http://example.com”) 来允许来自 “http://example.com” 的跨域请求。
配置全局跨域配置：可以通过编写一个配置类来配置全局的跨域配置。可以创建一个继承自 WebMvcConfigurerAdapter 的配置类，并重写 addCorsMappings 方法来配置跨域访问。例如，可以添加以下代码来配置允许所有域名的跨域请求：

@Configuration
public class CorsConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("*")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

使用 Filter 进行跨域处理：可以编写一个自定义的 Filter 来处理跨域请求。可以创建一个实现了 javax.servlet.Filter 接口的类，并在 doFilter 方法中添加跨域处理逻辑。然后，在配置类中将该 Filter 添加到过滤器链中。例如，可以创建一个 CorsFilter 类来处理跨域请求：

@Component
public class CorsFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization, X-Requested-With");
        chain.doFilter(req, res);
    }
}

使用第三方库：还可以使用一些第三方库来处理跨域问题，如 Spring Security、Apache Shiro 等。这些库提供了更多的跨域处理选项和配置方式，可以根据具体需求选择使用。

以上是几种常见的解决跨域问题的方式，在实际开发中可以根据具体情况选择适合的方式进行跨域处理。

3. javase

1. 接口和抽象类的·区别

接口特性

- 接口中每一个方法也是隐式抽象的,接口中的方法会被隐式的指定为 public abstract（只能是 public abstract，其他修饰符都会报错），JDK 1.8 以后，接口里可以有静态方法和方法体了
- 没有构造方法、动态代码块、静态代码块。
- 当类实现接口的时候，类要实现接口中所有的方法。否则，类必须声明为抽象的类。

抽象类中的方法可以有方法体，就是能实现方法的具体功能，但是接口中的方法不行。
抽象类中的成员变量可以是各种类型的，而接口中的成员变量只能是 public static final 类型的。
接口中不能含有静态代码块以及静态方法(用 static 修饰的方法)，而抽象类是可以有静态代码块和静态方法。
一个类只能继承一个抽象类，而一个类却可以实现多个接口。
类方法调用优先于接口
注：JDK 1.8 以后，接口里可以有静态方法和方法体了。
注：JDK 1.8 以后，接口允许包含具体实现的方法，该方法称为"默认方法"，默认方法使用 default 关键字修饰。更多内容可参考 Java 8 默认方法。
注：JDK 1.9 以后，允许将方法定义为 private，使得某些复用的代码不会把方法暴露出去。更多内容可参考 Java 9 私有接口方法。

2. 什么是反射？

 反射就是动态加载对象，并对对象进行剖析。在运行状态中，对于任意一个类，都能够

知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法，这种动
态获取信息以及动态调用对象方法的功能成为 Java 反射机制。

3. Servlet 的生命周期

Servlet 生命周期可以分成四个阶段：加载和实例化、初始化、服务、销毁。

当客户第一次请求时，首先判断是否存在 Servlet 对象，若不存在，则由 Web 容器创建对象
而后调用 init()方法对其初始化（如加载配置文件、建立数据库连接等），此初始化方法在整个 Servlet 生命周期中只调用一次。
完成 Servlet 对象的创建和实例化之后，Web 容器会调用 Servlet 对象的 service()方法来处理请求，Servlet 容器会为每个请求创建一个新的线程。在 service 方法中，Servlet 可以读取请求数据、进行业务处理，并生成响应数据发送给客户端。

当 Web 容器关闭或者 Servlet 对象要从容器中被删除时，会自动调用 destory()方法。

 一般情况下，Servlet只有在容器关闭时才会被销毁，但也可以通过Servlet的destroy()方法手动销毁Servlet。当Servlet不再被需要时，可以通过调用destroy()方法来释放资源、关闭数据库连接、取消注册等操作。Servlet的生命周期是整个应用程序中Servlet的初始化、请求处理和销毁的过程。