Java面试题——Spring

1.Spring

 

Spring是一个IOC容器，用来管理Bean，使用依赖注入实现控制反转，可以很方便的整合各种框架，提供AOP机制弥补面向对象编程的代码重复问题，更方便将同类不同方法中的共同处理抽取成切面自动注入给方法执行

1.AOP

1.AOP面向切面编程，是对面向对象编程的一种补充

不改变源码的情况对源码的方法进行增强

它是使用动态代理实现的，在内存中临时为增强某个方法生成一个AOP对象，这个对象包含目标的所有方法，在特定的切入点做了增强处理，并回调原来的方法

动态代理的特点：随用随创建，随用随加载

动态代理的两种实现方式

JDK动态代理（基于接口）

通过反射来接收被代理的类，但是被代理的类必须实现接口，核心是InvocationHandler和Proxy类

CGLIB动态代理（基于子类，继承方法实现）

CGLIB动态代理的类一般是没有实现接口的类，CGLIB是一个代码生成的类库，可以在运行时动态生成某个类的子类，所以CGLIB时通过继承的方式做的动态代理，因此如果某个类被标记为final，那么他是无法使用CGLIB做动态代理的

2.AOP能做什么

1.降低模块之间的耦合度

2.使系统容易扩展

3.避免修改业务代码，避免了引入重复代码，更好的代码复用

耦合：代码书写过程中所使用技术的结合紧密度，用于衡量软件中各个模块之间的互联程度

内聚：代码书写过程中单个模块内各部分间的联系，用于衡量软件中各个功能模块内部的功能联系

3.AOP怎么用

前置通知（增强）：某方法调用之前发出的通知

后置通知（增强）：某方法调用之后发出的通知

返回后通知（相当于finally）：方法正常返回后，调用通知，在方法调用后，正常退出发出通知

异常通知（相当于catch）：抛出异常后通知

环绕通知：通知包裹在被通知的方法周围，相当于前置+后置

应用场景：日志处理，事务

2.IOC和DI

IOC（容器）：控制反转           DI（行为）：依赖注入

依赖注入指IOC容器中的资源进入应用程序的方式，注入这一行为（依赖注入的方式）分为注解注入，自动装配注入，构造方法注入，set注入

IOC实现了无需修改源码，解耦，将修改的地方放进配置文件

IOC和DI是相辅相成的，都是为解耦而服务的，实现了由主动变被动，由自己创建对象到等Spring给

无IOC时修改实现就需要修改实现类中的代码，引入工厂模式以后，把实现类都放在工厂里由工厂调用，service调用工厂的方法，这时只需要修改工厂的方法，但还是需要修改源码，之后在工厂和实现类之间加入配置文件，工厂利用配置文件加反射把信息读取过来，这时只需要修改配置文件而不用修改源码

SpringIOC：Spring反向控制应用程序所需要使用的外部资源

IOC容器：Spring控制的资源全部放在Spring的容器中，即为IOC容器

3.Spring bean的生命周期

1. 实例化 Instantiation
2. 属性赋值 Populate
3. 初始化 Initialization
4. 销毁 Destruction

实例化 -> 属性赋值 -> 初始化 -> 销毁

4.Spring Bean的作用域

Spring 容器在初始化一个 Bean 的实例时，同时会指定该实例的作用域。Spring3 为 Bean 定义了五种作用域，具体如下。

1）singleton

单例模式，使用 singleton 定义的 Bean 在 Spring 容器中只有一个实例，这也是 Bean 默认的作用域。

2）prototype

原型模式，每次通过 Spring 容器获取 prototype 定义的 Bean 时，容器都将创建一个新的 Bean 实例。

3）request

在一次 HTTP 请求中，容器会返回该 Bean 的同一个实例。而对不同的 HTTP 请求，会返回不同的实例，该作用域仅在当前 HTTP Request 内有效。

4）session

在一次 HTTP Session 中，容器会返回该 Bean 的同一个实例。而对不同的 HTTP 请求，会返回不同的实例，该作用域仅在当前 HTTP Session 内有效。

5）global Session

在一个全局的 HTTP Session 中，容器会返回该 Bean 的同一个实例。该作用域仅在使用 portlet context 时有效。

在上述五种作用域中，singleton 和 prototype 是最常用的两种

5.相关注解

1、给容器中注入组件
（1）包扫描+组件标注注解

@Component：泛指各种组件

@Controller、@Service、@Repository都可以称为@Component。

@Controller：控制层

@Service：业务层

@Repository：数据访问层

（2）@Bean

导入第三方包里面的注解

（3）@Import

@Import(要导入到容器中的组件)；

2、注入bean的注解
@Autowired：由bean提供，根据数据类型匹配Spring核心容器对象

@Autowired可以作用在变量、setter方法、构造函数上；
有个属性为required，可以配置为false；
@Inject：由JSR-330提供

@Inject用法和@Autowired一样。
@Resource：由JSR-250提供

@Autowired、@Inject是默认按照类型匹配的，@Resource是按照名称匹配的，@Autowired如果需要按照名称匹配需要和@Qualifier一起使用，@Inject和@Name一起使用。

@Primary

让spring进行自动装配的时候，默认使用首选的bean，和@Qualifier一个效果。

6.事务的隔离界别

如果不考虑事务的隔离性，则会引发一些安全问题

脏读：一个事务读到了另一个事务还未提交的数据

不可重复读：一个事务读到了另一个事务已经提交的update的数据，导致在当前的事务中多次查询结果不一致

幻读/虚读：一个事务读到了另一个事务已经提交的insert的数据，导致在当前的事务中多次查询结果不一致

read uncommitted 读未提交 三个问题全可能发生

read committed 读已提交 避免脏读，不可重复读和幻读会发生，大部分数据库采取这种隔离级别

repeatable read 可重复读 避免脏读，不可重复读，幻读会发生，mysql数据库采取这种隔离级别

serializable 串行化的 避免三个问题

隔离级别越高，越安全，但是效率越低

Spring的事务机制包括声明式事务和编程式事务

编程式事务就是自己写Try catch语句调用commit\rollback等函数来实现那段业务数据改变的事务性。 声明式事务:是通过框架和事务定义配置给自己的业务代码添加事务性，比如Spring里面的AOP。 前者需要自己写大量重复的事务控制代码，后者通过设置可以一次性给所有的业务方法添加上事务特性,@Transaction注解的方式。

2.SpringMVC

SpringMVC是Spring对Web框架的一个解决方案，提供了一个总的前端控制器Servlet，用于接收请求，然后定义了一套路由策略（url到handler的映射）及适配执行handler，将handler处理结果使用视图解析技术展现给前端

1.Spring前端控制器以及三大组件

三大组件：处理器映射器、处理器适配器、视图解析器

前端控制器DispatcherServlet：前端控制器是整个流程控制的中心，由他接收和处理用户的请求，以及调用其他组件，前端控制器的存在降低了组件之间的耦合性，ss前端控制器是必须在web.xml配置的，但springboot继承ss时无需配置前端控制器

处理器Handler：Handler就是实际开发中写的Controller，他是继前端控制器的后端控制器，在前端控制器的控制下Handler对具体的用户请求进行处理

处理器映射器HandlerMapping：处理器映射器负责根据用户请求找到Handler，SpringMVC提供了不用的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等

处理器适配器HandlerAdapter：通过处理器适配器戳处理器进行执行，这是适配器模式的应用

视图解析器ViewResolver：负责将处理结果生成View视图

2.SpringMVC的执行流程

1.用户发送请求之后，请求被前端控制器DispatcherServlet捕获

2.前端控制器对请求URL进行解析，得到请求资源标识符（URI）然后根据该URI调用处理器映射器HandlerMapping，获得该Handler配置的所有相关的对象（包括Handler对象以及Handler对象对象对应的拦截器），最后以HandlerExecutionChain对象的形式返回

3.前端控制器根据获得的Handler选择一个合适的处理器适配器HandlerAdapter

4.提取Request中的模型数据，填充处理器Handler入参，开始执行Handler（也就是我们自己写的Controller），在填充Handler的入参过程中，也就是为形参赋值的过程，根据你的配置，Spring将帮你做一些额外的工作：

（1）HttpMessageConveter：将请求消息（如Json，xml等数据）转换成一个对象，将对象转换为指定的响应信息

（2）数据转换：对请求消息进行数据转换，如String转Integer，Double等

（3）数据格式化：对请求消息进行数据格式化，如将字符串转换成格式化数字或格式化日期等

（4）数据验证

5.Handler执行完毕后，向前端控制器返回一个ModelAndView对象

6.根据返回的ModelAndView，选择一个合适的视图解析器ViewResolver返回给前端控制器Dispatcherservlet

7.视图解析器结合Model和View来渲染视图

8.将渲染的结果返回给客户端

3.SpringMVC的优点

1.它是基于组件技术的全部的应用对象，无论控制器和视图还是业务对象之类的都是java组件（@Component）并且和Spring提供的其他基础结构紧密集成

2.不依赖于Servlet API（目标虽是如此，但是在实现的时候确实是依赖于Servlet的）

3.可以任意使用各种视图技术

4.支持各种请求资源的映射策略

5.易于扩展

4.Spring以及SpringMVC的常用注解

@Component：用于标记在一个类上，表示当前类是Spring的一个组件，会进入IOC容器，他有三个衍生注解，如下

@Controller：用于标记在一个类上，代表这个类是控制层组件

@Service：用于标记在一个类上，代表这个类是业务层组件

@Requesitory：用于标记在一个类上，代表这个类是数据访问层组件

@RequestMapping：是用来处理请求地址映射的注解，可用于类或方法上，用于类上表示类中的所有相应请求的方法都是以该地址作为父路径

@RequestParam：用于将指定的请求参数赋值给方法中的形式参数（形参重命名）

@PathVariable：请求头路径URL

@RequestBody：请求体内容

@ResponseBody：用于将Controller的方法返回的对象，用流相应给客户端

@RestController：@Controller+@ResponseBody

@Transactional：写在类上用于指定当前类中的方法支持事务

3.SpringBoot

SpringBoot（脚手架）是Spring提供的一个快速开发工具包让程序员能更方便、更快速的开发Spring+SpringMVC的应用，简化了配置，整合了一系列的解决方案，如redis，es等都可以开箱即用，约定大于配置

1.SpringBoot自动装配原理

1.什么是springboot自动装配？
自动装配是springboot的核心，一般提到自动装配就会和springboot联系在一起。实际上 Spring Framework 早就实现了这个功能。Spring Boot 只是在其基础上，通过 SPI 的方式，做了进一步优化。

SpringBoot 定义了一套接口规范，这套规范规定：SpringBoot 在启动时会扫描外部引用 jar 包中的META-INF/spring.factories文件，将文件中配置的类型信息加载到 Spring 容器（此处涉及到 JVM 类加载机制与 Spring 的容器知识），并执行类中定义的各种操作。对于外部 jar 来说，只需要按照 SpringBoot 定义的标准，就能将自己的功能装置进 SpringBoot。

2.springboot是如何实现自动装配的？

转http://t.csdn.cn/U5y1X

2.Spring Boot 的配置文件有哪几种格式？它们有什么区别？

.properties 和 .yml，它们的区别主要是书写格式不同。

3.Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

启动类上面的注解是@SpringBootApplication，它也是 Spring Boot 的核心注解，主要组合包含了以下 3 个注解：
@SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。
@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源自动配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。
@ComponentScan：Spring组件包名扫描。

4.SpringBoot 常用注解

1.@RestController 和 @RequestMapping 注解
2.@SpringBootApplication
3.@ResponseBody @RequestParam
4.@AutoWired
5.@PathVariable

4.SpringCloud

Spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。

1.分布式CAP理论和BASE理论

CAP：Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性

分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能2选1（CP和AP）

BASE：Basically Available 基本可用、soft state 软状态、Eventually consistent 最终一致性

此理论是对CAP中一致性和可用性权衡的结果

核心思想：即使无法做到强一致性，但每个应用都可以根绝自身业务特点，采用适当的方式来使系统达到最终一致性

基本可用：相应时间上的损失、系统功能上的损失

软状态：数据同步允许一定的延迟，可能没那么准

最终一致性：在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时同步

2.Dubbo的整体架构设计及分层

五个角色

注册中心registry：服务的注册与发现

服务提供者provider：暴露服务

服务消费者consumer：调用远程服务

监控中心monitor：统计服务的调用次数和调用时间

容器container：服务允许容器，启动时加载provider

调用流程

1.导出：容器container负责启动、加载、运行服务提供者provider

2.注册：服务提供者provider在启动时，向注册中心registry注册自己提供的服务

3.订阅：服务消费者consumer在启动时，向注册中心registry订阅自己所需的服务

4.发现：注册中心registry返回服务提供者列表给服务消费者consumer，如果有变更，注册中心将基于长连接推送变更数据给服务消费者

5.调用：服务消费者consumer调用服务提供者provider的服务，基于负载均衡算法进行调用

6.监控：服务消费者consumer调用服务提供者provider的统计，基于短链接定时每分钟一次统计到监控中心monitor

3.SpringCloud和Dubbo的区别

底层协议：SpringCloud基于http协议，Dubbo基于tcp协议，决定了Dubbo的性能会比较好，在小型轻量服务时可以选择使用Dubbo

注册中心：SpringCloud使用eureka/nacos，Dubbo推荐使用zookeeper

模型定义：SpringCloud将一个应用定义为一个服务，dubbo将一个接口定义为一个服务

CAP：SpringCloud AP高可用，Dubbo CP强一致

功能定位：SpringCloud提供了微服务整套的解决方案，Dubbo只解决了服务治理、服务调用一个环节，未能解决熔断、降级等

4.zookeeper分布式锁

分布式锁可以理解为锁集群的，解决单机锁锁不住别的节点的问题

1.每个节点都创建一个节点下的临时节点，然后对所有临时节点进行排序

2.如果自己不是第一个节点，就对自己上一个节点加监听器

3.只要上一个节点释放锁自己就拿到锁，相当于一个排队机制

使用临时节点可以保证服务宕机了，zk自动删除节点，释放锁，取消排队

5.MySql分布式锁

分布式环境中的线程连接同一个数据库，利用数据库中的行锁来达到互斥访问，但性能过低，不建议使用

6.SOA、分布式、微服务之间有什么关系和区别

1.分布式架构是指将单体架构中的各个部分进行拆分，然后部署不同的机器或进程中去，SOA和微服务基本上都是分布式的架构

2.SOA是一种面向服务的架构，系统的所有服务都注册在总线（应用程序）上，当调用微服务时，从总线上查找服务信息（IP、参数等），然后调用

3.微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本保持一个应用对应一个服务的架构

微服务更侧重服务

7.微服务的优缺点

微服务是一种架构风格，通过将大型的单体应用划分为比较小的服务单元，从而降低整个系统的复杂度

优点

1. 服务部署更加灵活，每个应用都可以是一个项目，低耦合

2.技术更新灵活，微服务可以根据业务特点，灵活选择技术栈

3.分开启动部署多台机器，应用性能得到提高

缺点

1.服务调用的复杂性提高了，会导致网络问题、容错问题、负载问题、高并发问题......

2.测试运维难度提升

8.SpringCloud常用组件

1.网关

网关旨在为微服务架构提供一种简单而有效的API路由管理方式

在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能调用n个微服务的接口完成一个用户的请求，其存在的问题：

1.客户端多次请求不同的微服务，增加客户端的复杂性

2.认证复杂，每个服务器都要进行认证

3.http请求不同服务次数增加，性能不高

网关就是系统的入口，封装了应用程序的内部结构，为客户端提供统一的服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、负载均衡、路由转发......

优点

安全 ，只有网关系统对外进行暴露，微服务可以隐藏在内网，通过防火墙保护。
易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。
易于认证。可以在网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
减少了客户端与各个微服务之间的交互次数
易于统一授权。

实现微服务网关的组件

nginx Nginx (tengine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务
zuul ,Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器
spring-cloud-gateway, 是spring 出品的 基于spring 的网关项目，集成断路器，路径重写，性能比Zuul好

1、Zuul和gateway的区别？

• Zuul1.0是阻塞式的api，不支持长连接，而gateway支持异步。
• Zuul没有提供限流、负载均衡等支持，而gateway支持。
• 它们都是web网关，处理http请求，底层都是servlet。

2.注册中心

为什么需要服务注册中心
微服务时代的服务管理
在微服务时代，我们所有的服务都被劲量拆分成最小的粒度，原先所有的服务都在混在1个server里，现在就被按照功能或者对象拆分成N个服务模块，这样做的好处是深度解耦，1个模块只负责自己的事情就好，能够实现快速的迭代更新。坏处就是服务的管理和控制变得异常的复杂和繁琐，人工维护难度变大。还有排查问题和性能变差（服务调用时的网络开销）

什么是注册中心
注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信。注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

原理和功能

注册中心是隐藏在服务框架背后最基础的服务，记录各个服务的实例信息，决定业务服务是否正常调用

 注册中心原理

注册中心主要涉及到三大角色 ：注册中心、服务提供者 、服务消费者

三者关系流程描述如下：

    1、各微服务启动时，将自己的实例信息(ip、端口、服务名等)注册到注册中心，注册中心存储这些数据；

    2、服务消费者从注册中心获取到服务提供者的实例信息，通过ip + 端口 方式远程调用服务提供者的接口；

    3、各个微服务通过心跳来上报注册中心，注册中心以某个时间段有没有接收到上报信息，来决定是否下线某服务实例；

  4、 微服务发生变动时如 增加实例或 ip变动，重新注册信息到注册中心。这样，服务消费者就无需改动，直接从注册中心获取最新信息即可。

注册中心功能

1、服务注册表

服务注册表是注册中心的核心，它用来记录各个微服务实例的信息，例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册与注销。

2、服务注册与发现

服务注册是指微服务在启动时，将自己的信息注册到注册中心的过程服务发现是指查询可用的微服务列表及网络地址的机制。

3、服务检查

注册中心使用一定的机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表移除该实例。

实现微服务注册中心的组件

一个服务的提供者数量和分布是基于业务发展是动态变化的，注册中心需要支持弹性扩容，而这也体现了微服务的分布式属性。主流技术方向选用组件时，主要有 Eureka、Consul、ZooKeeper和Nacos这几种。这几种开源组件 都是基于分布式理论 CAP 的 CP 、AP 来实现的。

Eurake --> AP

Eurake是Netflix公司提供开源的，由Java语言开发，基于Restful Api风格 实现的服务注册和服务发现。不过 Netflix只开源到1.X版本，2.X版本已经关闭，不开放了，于2022下半年闭源

Consul --> CP

Consul是由HashiCorp基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，采用Raft算法保证服务的一致性，且支持健康检查。

采用主从模式的设计，可以大规模的部署集群数据量，集群通过RPC方式来调用。

Zookeeper --> CP

Zookeeper 是Google开源的在Java语言上实现的分布式协调服务，是Hadoop和Hbase的重要组件，提供了数据/发布订阅、负载均衡、分布式同步等功能。Zookeeper 也是主从设计架构，搭建高可扩展的服务集群。

Nacos

是阿里开源软件，支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务发现外，还有可以动态配置。让配置管理变得更加高效和敏捷，无需重启服务。

Nacos致力于解决微服务中的统一配置，服务注册和发现等问题。Nacos集成了注册中心和配置中心

Nacos在特定条件下，会进行AP 、CP的切换。

差异

转http://t.csdn.cn/j1Jnc

转http://t.csdn.cn/8LLYK

1.Eureka与Zookeeper的区别在哪？

zookeeper保证的是CP，在Zookeeper集群中，当发生网络故障导致master节点和slave节点失联时，剩余的slave节点会进行leader选举，而在选举的过程中，zookeeper集群不可用，不能对外提供注册和查询的服务。主从节点数据同步的时候不能对外提供服务。
Eureka保证的是AP，在Eureka集群中，某些节点挂掉，只要有一个Eureka节点存在，就可以对外提供注册和查询服务，但是可能注册信息不是最新的(不保证强一致性)。
2 .Eureka与Nacos的区别？

Nacos既支持AP也支持CP，默认使用AP和Eureka一样。

3.配置中心

为什么要使用 spring cloud config 配置中心：

由于常用的配置管理有很大的缺点，因此 spring cloud 采用了集中式的配置中心来管理每个服务的配置
配置中心，在微服务和分布式系统中，采用服务端和客户端来提供可扩展的配置服务
配置中心负责管理所有的服务的各种环境配置文件，配置服务中心默认采用 Git 的方式存储配置文件，因此我们很容易部署修改，有助于对环境配置进行版本管理
spring cloud config 配置中心，解决了什么问题：

配置中心解决了微服务配置的中心化、版本控制、平台独立、语言独立等问题

特性：

提供服务端和客户端支持
集中式管理分布式环境下的应用配置
基于 Spring 环境，无缝与 Spring 应用集成
可用于任何语言开发的程序
默认实现基于 Git 仓库，可以进行版本管理

实现微服务配置中心的组件

nacos

consul

config

1、Config和Nacos的区别？

• Config大部分集合git使用，配置动态变更需要依赖SpringCloudBus消息总线来通知所有Client变化；并且没有可视化界面。
• Nacos采用长连接，一旦配置变更，会迅速通知Client进行变更，速度较快；提供可视化界面。

4.负载均衡

Ribbon是一个Http和Tcp的客户端负载均衡工具，它可以在客户端配置服务端列表，，它使用RestTemplate模拟客户端请求，过程相对繁琐。
Feign继承了Ribbon，使用接口的方式进行服务调用。

1.负载均衡算法有哪些？
随机、轮询、响应时间权重、重试等，还可以实现IRule接口，自定义负载均衡算法。

2.Ribbon和Feign的区别？

启动类上加的注解不同，Ribbon用的是@RibbonClients；Feign用的是@EnableFeignClients
服务的指定位置不同，Ribbon是在@RibbonClient上指定服务名称；Feign是在接上的@FeignClient上指定。
调用方式不同，Ribbon需要自己构建http请求，模拟http请求，然后使用RestTempate进行调用；Feign采用接口的方式调用。
3.Ribbon原理
先去本地获取从Eureka缓存下来的服务列表，然后使用负载均衡算法选取一个服务，使用HttpClient进行调用。

4.Feign的原理
在配置类上，加上@EnableFeginClients，那么该注解是基于@Import注解，注册有关Fegin的解析注册类，这个类是实现 ImportBeanDefinitionRegistrar 这个接口，重写registryBeanDefinition 方法。他会扫描所有加了@FeginClient 的接口，然后针对这个注解的接口生成动态代理，然后你针对fegin的动态代理去调用他方法的时候，此时会在底层生成http协议格式的请求，使用HttpURLConnection进行调用。

5.Feign和OpenFeign的区别？
OpenFeign在feign的基础上支持了SpringMVC的注解，如@RequestMapping等等，OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

5.服务熔断

转http://t.csdn.cn/lElsx

Hystix是分布式系统的一个延迟和容错的开源库，它可以进行熔断、降级、限流、监控，可以避免分布式系统的级联故障和雪崩效应。

阻止故障的连锁反应，实现熔断

快速失败，实现优雅降级

提供实时的监控和警告

服务熔断：熔断是直接调用降级方法。不调用目标方法，无需等待接口调用超时才返回结果，是为了防止异常扩散，保证系统的稳定性。
服务降级：降级是调用目标方法，由于目标方法调用超时或者异常，才调用降级方法。编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降
使用：服务降级是在消费端和feign一起使用，默认降级的配置不是开启的(feign.hystrix.enabled=false)，服务熔断是在服务端使用，对服务端的controller进行熔断，默认熔断的配置是开启的(spring.cloud.circuit.breaker.enabled=true)。

Hystix和Sentinel的区别？

 资源隔离（Hystix的限流两种方式）

1.线程隔离，Hystix会给每一个command分配一个单独的线程池

2.信号量隔离，客户端向依赖服务发起请求时，首先获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号个数时，后续的请求都会直接拒绝，进入fallback流程，如果技术过多则直接熔断，信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞从而达到限流和防止雪崩的目的‘

限流算法有几种？
计数器、滑动窗口计数器、漏桶法、令牌桶

9.击穿、穿透、雪崩

缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某一时间点被超高并发地访问，是一种非常热点地数据，和雪崩的区别是针对某一key，雪崩是很多key

缓存在某个时间点过期的时候，恰好在这个时间点对这个key有大量的请求过来，这些请求发现过期了就去DB，DB就垮了

解决方法 加锁式队列，可以将失效时间分散，设置随机过期

击穿与雪崩的不同在于缓存key失效的量级上。击穿是对于单个key值的缓存失效过期，雪崩则是大面积key同时失效。

解决办法：

若缓存数据基本不会发生更新，则可尝试将热点数据设置为永不过期。
若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。
若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

缓存穿透

指查询一个缓存和数据库都不存在的数据，导致尽管数据不存在但是每次都会到数据库查询。在访问量大时可能DB就会挂掉。如果有人利用不存在的key频繁攻击，则这就形成了漏洞。

解决方法 布隆过滤器：将所有可能存在的数据存在bigmap中，一定不存在的数据被bigmap拦截

也可以无论存不存在都存入缓存，不存在则设置特别端的过期时间

布隆过滤器：类似于HashSet，可以快速判断一个元素在集合中是否存在，应用场景：快速判断一个元素是否在某容器内，不存在直接返回。（关键点在于hash算法和容器大小。）

缓存雪崩

当服务A调用服务B，服务B调用服务C，此时大量的请求突然请求服务A，假如服务A本身能扛住这些请求，但是如果服务C扛不住，导致C请求堆积，从而服务B请求堆积，从而服务A不可用，即下游服务挂掉或者超时，导致上游调用服务大面积受到影响，阻塞、超时，进而导致雪崩效应。

解决方法 熔断和降级