端午前最后一场面试

小咪咪 2022-10-08 11:16 71阅读 0赞

### **1、RocketMQ顺序消息扩容的过程中，如何在不停写的情况下保证消息顺序?** ###

*  成倍扩容，实现扩容前后，同样的 key，hash 到原队列，或者 hash 到新扩容的队列。
 *  扩容前，记录旧队列中的最大位点。
 *  对于每个 Consumer Group ，保证旧队列中的数据消费完，再消费新队列，也即：先对新队列进行禁读即可。

### **2、什么是定时消息？如何实现？** ###

定时消息，是指消息发到 Broker 后，不能立刻被 Consumer 消费，要到特定的时间点或者等待特定的时间后才能 被消费。  
目前，开源版本的 RocketMQ 只支持固定延迟级别的延迟消息，不支持任一时刻的延迟消息。如下表格：

![图片][901624ee5a148c5b4a36583d4fc5f3e8.png]

可通过配置文件，自定义每个延迟级别对应的延迟时间。当然，这是全局的。

如果大家想要实现任一时刻的延迟消息，比较简单的方式是插入延迟消息到数据库中，然后通过定时任务轮 询，到达指定时间，发送到 RocketMQ 中。

**实现原理**

1、 定时消息发送到 Broker 后，会被存储 Topic 为 SCHEDULE\_TOPIC\_XXXX 中，并且所在 Queue 编号为延 迟级别 - 1 。

需要 -1 的原因是，延迟级别是从 1 开始的。如果延迟级别为 0 ，意味着无需延迟。

2、Broker 针对每个 SCHEDULE\_TOPIC\_XXXX 的队列，都创建一个定时任务，顺序扫描到达时间的延迟消 息，重新存储到延迟消息原始的 Topic 的原始 Queue 中，这样它就可以被 Consumer 消费到。此处会有两个 问题：

为什么是“顺序扫描到达时间的延迟消息”？

因为先进 SCHEDULE\_TOPIC\_XXXX 的延迟消息，在其所在的 队列，意味着先到达延迟时间。  
会不会存在重复扫描的情况？

每个 SCHEDULE\_TOPIC\_XXXX 的扫描进度，会每 10s 存储到 config/delayOffset.json 文件中，所以正常情况下，不会存在重复扫描。如果异常关闭，则可能导 致重复扫描。

### **3、如何保证消费者的消费消息的幂等性？** ###

*  Producer 在发送消息时，默认会生成消息编号( msgId )，可见 org.apache.rocketmq.common.message.MessageClientExt 类。
 *  Broker 在存储消息时，会生成结合 oﬀset 的消息编号( offsetMsgId ) 。
 *  Consumer 在消费消息失败后，将该消息发回 Broker 后，会产生新的 offsetMsgId 编号，但是 msgId 不变。

### **4、Spring Boot 的核心注解是哪个？** ###

@SpringBootApplication 注解，就是 Spring Boot 的核心注解。  
整合了以下三个注解：

*  @Configuration 注解，指定类是 Bean 定义的配置类。  
    @Configuration 注解，来自 spring-context 项目，用于 Java Conﬁg ，不是 Spring Boot 新带来 的。
 *  @ComponentScan 注解，扫描指定包下的 Bean 们。  
    @ComponentScan 注解，来自 spring-context 项目，用于 Java Conﬁg ，不是 Spring Boot 新带来 的。
 *  @EnableAutoConfiguration 注解，打开自动配置的功能。如果我们想要关闭某个类的自动配置，可以设 置注解的 exclude 或 excludeName 属性。  
    @EnableAutoConfiguration 注解，来自 spring-boot-autoconfigure 项目，它才是 Spring Boot 新带来的。

### **5、SpringBoot几个常用的注解？** ###

（1）@RestController和@Controller指定一个类，作为控制器的注解  
（2）@RequestMapping方法级别的映射注解，这一个用过Spring MVC的小伙伴相信都很熟悉  
（3）@EnableAutoConfiguration和@SpringBootApplication是类级别的注解，根据maven依赖的jar来自动猜测完成正确的spring的对应配置，只要引入了spring-boot-starter-web的依赖，默认会自动配置Spring MVC和tomcat容器  
（4）@Configuration类级别的注解，一般这个注解，我们用来标识main方法所在的类,完成元数据bean的初始化。  
（5）@ComponentScan类级别的注解，自动扫描加载所有的Spring组件包括Bean注入，一般用在main方法所在的类上  
（6）@ImportResource类级别注解，当我们必须使用一个xml的配置时，使用@ImportResource和@Configuration来标识这个文件资源的类。  
（7）@Autowired注解，一般结合@ComponentScan注解，来自动注入一个Service或Dao级别的Bean  
（8）@Component类级别注解，用来标识一个组件，比如我自定了一个filter，则需要此注解标识之后，Spring Boot才会正确识别。

### **6、Spring Cloud 和 Spring Boot 的区别和关系？** ###

1.  Spring Boot 专注于快速方便的开发单个个体微服务。
2.  Spring Cloud 是关注全局的微服务协调整理治理框架以及一整套的落地解决方案，它将 Spring Boot 开发的 一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代 理，事件总线等的集成服务。
3.  Spring Boot 可以离开 Spring Cloud 独立使用，但是 Spring Cloud 离不开 Spring Boot ，属于依赖的关系。

**总结：**  
Spring Boot ，专注于快速，方便的开发单个微服务个体。Spring Cloud ，关注全局的服务治理框架。

### **7、微服务的优缺点分别是什么？** ###

**1）优点**

*  每一个服务足够内聚,代码容易理解
 *  开发效率提高，一个服务只做一件事
 *  微服务能够被小团队单独开发
 *  微服务是松耦合的，是有功能意义的服务
 *  可以用不同的语言开发,面向接口编程
 *  易于与第三方集成
 *  微服务只是业务逻辑的代码，不会和 HTML、CSS 或者其他界面组合
    
    开发中，两种开发模式

前后端分离

全栈工程师

*  可以灵活搭配,连接公共库/连接独立库

**2）缺点**

*  分布式系统的负责性
 *  多服务运维难度，随着服务的增加，运维的压力也在增大
 *  系统部署依赖
 *  服务间通信成本
 *  数据一致性
 *  系统集成测试
 *  性能监控

### **8、负载平衡的意义什么？** ###

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工 作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个 组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例 如多层交换机或域名系统服务器进程。

### **9、SpringCloud中Feign 的实现原理？** ###

Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：

*  首先，如果你对某个接口定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理。
 *  接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。
 *  Feign的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址。
 *  最后针对这个地址，发起请求、解析响应。

![图片][accf349babb59285caf8604d388b6636.png]

### **10、简单介绍一下SpringCloud的常用组件。** ###

*  服务发现——Netflix Eureka
 *  客服端负载均衡——Netflix Ribbon
 *  断路器——Netflix Hystrix
 *  服务网关——Netflix Zuul
 *  分布式配置——Spring Cloud Config

Eureka

作用：实现服务治理（服务注册与发现）

简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。

由两个组件组成：Eureka服务端和Eureka客户端。

Eureka服务端用作服务注册中心。支持集群部署。

Eureka客户端是一个java客户端，用来处理服务注册与发现。

在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

Ribbon

作用：Ribbon，主要提供客户侧的软件负载均衡算法。

简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。

注意看上图，关键点就是将外界的rest调用，根据负载均衡策略转换为微服务调用。Ribbon有比较多的负载均衡策略，以后专门讲解。

Hystrix

作用：断路器，保护系统，控制故障范围。

简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

Zuul

作用：api网关，路由，负载均衡等多种作用

简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

Config

作用：配置管理

简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。

这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

![202106211035449.jpeg][]

> 另附资源下载：关注 “**Java面试百分百**”  
> 1，后台回复：**“面试资料”**，可获取一份最新的Java面试资料。

[901624ee5a148c5b4a36583d4fc5f3e8.png]: /images/20221005/62802e47e2d34afaa8cefff0e06fe7d1.png
[accf349babb59285caf8604d388b6636.png]: /images/20221005/00acdb73d023470992d5e577b9054e5e.png
[202106211035449.jpeg]: /images/20221005/fd9671803a65467fb7eba7a02a5366b7.png