Java 攻城狮面试题 06_Spring Cloud 微服务
Spring Cloud 基础
什么是微服务架构？
微服务架构就是将单体的应用程序分成多个应用程序，这多个应用程序就成为微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
什么是 Spring Cloud？
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
为什么需要学习Spring Cloud？
-
首先springcloud基于spingboot的优雅简洁，可还记得我们被无数xml支配的恐惧？可还记得springmvc，mybatis错综复杂的配置，有了spingboot，这些东西都不需要了，spingboot好处不再赘诉，springcloud就基于SpringBoot把市场上优秀的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理
-
什么叫做开箱即用？即使是当年的黄金搭档dubbo+zookeeper下载配置起来也是颇费心神的！而springcloud完成这些只需要一个jar的依赖就可以了！
-
springcloud大多数子模块都是直击痛点，像zuul解决的跨域，fegin解决的负载均衡，hystrix的熔断机制等等等等
Spring Cloud的优缺点？
优点：
- 耦合度比较低。不会影响其他模块的开发。
- 减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。
- 配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
- 微服务跨平台的，可以用任何一种语言开发。
- 每个微服务可以有自己的独立的数据库也有用公共的数据库。
- 直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。
缺点：
- 部署比较麻烦，给运维工程师带来一定的麻烦。
- 针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库。
- 系统集成测试比较麻烦
- 性能的监控比较麻烦。【最好开发一个大屏监控系统】
总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。
SpringBoot和SpringCloud的区别？
-
SpringBoot专注于快速方便的开发单个个体微服务；
-
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来；
-
为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务；
-
SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系；
-
SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。
使用 Spring Boot 开发分布式微服务时，我们面临什么问题？
-
与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
-
服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。
-
冗余-分布式系统中的冗余问题。
-
负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
-
性能-问题 由于各种运营开销导致的性能问题。
Spring Cloud和SpringBoot版本对应关系？
| Spring Cloud Version | SpringBoot Version |
|---|---|
| Hoxton | 2.2.x |
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
Spring Cloud由什么组成？
这就有很多了，我讲几个开发中最重要的：
Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件
-
Spring Cloud Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
-
Spring Cloud Zuul：服务网关，由 Zuul 网关转发请求给对应的服务；
-
Spring Cloud Ribbon：客户端负载均衡的服务调用组件，从一个服务的多台机器中选择一台，具有多种负载均衡调用策略；
-
Spring Cloud Feign：声明性的Web服务客户端，基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求；
-
Spring Cloud Hystrix：断路器，提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题；
-
Spring Cloud Config：分布式统一配置管理
等20几个框架，开源一直在更新
Spring Cloud Alibaba由什么组成？
Spring Cloud Alibaba 默认提供了如下核心功能（先了解）：
-
Nacos 服务注册与发现：基于Spring Cloud 服务注册与发现标准，借助Nacos进行实现，默认还集成了 Ribbon 的支持。
-
Nacos 分布式配置管理：基于Nacos支持分布式系统中的外部化配置，配置更改时自动刷新。
-
Sentinel 服务限流降级：默认支持 WebServlet、OpenFeign、RestTemplate、Spring Cloud Gateway, RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
-
消息驱动能力：
基于Spring Cloud Stream 为微服务应用构建消息驱动能力。 -
分布式事务：
使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。。 -
分布式任务调度：
提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker上执行。
SpringCloud主要项目？
Spring Cloud的子项目，大致可分成两类：
-
一类是对现有成熟框架"Spring Boot化"的封装和抽象，也是数量最多的项目；
-
第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。
注册中心与配置中心
常用注册中心？
常用注册中心有
- Zookeeper (雅虎Apache)（支持，专业的独立产品。例如：dubbo）
- Eureka (Netfix)（原生，2.0遇到性能瓶颈，停止维护）
- Nacos (Alibaba)
- Consul (Google)（原生，GO语言开发）
微服务间远程交互的过程？
- 先去注册中心查询服务的服务器地址
- 调用方给对方发送http请求
Eureka
服务注册和发现是什么意思？Spring Cloud 如何实现？
当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。
什么是Eureka？
Eureka 作为 SpringCloud 的服务注册功能服务器，他是服务注册中心，系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中，并且保持心跳，这样工作人员可以通过Eureka Service来监控各个微服务是否运行正常。
什么是Eureka的自我保护模式？
默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。
Eureka怎么实现高可用？
集群吧，注册多台Eureka，然后把SpringCloud服务互相注册，客户端从Eureka获取信息时，按照Eureka的顺序来访问。
DiscoveryClient的作用？
可以从注册中心中根据服务别名获取注册的服务器信息。
Spring Cloud Config
什么是Spring Cloud Config?
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持，可以方便的对微服务各个环境下的配置进行集中式管理。Spring Cloud Config分为Config Server和Config Client两部分。Config Server负责读取配置文件，并且暴露Http API接口，Config Client通过调用Config Server的接口来读取配置文件。
分布式配置中心的作用？
动态变更项目配置信息而不必重新部署项目。（当某个配置项发生变更时，不停机就可以动态刷新服务内部的配置项）
分布式配置中心有哪些框架？
- Apollo
- zookeeper
- springcloud config
- nacos
Nacos 注册中心
什么是Nacos？
Nacos（DynamicNaming and Configuration Service）是一个应用于服务注册与发现、配置管理的平台。它孵化于阿里巴巴，成长于十年双十一的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。
其官网地址如下：
https://nacos.io/zh-cn/docs/quick-start.html
Nacos 优点？
相对于 Spring Cloud Eureka 来说，Nacos 更强大。它很好的支持了阿里的双11活动，不仅可以做注册中心，还可以作为配置中心，稳定性和性能都很好。
Nacos = Spring Cloud Eureka + Spring Cloud Config
-
Nacos 可以与 Spring, Spring Boot, Spring Cloud 集成，并能代替 Spring Cloud Eureka, Spring Cloud Config。
-
通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更。
-
通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-discovery 实现服务的注册与发现。
-
Nacos 默认集成了 Ribbon 来实现负载均衡，Ribbon配合RestTemplate，可以非常容易的实现服务之间的远程访问。
Nacos的配置流程？
1、初始化配置
- 配置JAVA_HOME环境变量，MySQL版本为5.7以上（MariaDB10.5以上)；
- Nacos下载对应版本，
https://github.com/alibaba/nacos/releases; - 解压Nacos到本地，登陆mysql，执行sql指令，
source d:/nacos-mysql.sql，将 nacos_config 导入数据库 - 打开/conf/application.properties里打开默认配置，并基于你当前环境配置要连接的数据库，连接数据库时使用的用户名和密码(假如前面有"#"要将其去掉)
- 启动Nacos服务，Linux:
./startup.sh -m standalone，Windows：startup.cmd -m standalone - 访问Nacos服务，
http://localhost:8848/nacos
2、服务注册
- 模块中添加jar包
spring-cloud-starter-alibaba-nacos-discovery - 创建并修改配置文件application.yml(或者application.properties)，实现服务注册
spring:
application:
name: sca-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848
Nacos在windows中的的初步配置？
(application.properties访问数据库的数据源)
Nacos的健康检查机制？
1、服务启动时如何找到服务启动注册配置类?
通过 Nacos 的 NacosNamingService 模块
2、在Nacos中服务提供者是如何向Nacos注册中心(Registry)续约的？(5秒心跳)
在微服务启动后每过5秒，会由微服务内置的 Nacos 客户端主动向 Nacos 服务器发起心跳包（HeartBeat）。心跳包会包含当前服务实例的名称、IP、端口、集群名、权重等信息。
naming 模块收到心跳包，首先根据 IP 与端口判断 Nacos 是否存在该服务实例。
- 如果实例信息不存在，在 Nacos 中注册登记该实例。而注册的本质是将新实例对象存储在“实例 Map”集合中；
- 如果实例信息已存在，记录本次心跳包发送时间；
- 设置实例状态为“健康”；
- 推送“微服务状态变更”消息；
- naming 模块返回心跳包时间间隔。
到这里一次完整的心跳包处理已完成。
3、对于Nacos服务来讲它是如何判定服务实例的状态？(检测心跳包，15,30)
nacos server 也会向 client 主动发起健康检查，支持tcp/http检查。检测心跳包客户端的心跳包，如果15秒内无心跳且健康检查失败则认为实例不健康，如果30秒内健康检查失败则剔除实例。
Nacos中服务消费方是如何调用服务提供方的服务的？(RestTemplate)
Nacos 默认集成了 Ribbon 来实现负载均衡，Ribbon配合RestTemplate，可以非常容易的实现服务之间的远程访问。
Nacos 配置中心
配置中心一般都会配置什么内容？
可能会经常变化的配置信息，例如连接池，日志、线程池、限流熔断规则
什么信息一般不会写到配置中心?
- 服务端口
- 服务名
- 服务的注册地址
- 配置中心
项目中为什么要定义bootstrap.yml文件？
此文件被读取的优先级比较高，可以在服务启动时读取配置中心的数据。
Nacos配置中心宕机了，我们的服务还可以读取到配置信息吗？
可以从内存，客户端获取了配置中心的配置信息以后，会将配置信息在本地内存中存储一份。
微服务应用中我们的客户端如何获取配置中心的信息?
我们的服务一般首先会从内存读取配置信息，同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息。
微服务应用中客户端如何感知配置中心数据变化？
当数据发生变化时，nacos找到它维护的客户端，然后通知客户端去获取更新的数据，客户端获取数据以后更新本地内存，并在下次访问资源时，刷新@Value注解描述的属性值，但是需要借助@RefreshScope注解对属性所在的类进行描述。
服务启动后没有从配置中心获取我们的配置数据是什么原因?
依赖,配置文件名字bootstrap.yml，配置中心的dataId名字是否正确，分组是否正确，配置的名字是否正确，缩进关系是否正确，假如是动态发布，类上是否有@RefreshScope注解
服务配置中心的使用？
1、已有的项目中添加配置依赖spring-cloud-starter-alibaba-nacos-config
2、将项目中的application.yml的名字修改为bootstrap.yml配置文件（启动优先级最高）
3、打开nacos配置中心，新建配置。其中Data ID的值要与bootstrap.yml中定义的spring.application.name的值相同(服务名-假如有多个服务一般会创建多个配置实例，不同服务对应不同的配置实例)。
4、在模块中将需要使用动态配置的类中添加@RefreshScope注解，@RefreshScope 动态刷新配置，此注解用于告诉spring,一旦在配置发生变化时，重新构建标记对象。
负载均衡
负载平衡的意义什么？
-
简单来说： 先将集群，集群就是把一个的事情交给多个人去做，假如要做1000个产品给一个人做要10天，我叫10个人做就是一天，这就是集群，负载均衡的话就是用来控制集群，他把做的最多的人让他慢慢做休息会，把做的最少的人让他加量让他做多点。
-
在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。
SpringCloud有几种调用接口方式？
- Feign
- RestTemplate
服务间的调用方式？
- RestTemplate + 手写URL 调用
- RestTemplate + Ribbon（@LoadBalanced）
- Feign
第一种：并发比较大，服务服务比较多，我们需要管理服务，就需要注册中心，我们还需要服务间的负载均衡。但代码编写的复杂多相对高一些，我们需要自己获取ip，获取端口，拼接字符串等。
第二种：我们要基于第二种进行代码简化，底层提供了一种拦截器，把基于服务名获取服务实例的过程在拦截器中做了封装，简化了代码的开发。但是加了拦截器多少会在性能少有一点损耗。
第三种方式主要是从代码结构上做一个挑战，我们前面三种基于RestTemplate进行服务调用，本身属于一种远程服务调用业务，能够将这种业务写到一个业务对象中，Feign方式就诞生了，它主要对代码结构的一种优化。
Ribbon
Ribbon是什么？
Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法。Ribbon客户端组件提供一系列完善的配置项，如连接超时，重试等。简单的说，就是在配置文件中列出后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随即连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。（有点类似Nginx）
Nginx与Ribbon的区别？
Nginx是反向代理同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。
Ribbon底层实现原理
Ribbon使用discoveryClient从注册中心读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。
@LoadBalanced注解的作用
在RestTemplate上添加 @LoadBalanced 注解
作用：开启客户端负载均衡。在使用 RestTemplate 的时候，如果 RestTemplate 上面有这个注解，那么这个 RestTemplate 调用的远程地址，会走负载均衡器。
简单原理：使用了这个注解以后 ，会在 restTemplate 里面通过 restTemplate.setInterceptors 放入 LoadBalancerInterceptor（负载均衡拦截器），这个过滤器会在请求远程成接口的时候动态判断请求的域是不是负载均衡支持的服务的地址。如果是，那么就会代理使用这个负载均衡器来调用。
@Bean
@LoadBalanced //这个注解描述RestTemplate对象时,系统底层会对RestTemplate对象的请求进行拦截
public RestTemplate loadBalanceRestTemplate(){
return new RestTemplate();
}
@RestController
public class ConsumerController{
@Value("${spring.application.name}")
private String appName;
@Autowired
private LoadBalancerClient loadBalancerClient;
//负载均衡应用方式2:@LoadBalance
//http://localhost:8610/consumer/doRestEcho3
@GetMapping("/consumer/doRestEcho3")
public String doRestEcho3(){
String serviceId="sca-provider";//直接放入sca-provider
String url=String.format("http://%s/provider/echo/%s",serviceId,appName);
//底层在基于loadBalanceRestTemplate对象访问方式,会启动一个拦截器
return loadBalanceRestTemplate.getForObject(url,String.class);
}
}
Ribbon负载均衡策略有哪些？
有8种，可以通过查看IRule接口的实现类进行分析
| 名称 | 解释 |
|---|---|
| RoundRobinRule | 轮训策略 |
| RandomRule | 随机策略 |
| BestAvailableRule | 过滤出故障服务器后，选择一个并发量最小的 |
| WeightedResponseTimeRule | 针对响应时间加权轮询 |
| AvailabilityFilteringRule | 可用过滤策略,先过滤出故障的或并发请求大于间值的一部分服务实例,然后再以线性轮询的方式从过滤后的实例清单中选出一个 |
| ZoneAvoidanceRule | 从最佳区域实例集合中选择一个最优性能的服务实例 |
| RetryRule | 选择一个Server,如果失败,重新选择一个Server重试 |
当系统提供的负载均衡策略不能满足我们需求时，我们还可以基于IRule接口自己定义策略。
Feign
什么是Feign？
Feign 最早是由 Netflix 公司进行维护的，后来 Netflix 不再对其进行维护，最终 Feign 由一些社区进行维护，更名为 OpenFeign。
-
Feign 是一个声明web服务客户端，这使得编写web服务客户端更容易。
-
他将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，不过要注意，调用方法要和本地抽象方法的签名完全一致。
基于Feign可以更加友好的实现服务调用，简化服务消费方对服务提供方方法的调用
Feign方式的调用，底层负载均衡是如何实现的？
集成 Ribbon
Feign 调用过程分析
Feign应用过程分析（底层逻辑先了解）：
-
通过 @EnableFeignCleints 注解告诉springcloud,启动 Feign Starter 组件。
-
Feign Starter 在项目启动过程中注册全局配置，扫描包下所由@FeignClient注解描述的接口，然后由系统底层创建接口实现类(JDK代理类)，并构建类的对象，然后交给spring管理(注册 IOC 容器)。
-
接口被调用时被动态代理类逻辑拦截，将 @FeignClient 请求信息通过编码器生成 Request对象，基于此对象进行远程过程调用。
-
请求对象经Ribbon进行负载均衡，挑选出一个健康的 Server 实例（instance）。
-
通过 Client 携带 Request 调用远端服务返回请求响应。
-
通过解码器生成 Response 返回客户端，将信息流解析成为接口返回数据。
Feign的使用流程？
1、在远程调用方（A调用B，在A模块添加），添加项目依赖(SpringCloud团队基于OpenFeign研发了starter)，spring-cloud-starter-openfeign。
2、远程调用模块的启动类添加@EnableFeignClients ,@EnableFeignClients注解描述启动类时，用于告诉springboot在启动时，扫描启动类所在包或子包中的类，假如接口上有@FeignClient定义的feign客户端，则对这样的接口创建其实现类（注册到IOC容器中），在实现类内部帮我们进行远程服务调用。
3、编写一个feign类型的端口
- 添加@FeignClient(name=“xxx”,contextId = “remoteOtherService”,fallback = ProviderFallback.class)
name:为被调用模块的名称
contextId:远程调用服务的唯一标识(当创建多个feign接口时使用)
fallback ：调用的服务突然不可用了或者调用过程超时，实现熔断
- @FeignClient 注解用于描述远程服务调用接口，这个接口不需要你实现写实现类， 你只需要定义访问规则即可（例如请求方式，请求url，请求参数），@FeignClient描述的接口底层会为其创建实现类。
- @FeignClient 注解描述的接口的实现类对象会默认交给spring管理，这个bean对象的名字默认就是name属性指定的值，这个name还有一个层面的含义，就是你远程调用的服务名。
- 定义Http请求API，基于此API借助OpenFeign访问远端服务
@FeignClient(name = "sca-provider",
contextId = "remoteOtherService",
fallback = ProviderFallback.class)
public interface RemoteOtherService {
@GetMapping("/provider/echo/{msg}")
String echoMsg(@PathVariable("msg") String msg);
}
}
@FeignClient注解的作用是什么？
@FeignClient 注解用于描述远程服务调用接口，这个接口不需要你实现写实现类， 你只需要定义访问规则即可（例如请求方式，请求url，请求参数），@FeignClient描述的接口底层会为其创建实现类。
@FeignClient标签的常用属性?
-
name：指定FeignClient的名称，如果项目使用了Ribbon，name属性会作为微服务的名称，用于服务发现。
-
url: url一般用于调试，可以手动指定@FeignClient调用的地址。
-
decode404:当发生http 404错误时，如果该字段位true，会调用decoder进行解码，否则抛出FeignException。
-
configuration: Feign配置类，可以自定义Feign的Encoder、Decoder、LogLevel、Contract。
-
fallback: 定义容错的处理类，当调用远程接口失败或超时时，会调用对应接口的容错逻辑，fallback指定的类必须实现@FeignClient标记的接口。
-
fallbackFactory: 工厂类，用于生成fallback类示例，通过这个属性我们可以实现每个接口通用的容错逻辑，减少重复的代码。
-
path: 定义当前FeignClient的统一前缀。
Feign 调用的熔断机制
1、使用fallbackFactory 实现熔断
- 在服务消费端入口文件开启feign注解功能，添加@EnableFeignClients注解
- 在Feign访问接口中应用FallbackFactory对象：fallbackFactory = ProviderFallbackFactory.class
@FeignClient(name = "sca-provider",
contextId = "remoteProviderService",
fallbackFactory = ProviderFallbackFactory.class)
- 创建ProviderFallbackFactory类，定义FallbackFactory接口的实现
- 在配置文件application.yml中添加如下配置，启动feign方式调用时的服务中断处理机制。同时在controller层调用RemoteOtherService 服务的接口。
feign:
hystrix: #hystrix 含义是熔断（就相当于服务停止了）或降级
enabled: true #默认值为false
@Autowired
private RemoteProviderService remoteProviderService;
2、实现fallback方法
不同点
- 在Feign访问接口中应用FallbackFactory对象：fallback = ProviderFallback.class
- 写ProviderFallback类实现自己写的Feign访问接口（不同点）
@FeignClient 中 fallbackFactory与fallback方法不能同时使用，这个两个方法其实都类似于Hystrix（类似于断容器）的功能，当网络不通时返回默认的配置数据。
Ribbon和Feign调用服务的区别
-
调用方式同：Ribbon需要我们自己构建Http请求，模拟Http请求然后通过RestTemplate并添加@LoadBalanced 发给其他服务，步骤相当繁琐。
-
而Feign则是在Ribbon的基础上进行了一次改进，采用接口的形式，将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，不过要注意，调用方法要和本地抽象方法的签名完全一致。
网关
概述
什么是网关?
网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。
网关的作用是什么？
统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等
常用网关框架有哪些？
Nginx、Zuul、Gateway
网关与过滤器有什么区别？
网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。
Zuul
什么是Spring Cloud Zuul（服务网关）
Zuul是对SpringCloud提供的成熟对的路由方案，他会根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。
三个重要概念：动态路由表，路由定位，反向代理：
- 动态路由表：Zuul支持Eureka路由，手动配置路由，这俩种都支持自动更新
- 路由定位：根据请求路径，Zuul有自己的一套定位服务规则以及路由表达式匹配
- 反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在给客户端
它可以和Eureka，Ribbon，Hystrix等组件配合使用。
Zuul的应用场景：
对外暴露，权限校验，服务聚合，日志审计等
Zuul与Nginx有什么区别？
Zuul是java语言实现的，主要为java服务提供网关服务，尤其在微服务架构中可以更加灵活的对网关进行操作。Nginx是使用C语言实现，性能高于Zuul，但是实现自定义操作需要熟悉lua语言，对程序员要求较高，可以使用Nginx做Zuul集群。
既然Nginx可以实现网关？为什么还需要使用Zuul框架
Zuul是SpringCloud集成的网关，使用Java语言编写，可以对SpringCloud架构提供更灵活的服务。
如何设计一套API接口？
考虑到API接口的分类可以将API接口分为开发API接口和内网API接口，内网API接口用于局域网，为内部服务器提供服务。开放API接口用于对外部合作单位提供接口调用，需要遵循Oauth2.0权限认证协议。同时还需要考虑安全性、幂等性等问题。
ZuulFilter常用有那些方法
- Run()：过滤器的具体业务逻辑
- shouldFilter()：判断过滤器是否有效
- filterOrder()：过滤器执行顺序
- filterType()：过滤器拦截位置
如何实现动态Zuul网关路由转发
通过path配置拦截请求，通过ServiceId到配置中心获取转发的服务列表，Zuul内部使用Ribbon实现本地负载均衡和转发。
Gateway
什么是Spring Cloud Gateway?
-
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。
-
使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。
熔断、限流
服务器问题
谈谈服务雪崩效应
雪崩效应是在大型互联网项目中，当某个服务发生宕机时，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃。
发生雪崩效应的原因有以下几点：
- 单个服务的代码存在bug
- 请求访问量激增导致服务发生崩溃(如大型商城的枪红包，秒杀功能)
- 服务器的硬件故障也会导致部分服务不可用
在微服务中，如何保护服务?
一般使用使用限流框架，实现服务隔离来避免出现服务的雪崩效应，从而达到保护服务的效果。当微服务中，高并发的数据库访问量导致服务线程阻塞，使单个服务宕机，服务的不可用会蔓延到其他服务，引起整体服务灾难性后果，使用服务降级能有效为不同的服务分配资源,一旦服务不可用则返回友好提示，不占用其他服务资源，从而避免单个服务崩溃引发整体服务的不可用。
服务雪崩效应产生的原因？
因为Tomcat默认情况下只有一个线程池来维护客户端发送的所有的请求，这时候某一接口在某一时刻被大量访问就会占据tomcat线程池中的所有线程，其他请求处于等待状态，无法连接到服务接口。
Hystrix
什么是断路器？
在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）
断路器有三种状态：
- 打开状态：一段时间内 达到一定的次数无法调用，并且多次监测没有恢复的迹象，断路器完全打开 那么下次请求就不会请求到该服务。
- 半开状态：短时间内有恢复迹象，断路器会将部分请求发给该服务，正常调用时断路器关闭。
- 关闭状态：当服务一直处于正常状态能正常调用。
什么是 Hystrix？
在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪
崩，Hystrix就是这样的一个工具，防雪崩利器，它具有服务降级，服务熔断，服务隔离，监控等
一些防止雪崩的技术。
Hystrix有四种防雪崩方式:
- 服务降级：接口调用失败就调用本地的方法返回一个空；
- 服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息；
- 服务隔离：隔离服务之间相互影响；
- 服务监控：在服务发生调用时，会将每秒请求数、成功请求数等运行指标记录下来。
谈谈服务降级、熔断、服务隔离？
-
服务降级：当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返回一个友好的提示给客户端。
-
服务熔断是在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量达到设定值（requestVolumeThreshold）或当前的请求错误率达到设定的错误率阈值（errorThresholdPercentage）时开启断路，之后的请求直接走fallback方法，在设定时间（sleepWindowInMilliseconds）后尝试恢复。
-
服务隔离就是Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。
服务降级底层是如何实现的？
Hystrix实现服务降级的功能是通过重写HystrixCommand中的getFallback()方法，当Hystrix的 run方法或construct执行发生错误时转而执行getFallback()方法。
Sentinel
Sentinel核心分为两个部分:
核心库（Java 客户端）：能够运行于所有 Java 运行时环境，同时对Dubbo /Spring Cloud 等框架也有较好的支持。
控制台（Dashboard）：基于 Spring Boot 开发，打包后可以直接运行。
Spring Cloud Security
安全工具包：
- 对Zuul代理中的负载均衡从前端到后端服务中获取SSO令牌
- 资源服务器之间的中继令牌
- 使Feign客户端表现得像 OAuth2RestTemplate （获取令牌等）的拦截器
- 在Zuul代理中配置下游身份验证
Spring Cloud Security提供了一组原语，用于构建安全的应用程序和服务，而且操作简便。可以在外部（或集中）进行大量配置的声明性模型有助于实现大型协作的远程组件系统，通常具有中央身份管理服务。它也非常易于在Cloud Foundry等服务平台中使用。
在Spring Boot和SpringSecurity OAuth2的基础上，可以快速创建实现常见模式的系统，如单点登录，令牌中继和令牌交
换。
Spring Cloud Bus
什么是 Spring Cloud Bus？
- Spring Cloud Bus就像一个分布式执行器，用于扩展的Spring Boot应用程序的配置文件，但也可以用作应用程序之间的通信通道。
- Spring Cloud Bus 不能单独完成通信，需要配合MQ支持。
- Spring Cloud Bus一般是配合Spring Cloud Config做配置中心的。
- Springcloud config实时刷新也必须采用SpringCloud Bus消息总线。
微服务架构
- 单体架构你觉得存在什么缺陷？（容量、计算、故障）
- 为什么要使用分布式架构？(增加容量、高并发、高性能、高可用)
- 分布式架构有什么劣势？(设计的难度、维护成本)
- 为什么要使用缓存？(减少数据库访问压力、提高性能)
- 使用缓存时要注意什么问题？(一致性、淘汰算法、击穿、雪崩)
- 如何理解反向代理？(服务端代理，是服务端服务器的一种代理机制，请求转发)
- 反向代理如何实现负载均衡？(轮询，轮询+权重，哈希IP)
- 什么是读写分离、读写分离的目的是什么？(单机数据库有瓶颈、读写频次，并发能力)
读写分离后可能会带来什么问题？（数据同步） - 当我们向写库写数据时还要做什么？(写缓存、数据同步到读库)
- 为什么要进行分库、分表，有哪些分表策略？(业务数据可靠性、查询性能)
- 何为服务，有什么是微服务？(服务-软件要解决的问题，可以提供的功能。微服务-服务中的共性再抽象，以实现更好的重用)
- 哪种互联网架构设计最好？(没有最好，只有更好，脱离业务谈就够就是耍流氓)
服务注册与调用
-
为什么要将服务注册到nacos?(为了更好的查找这些服务)
-
在Nacos中服务提供者是如何向Nacos注册中心(Registry)续约的？(5秒心跳)
-
对于Nacos服务来讲它是如何判定服务实例的状态？(检测心跳包，15,30)
-
服务启动时如何找到服务启动注册配置类?(NacosNamingService)
-
服务消费方是如何调用服务提供方的服务的？(RestTemplate)
服务的负载均衡
-
@Bean注解的作用?(一般用于配置类内部,描述相关方法,用于告诉spring此方法的返回值要交给spring管理,bean的名字默认为方法名,假如需要指定名字可以@Bean(“bean的名字”),最多的应用场景是整合第三方的资源-对象)
-
@Autowired注解的作用?(此注解用于描述属性,构造方法,set方法等,用于告诉spring框架,按找一定的规则为属性进行DI操作,默认按属性,方法参数类型查找对应的对象,假如只找到一个,则直接注入,类型多个时还会按照属性名或方法参数名进行值的注入,假如名字也不同,就出报错.)
-
Nacos中的负责均衡底层是如何实现的?(通过Ribbon实现,Ribbon中定义了一些负载均衡算法,然后基于这些算法从服务实例中获取一个实例为消费方法提供服务)
-
Ribbon 是什么？(Netflix公司提供的负载均衡客户端,一般应用于服务的消费方法)
-
Ribbon 可以解决什么问题? (基于负载均衡策略进行服务调用, 所有策略都会实现IRule接口)
-
Ribbon 内置的负载策略都有哪些?(8种,可以通过查看IRule接口的实现类进行分析)
-
@LoadBalanced的作用是什么？(描述RestTemplate对象,用于告诉Spring框架，在使用RestTempalte进行服务调用时，这个调用过程会被一个拦截器进行拦截,然后在拦截器内部,启动负载均衡策略。)
-
我们可以自己定义负载均衡策略吗？(可以，基于IRule接口进行策略定义,也可以参考NacosRule进行实现)
Nacos
Nacos是什么，提供了什么特性
- (服务的注册、发现、配置)？
你为什么会选择Nacos?
-
（活跃度、稳定、性能、学习成本）
-
Nacos的官网？(nacos.io)
-
Nacos在github的源码？(github.com/alibaba/nacos)
-
Nacos在windows环境下安装?(解压即可使用)
-
Nacos在windows中的的初步配置？(application.properties访问数据库的数据源)
-
Nacos服务注册的基本过程？（服务启动时发送web请求）
-
Nacos服务消费的基本过程？（服务启动时获取服务实例，然后调用服务）
-
Nacos服务负载均衡逻辑及设计实现？(Ribbon)
-
注册中心的核心数据是什么？（服务的名字和它对应的网络地址）
-
注册中心中心核心数据的存取为什么会采用读写锁?(底层安全和性能)
-
Nacos健康检查的方式？(基于心跳包机制进行实现)
-
Nacos是如何保证高可用的?(重试，本地缓存、集群)
-
Feign是什么，它的应用是怎样的，feign应用过程中的代理对象是如何创建的（JDK）？
-
Feign方式的调用过程，其负载均衡是如何实现？(Ribbon)
配置中心
-
什么是配置中心？（存储项目配置信息的一个服务）
-
为什么要使用配置中心？(集中管理配置信息，动态发布配置信息)
-
市场上有哪些主流的配置中心？(Apollo，nacos，……)
-
配置中心一般都会配置什么内容？(可能会经常变化的配置信息，例如连接池，日志、线程池、限流熔断规则)
-
什么信息一般不会写到配置中心?(服务端口，服务名，服务的注册地址，配置中心)
-
项目中为什么要定义bootstrap.yml文件？(此文件被读取的优先级比较高，可以在服务启动时读取配置中心的数据)
-
Nacos配置中心宕机了，我们的服务还可以读取到配置信息吗？(可以从内存,客户端获取了配置中心的配置信息以后,会将配置信息在本地内存中存储一份。)
-
微服务应用中我们的客户端如何获取配置中心的信息?(我们的服务一般首先会从内存读取配置信息，同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息)
-
微服务应用中客户端如何感知配置中心数据变化？(当数据发生变化时，nacos找到它维护的客户端，然后通知客户端去获取更新的数据，客户端获取数据以后更新本地内存，并在下次访问资源时，刷新@Value注解描述的属性值，但是需要借助@RefreshScope注解对属性所在的类进行描述)
-
服务启动后没有从配置中心获取我们的配置数据是什么原因?(依赖,配置文件名字bootstrap.yml，配置中心的dataId名字是否正确，分组是否正确，配置的名字是否正确，缩进关系是否正确，假如是动态发布，类上是否有@RefreshScope注解)
-
你项目中使用的日志规范是什么?(SLF4J)
-
你了解项目中的日志级别吗?(debug,info,error,…,可以基于日志级别控制日志的输出)
-
Nacos配置管理模型的背景？(环境不同配置不同)
-
Nacos配置中的管理模型是怎样的？（namespace,group,service/data-id）
-
Nacos客户端(微服务)是否可以读取共享配置?(可以)
-
配置中心的选型。(市场活跃度、稳定性、性能、易用)
-
Nacos配置中心基本应用。(新建，修改、删除配置以后，在Nacos客户端应用配置)
-
配置管理模型应用。(namespace,group,service/dataId)
-
Nacos配置变更的动态感知。(底层原理分析)
-
为什么需要配置中心？(动态管理发布配置，无需重启服务，更好保证服务的可用)
-
配置中一般要配置什么内容？(经常变化的配置数据-日志级别，线程池、连接池、…)
-
市面上有哪些主流配置中心？(Nacos,….)
-
配置中心选型时要重点考虑哪些因素？(市场活跃度、稳定性、性能、易用)
-
Nacos客户端(微服务业务)如何动态感知配置中心数据变化的？(nacos2.0之前nacos客户端采用长轮询机制每隔30秒拉取nacos配置信息.)
-
Nacos配置管理模型是怎样的？（命名空间-namespace,分组-group,服务实例-dataId）
Sentinel
-
Sentinel是什么？(阿里推出一个流量控制平台，防卫兵)
-
类似Sentinel的产品你知道有什么？(hystrix-一代微服务产品)
-
你了解哪些限流算法？(计数器、令牌桶、漏斗算法，滑动窗口算法，…)
-
Sentinel 默认的限流算法是什么？(滑动窗口算法)
-
你了解sentinel中的阈值应用类型吗?（两种-QPS,线程数）
-
Sentinel 限流规则中默认有哪些限流模式?(直连，关联，链路)
-
Sentinel的限流效果有哪些？(快速失败，预热，排队)
-
Sentinel 为什么可以对我们的业务进行限流，原理是什么？
小节面试分析
-
何为降级熔断？（让外部应用停止对服务的访问，生活中跳闸，路障设置-此路不通）
-
为什么要进行熔断呢？(平均响应速度越来越慢或经常出现异常，这样可能会导致调用链堆积，最终系统崩溃)
-
Sentinel中限流，降级的异常父类是谁？(BlockException)
-
Sentinel 出现降级熔断时，系统底层抛出的异常是谁？(DegradeException)
-
Sentinel中异常处理接口是谁？（BlockExceptionHandler）
-
Sentinel中异常处理接口下默认的实现类为? (DefaultBlockExceptionHandler)
-
假如Sentinel中默认的异常处理规则不满足我们的需求怎么办?(自己定义)
-
我们如何自己定义Sentinel中异常处理呢？（直接或间接实现BlockExceptionHandler ）
Sent -
Sentinel 降级熔断策略有哪些？（慢调用，异常比例，异常数）
-
Sentinel 熔断处理逻辑中的有哪些状态？(Open，HalfOpen,Closed)
-
Sentinel 对服务调用进行熔断以后处于什么状态？(熔断打开状态-Open)
-
Sentinel 设置的熔断时长到期以后，Sentinel的熔断会处于什么状态？(探测-HalfOpen,假如再次访问时依旧响应时间比较长或依旧有异常，则继续熔断)
-
Sentinel 中的熔断逻辑恢复正常调用以后，会出现什么状态?(熔断关闭-closed)
-
如何理解热点数据？(访问频度比较高的数据，某些商品、谋篇文章、某个视频)
-
热点数据的限流规则是怎样的?(主要是针对参数进行限流设计)
-
热点数据中的特殊参数如何理解？(热点限流中的某个参数值的阈值设计)
-
对于热点数据的访问出现限流以后底层异常是什么？(ParamFlowException)
-
如何理解sentinel中的系统规则？(是对所有链路的控制规则,是一种系统保护策略)
-
Sentinel的常用系统规则有哪些？(RT,QPS,CPU,线程,Load-linux,unix)
Sentinel系统保护规则被触发以后底层会抛出什么异常？（SystemBlockException） -
如何理解Sentinel中的授权规则？(对指定资源的访问给出的一种简易的授权策略)
-
Sentinel的授权规则是如何设计的？(白名单和黑名单)
-
如何理解Sentinel中的白名单？（允许访问的资源名单）
-
如何理解Sentinel中的黑名单？（不允许访问的资源名单）
-
Sentinel如何识别白名单和黑名单？(在拦截器中通过调用RequestOriginParser对象的方法检测具体的规则)
-
授权规则中RequestOriginParser类的做用是什么？（对流控应用值进行解析，检查服务访问时传入的值是否与RequestOriginParser的parseOrigin方法返回值是否相同。）
总之，Sentinel可为秒杀、抢购、抢票、拉票等高并发应用，提供API接口层面的流量限制，让突然暴涨而来的流量用户访问受到统一的管控，使用合理的流量放行规则使得用户都能正常得到服务。
-
Sentinel诞生的背景?(计算机的数量是否有限,处理能力是否有限,并发比较大或突发流量比较大)
-
服务中Sentinel环境的集成,初始化?(添加依赖-两个,sentinel配置)
-
Sentinel 的限流规则?(阈值类型-QPS&线程数,限流模式-直接,关联,链路)
-
Sentinel 的降级(熔断)策略?(慢调用,异常比例,异常数)
-
Sentinel 的热点规则设计(掌握)?
-
Sentinel 系统规则设计?(了解,全局规则定义,针对所有请求有效)
-
Sentinel 授权规则设计?(掌握,黑白名单)
-
为什么要限流?
-
你了解的那些限流框架?(sentinel)
-
常用的限流算法有那些?(计数,令牌桶-电影票,漏桶-漏斗,滑动窗口)
-
Sentinel有哪些限流规则?(QPS,线程数)
-
Sentinel有哪些限流模式?(直接,关联-创建订单和查询订单,链路限流-北京六环外不限号,但是五环就限号)
-
Sentinel 的降级(熔断)策略有哪些?(慢调用-响应时长,异常比例-异常占比,异常数)
-
Sentinel 的热点规则中的热点数据?(热卖商品,微博大咖,新上映的电影)
-
如何理解Sentinel 授权规则中的黑白名单?
RabbitMQ
RabbitMQ 的使用场景有哪些？
- 抢购活动，削峰填谷，防止系统崩塌。
- 延迟信息处理，比如 10 分钟之后给下单未付款的用户发送邮件提醒。
- 解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，
- 新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。
RabbitMQ 有哪些重要的角色？
RabbitMQ 中重要的角色有：生产者、消费者和代理：
- 生产者：消息的创建者，负责创建和推送数据到消息服务器；
- 消费者：消息的接收方，用于处理数据和确认消息；
- 代理：就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。
RabbitMQ 有哪些重要的组件？
- ConnectionFactory（连接管理器）：应用程序与 Rabbit 之间建立连接的管理器，程序代码中使用。
- Channel（信道）：消息推送使用的通道。
- Exchange（交换器）：用于接受、分配消息。
- Queue（队列）：用于存储生产者的消息。
- RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
- BindingKey（绑定键）：用于把交换器的消息绑定到队列上。
RabbitMQ 中 vhost 的作用是什么？
vhost：每个 RabbitMQ 都能创建很多 vhost，我们称之为虚拟主机，每个虚拟主机其实都是 mini 版的 RabbitMQ，它拥有自己的队列，交换器和绑定，拥有自己的权限机制。
RabbitMQ 的消息是怎么发送的？
- 首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息，客户端和 rabbit server 之间会创建一个 tcp 连接；
- 一旦 tcp 打开并通过了认证（认证就是你发送给rabbit 服务器的用户名和密码），你的客户端和 RabbitMQ 就创建了一条 amqp 信道（channel），信道是创建在“真实” tcp 上的虚拟连接，amqp 命令都是通过信道发送出去的，每个信道都会有一个唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。
RabbitMQ 怎么保证消息的稳定性？
- 提供了事务的功能。
- 通过将 channel 设置为 confirm（确认）模式。
RabbitMQ 怎么避免消息丢失？
- 把消息持久化磁盘，保证服务器重启消息不丢失。
- 每个集群中至少有一个物理磁盘，保证消息落入磁盘。
要保证消息持久化成功的条件有哪些？
- 声明队列必须设置持久化 durable 设置为 true.
- 消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。
- 消息已经到达持久化交换器。
- 消息已经到达持久化队列。
以上四个条件都满足才能保证消息持久化成功。
RabbitMQ 持久化有什么缺点？
持久化的缺地就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低
了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。
RabbitMQ 有几种广播类型？
-
direct（默认方式）：最基础最简单的模式，发送方把消息发送给订阅方，如果有多个订阅者，默认采取轮询的方式进行消息发送。
-
headers：与 direct 类似，只是性能很差，此类型几乎用不到。
-
fanout：分发模式，把消费分发给所有订阅者。
-
topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收到。
RabbitMQ 怎么实现延迟消息队列？
延迟队列的实现有两种方式：
- 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
- 使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。
RabbitMQ 集群有什么用？
集群主要有以下两个用途：
- 高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
- 高容量：集群可以承载更多的消息量。
RabbitMQ 节点的类型有哪些？
- 磁盘节点：消息会存储到磁盘。
- 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。
RabbitMQ 集群搭建需要注意哪些问题？
- 各节点之间使用“–link”连接，此属性不能忽略。
- 各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。
- 整个集群中必须包含一个磁盘节点。
RabbitMQ 每个节点是其他节点的完整拷贝吗？为什么？
不是，原因有以下两个：
- 存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；
- 性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。
RabbitMQ 集群中唯一一个磁盘节点崩溃了会发生什么情况？
如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：
- 不能创建队列
- 不能创建交换器
- 不能创建绑定
- 不能添加用户
- 不能更改权限
- 不能添加和删除集群节点
唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。
RabbitMQ 对集群节点停止顺序有要求吗？
RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。