面试题总结

目录

一、框架

1. 什么是Spring？

2. Spring 的优点？

3. 什么是Bean管理？

4.Spring常用注解

5.Spring的生命周期

5.什么是Spring MVC ？

5.Servlet和JSP的区别联系？

6. Spring MVC的优点:

7. SpringMVC怎么样设定重定向和转发的？

8. forward和redirect的区别？

9. Spring MVC常用的注解有哪些？

10. 什么是Mybatis？

 11.Spring怎么整合Mybatis？

11. Mybaits的优缺点：

12. #{}和${}的区别是什么？

13. 什么是 Spring Boot？

14. 为什么要用SpringBoot？

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

二、数据库

1.MySQL 使用索引的原因？

2.聚集索引和非聚集索引

3.为什么一定要设一个主键？

4. 正确使用索引

5.最左匹配原则

6.索引有几种？

7. 创建了很多索引，怎么知道到底有没有生效？

8.InnoDB使用的B+ 树的索引模型，那么你知道为什么采用B+ 树吗？

9.B+树索引和Hash索引的区别？

10.MySQL数据库优化

11. MySQL大数据量处理常用解决方案

三、Redis缓存技术

1.为什么 Redis 是单线程？

2.Redis 为什么使用单进程、单线程也很快?

3.Redis 在项目中的使用场景?

4.Redis 常见的数据结构?

5.Redis 删除过期键的策略（缓存失效策略、数据过期策略）

6.Redis 的持久化机制有哪几种，各自的实现原理和优缺点？

7.Redis 怎么保证高可用？

小结：

8、redis有哪些集群模式？

9、redis实现分布式锁

四、Nginx

1. 什么是nginx？

2. 为什么要用Nginx？

3.什么是正向代理和反向代理？

4.Nginx应用场景？

5.location指令

6.Nginx如何进行限流？

7.漏桶流算法和令牌桶算法

8.为什么要做动静分离？

9.Nginx负载均衡的算法怎么实现的?策略有哪些?

10.cookie和session的区别？

五、微服务

1.什么是微服务架构

2.SpringCloud的优点？

3.什么是Dubbo？

4.为什么要用Dubbo？

5.Dubbo的使用场景有哪些？

6.Spring Cloud 和Dubbo区别?

7.Dubbo集群容错有几种方案？六种

8.Dubbo使用过程中都遇到了些什么问题？

9.Dubbo用到哪些设计模式？

10.Dubbo核心功能有哪些？

11. Zookeeper是什么？

12.Zookeeper是怎样的一个数据结构？

13.Zookeeper有几种常用的数据格式呢？

14.Zookeeper 怎么保证主从节点的状态同步？

14.Zookeeper有哪些核心的功能呢？

16.在开发中使用Synchronized就可以保证线程安全了，为什么还需要使用zookeeper来实现分布式锁呢？

17.zookeeper的权限控制

18.zookeeper的数据是存储在内存中的吗，怎么进行持久化操作呢？

19.Zookeeper 的典型应用场景

20.说一下 Zookeeper 的通知机制？

21.Zookeeper 和 Dubbo 的关系？

23.Zookeeper和Eueaka的区别

23.RabbitMQ是什么？

24.消息队列的优点？

25.如何保证消息不被重复消费？

26.如何保证消息不丢失，进行可靠性传输？

27.如何保证消息的有序性？

28.如何处理消息堆积情况?

29.如何保证消息队列的高可用？

六、多线程

1.为什么要使用线程池？直接new个线程不是很舒服？

2.线程池的核心属性有哪些？

3.线程池的创建

4.线程池中的各个状态分别代表什么含义？这几个状态之间是怎么流转的？

5.线程池有哪些队列？

6.线程池有哪些拒绝策略？

7. 线程只能在任务到达时才启动吗？

8. Executors 提供了哪些创建线程池的方法？

9.在我们实际使用中，线程池的大小配置多少合适？

10.怎么保证线程安全？

七、设计模式

1.单例模式和多例模式

2.单例模式的适用场景是什么样子的？

3.实现java单例模式的几种模式？

4.饿汉式和懒汉式的区别?

八、Java Web

1、HTTP RestFul 和RPC的区别？什么时候用哪个？

2、怎么选择rpc还是http？

九、文件存储服务组件

1、MinIO和Fast DFS对比？

十、ES

1、Elasticsearch 中的集群、节点、索引、文档、类型是什么？

2、Elasticsearch 中的倒排索引是什么？

十一、Java基础

---

一、框架

1. 什么是Spring？

Spring是一个轻量级的IOC和AOP容器框架。是为Java应用程序提供基础型服务的一套框架，目的是用于简化企业应用程序的开发，这样开发者只需要关心业务需求。主要包括以下七个模块：

Spring Context：提供框架式的Bean访问方式，以及企业级功能（JNDI、定时任务等）；

Spring Core：核心类库，所有功能都依赖于该类库，提供IOC和DI服务

Spring AOP：AOP服务

Spring Web：提供了基本的面向Web的综合特性，提供对常见框架如Struts2的支持，Spring能够管理这些框架，将Spring的资源注入给框架，也能在这些框架的前后插入拦截器；

Spring MVC：提供面向Web应用的Model-View-Controller，即MVC实现。

Spring DAO：对JDBC的抽象封装，简化了数据访问异常的处理，并能统一管理JDBC事务；

Spring ORM：对现有的ORM框架的支持

2. Spring 的优点？

• spring的DI机制将对象之间的依赖关系交由框架处理，减低组件的耦合性。di机制是ioc的体现。

• Spring提供了AOP技术，支持将一些通用任务，如安全、事务、日志、权限等进行集中式管理，从而提供更好的复用。

• Spring对于主流的应用框架提供了集成支持。

3. 什么是Bean管理？

bean管理是指（1）spring创建对象 （2）spring注入属性。当我们在将一个类上标注@Service或者@Controller或@Component或@Repository注解之后，spring的组件扫描就会自动发现它，并且会将其初始化为spring应用上下文中的bean。 当需要使用这个bean的时候，例如加上@Autowired注解的时候，这个bean就会被创建。而且初始化是根据无参构造函数。

@Autowired可以标注在属性上、方法上和构造器上，来完成自动装配。默认是根据属性类型，spring自动将匹配到的属性值进行注入，然后就可以使用这个属性AutoWiredBean对象的方法。

4.Spring常用注解

@Component

它是这些注解里面最普通的一个注解，一般用于把普通pojo（实体类）实例化到spring容器中。

@Controller和@Service和@Repository是它的特殊情况，当一个类不需要进行这几种特殊归类的时候，只是作为一个普通的类，被Spring管理就OK的时候，比较适合采用@Component注解。

原理：将普通JavaBean实例化到spring容器中,Spring容器统一管理，用起来不用自己new了，相当于配置文件中的< bean id="" class=""/>

@Controller

用于标注控制层，表示向控制层注入服务层的数据

@Service

用于标注服务层，来进行业务的逻辑处理，在服务层注入DAO层数据

@Repository

用于标注数据访问层，也可以说用于标注数据访问组件，即DAO组件

@ComponentScan

@ComponentScan像一个路标，告诉你去哪找东西，如果我们要找的bean不在它的所在包或者子包里面，就需要自己再添加一个@ComponentScan注解。

在定义spring中的bean的时候，一般有两步 1.在bean上面添加@Controller/@Service/@Repository/@Component这几个注解，标注这个类是个bean 2.然后还需要让Spring能够找到这个bean，这时候就需要使用到@ComponentScan这个注解了

使用：@ComponentScan(“com.demo”) 引号里面是要扫描的包路径

SpringBoot中的使用： 在SpringBoot中也许不会经常看到这个注解，因为@SpringBootApplication这个注解里面集成了@ComponentScan注解，它里面会自动扫描这个类所在包以及子包下面的bean。

@ResponseBody

加了这个注解的类会将controller的方法返回的对象通过适当的转换器转换为指定的格式之后，写入到response对象的body区，通常用来返回JSON数据或者是XML。

需要注意的是，在使用此注解之后的数据不会再走ViewResolver，而是直接将数据写入到输入流中，它的效果相当于用response对象输出指定格式的数据。

@RestController

@RestController = @Controller + @ResponseBody

写这一个注解就相当于写了后面的两个注解，在返回值是json串的非常方便，但同时也会有一个问题，加了这个注解就不能返回jsp或者html页面，这时可以通过返回视图数据的方式来返回页面。

@RequestMapping(“xxxx”)

它用于 映射客户端的访问地址，可以被应用于类和方法上面，客户进行访问时，URL应该为类+方法上面的这个注解里面的内容。

@AutoWired

@Autowired可以标注在属性上、方法上和构造器上，来完成自动装配。默认是根据属性类型，spring自动将匹配到的属性值进行注入，然后就可以使用这个属性AutoWiredBean对象的方法。

注意事项：

@Autowired是ByType的，在使用时首先在容器中查询对应类型的bean

如果查询结果刚好为一个，就将该bean装配给@Autowired指定的数据

如果查询的结果不止一个，那么@Autowired会根据名称来查找（首字母小写）。

如果查询的结果为空，那么会抛出异常。解决方法是，@AutoWired(required=false)

@AutoWired加在变量/方法上面与加在构造器上面有什么区别？

答：加在构造器上面更保险一些。

因为Java变量的初始化顺序为： 静态变量或静态语句块–>实例变量或初始化语句块–>构造方法–>@Autowired

@Qualifer

这个注解是用来辅助@AutoWired注解来使用的。 用于当@AutoWired在注入父类属性时有两个或以上实现类时，指定要用哪个。

上面在@AutoWired注解里面说了，当实现类有多个的时候，它会自动去找和它名称相同的实现类（首字母小写），但如果我们不想这样，就可以加一个@Qualifer注解来指定具体要注入哪一个实现类。

@Resource

这个注解的作用和@AutoWired一致， 只不过@AutoWired是ByType的，而@Resource是ByName的 @AutoWired首先按类型查找，同类型的有多个时，才按照首字母小写来匹配 @Resource首先按照名称查找（注解写在字段上时，默认取字段名进行按照名称查找，注解写在setter方法上默认取属性名进行装配），没有对应名称时，才按照类型匹配

5.Spring的生命周期

对于 Spring Bean 的生命周期来说：

• 实例化 Instantiation
• 属性赋值 Populate
• 初始化 Initialization
• 销毁 Destruction

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

下面是Sprng Bean的完整生命周期：

5.什么是Spring MVC ？

Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架，通过把Model，View，Controller分离，将web层进行职责解耦，把复杂的web应用分成逻辑清晰的几部分，简化开发，减少出错，方便组内开发人员之间的配合。

• Controller——负责转发请求，对请求进行处理

• View——负责界面显示

• Model——业务功能编写（例如算法实现）、数据库设计以及数据存取操作实现

在JSP/Servlet开发的软件系统中，这三个部分的描述如下所示：

1. Web浏览器发送HTTP请求到服务端，被Controller(Servlet)获取并进行处理（例如参数解析、请求转发）

2. Controller(Servlet)调用核心业务逻辑——Model部分，获得结果

3. Controller(Servlet)将逻辑处理结果交给View（JSP），动态输出HTML内容

4. 动态生成的HTML内容返回到浏览器显示

5.Servlet和JSP的区别联系？

servlet是java编写的服务器端的程序,运行在web服务器中。

作用:

1. 接收用户端发来的请求

2. 调用其他java程序来处理请求

3. 将处理结果,返回到服务器中

JSP的全称是Java Server Pages，即Java的服务器页面

JSP的主要作用是代替Servlet程序回传HTML页面的数据

区别联系：

• JSP是Servlet技术的扩展，本质上就是Servlet的简易方式。jsp经编译后就变成了Servlet，JSP的本质就是Servlet，JVM只能识别java的类，不能识别JSP的代码,Web容器将JSP的代码编译成JVM能够识别的java类。

• jsp更擅长表现于视图（页面显示）,servlet更擅长于逻辑控制，Servlet类似于一个Controller，用来做控制。

• Servlet的应用逻辑是在Java文件中，并且完全从表示层中的HTML里分离开来。而JSP的情况是Java和HTML可以组合成一个扩展名为.jsp的文件。

6. Spring MVC的优点:

（1）可以支持各种视图技术，而不仅仅局限于JSP；

（2）与Spring框架集成（如IoC容器、AOP等）；

（3）清晰的角色分配：前端控制器(dispatcherServlet) ，请求到处理器映射（handlerMapping)，处理器适配器（HandlerAdapter)，视图解析器（ViewResolver）。

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

7. SpringMVC怎么样设定重定向和转发的？

（1）转发：在返回值前面加"forward:"，譬如"forward:user.do?name=method4"

（2）重定向：在返回值前面加"redirect:"，譬如"redirect:百度一下，你就知道"

8. forward和redirect的区别？

forward是转发，redirect是重定向。

forward ：url不会发生改变，redirect：url会发生改变

forward可以共享request里的数据，redirect不能共享

forward比redirect效率高

9. Spring MVC常用的注解有哪些？

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

@RequestBody：注解实现接收http请求的json数据，将json转换为java对象。

@ResponseBody：注解实现将controller方法返回对象转化为json对象响应给客户。

10. 什么是Mybatis？

（1）Mybatis是一个半ORM（对象关系映射）框架，它内部封装了JDBC，加载驱动、创建连接、创建statement等繁杂的过程，开发者开发时只需要关注如何编写SQL语句，可以严格控制sql执行性能，灵活度高。

（2）作为一个半ORM框架（称Mybatis是半自动ORM映射工具因为在查询关联对象或关联集合对象时，需要手动编写sql来完成），MyBatis 可以使用 XML 或注解来配置和映射原生信息，将 POJO映射成数据库中的记录，避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。

（3）通过xml 文件或注解的方式将要执行的各种 statement 配置起来，并通过java对象和 statement中sql的动态参数进行映射生成最终执行的sql语句，最后由mybatis框架执行sql并将结果映射为java对象并返回。（从执行sql到返回result的过程）。

（4）由于MyBatis专注于SQL本身，灵活度高，所以比较适合对性能的要求很高，或者需求变化较多的项目，如互联网项目。

Mybatis-Plus（MP）在 MyBatis 的基础上只做增强不做改变，简化开发、提高效率。但它也提供了一些很有意思的插件，比如SQL性能监控、乐观锁、执行分析等。

 11.Spring怎么整合Mybatis？

当运行MyBatis框架时，会先通过Resources去加载MyBaits配置文件，把加载到的文件流交给XMLConfigBuilder去解析，XMLConfigBuilder会把解析后的结果封装到Configuration中同时传递给DefaultSqlSessionFactory构造方法进行实例化SqlSessionFactory，再由SqlSessionFactory工厂对象创建SqlSession对象，中间每个SqlSession创建过程都会由Mybatis自动创建Transaction对象及Executor，最后实例化 DefaultSqlSession,传递给 SqlSession 接口

之后Mybatis会加载指定包下所有接口和映射文件实现接口绑定，每个接口都是通过动态代理实例化的。 在具体的业务中调用接口的某个方法时,调用了对应的SQL当事务执行结束后，需要commit事务.如果在提交事务过程出现异常,需要Rollback回滚事务.最后需要关闭SglSession对象.以上就是Mybatis的运行原理。

mybatis应用程序通过SqlSessionFactoryBuilder从mybatis-config.xml配置文件中构建出SqlSessionFactory，然后，SqlSessionFactory的实例直接开启一个SqlSession，再通过SqlSession实例获得Mapper对象并运行Mapper映射的SQL语句，完成对数据库的CRUD和事务提交，之后关闭SqlSession。

11. Mybaits的优缺点：

（1）优点：

① 消除了JDBC大量冗余的代码，不需要手动开关连接；

② 基于SQL语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL写在XML里，解除sql与程序代码的耦合，便于统一管理；提供XML标签，支持编写动态SQL语句，并可重用。

③ 很好的与各种数据库兼容（因为MyBatis使用JDBC来连接数据库，所以只要JDBC支持的数据库MyBatis都支持）。

④ 能够与Spring很好的集成；

⑤ 提供映射标签，支持对象与数据库的ORM字段关系映射；提供对象关系映射标签，支持对象关系组件维护。

（2）缺点：

① SQL语句的编写工作量较大，尤其当字段多、关联表多时，对开发人员编写SQL语句的功底有一定要求。

② SQL语句依赖于数据库，导致数据库移植性差，不能随意更换数据库。

12. #{}和${}的区别是什么？

${}注入会直接注入，即注入的变量是什么就注入什么，一般用作占位符。在有些需要表示字段名、表名的场景下使用${}，其余能用#{}都用#{}。

#{}会在你注入的变量上加上“ ”,当你采用${}注入时，如果注入的内容恰好是sql语句时，则会改变你开始的sql语句而#{}则不会，即#{}可以防止sql注入。

13. 什么是 Spring Boot？

Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式解决方案，主要是简化了使用 Spring 的难度，简省了繁重的配置，提供了各种启动器，使开发者能快速上手

14. 为什么要用SpringBoot？

快速开发，快速整合，配置简化、内嵌服务容器

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

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

二、数据库

1.MySQL 使用索引的原因？

根本原因

• 索引的出现，就是为了提高数据查询的效率，就像书的目录一样。

• 对于数据库的表而言，索引其实就是它的“目录”。

扩展

• 创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

• 帮助引擎层避免排序和临时表

• 将随机 IO 变为顺序 IO，加速表和表之间的连接。

一般对于查询概率比较高，经常作为where条件的字段设置索引

2.聚集索引和非聚集索引

聚集索引（聚簇索引）是指数据库表行中数据的物理顺序与键值的逻辑（索引）顺序相同。一个表只能有一个聚集索引，因为一个表的物理顺序只有一种情况，所以，对应的聚集索引只能有一个。

如果某索引不是聚集索引，则表中的行物理顺序与索引顺序不匹配，与非聚集索引相比，聚集索引有着更快的检索速度。

聚集索引确定表中数据的物理顺序。聚集索引类似于字典，按字母排序，每个字母下有多个字（相当于数据列）。所以对于聚集索引，叶子结点即存储了真实的数据行。所以通过聚集索引可以直接获取到数据库中的数据。

非聚集索引，该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。

非聚集索引的叶层不包含数据页， 叶结点包含索引字段值及指向数据页数据行的逻辑指针（每个索引行包含非聚集键值以及一个或多个行定位器，这些行定位器指向有该键值的数据行（如果索引不唯一，则可能是多行））。所以非聚集索引不能直接获取到数据，需要通过定位器来获取数据。
 

MyISAM 引擎（非聚集索引方式）

MyISAM 用的是非聚集索引方式，即数据和索引落在不同的两个文件上。MyISAM 在建表时以主键作为 KEY 来建立主索引 B+树，树的叶子节点存的是对应数据的物理地址。我们拿到这个物理地址后，就可以到 MyISAM 数据文件中直接定位到具体的数据记录了。

当我们为某个字段添加索引时，我们同样会生成对应字段的索引树，该字段的索引树的叶子节点同样是记录了对应数据的物理地址，然后也是拿着这个物理地址去数据文件里定位到具体的数据记录。

 Innodb 引擎（聚集索引方式）

InnoDB 是聚集索引方式，因此数据和索引都存储在同一个文件里。首先 InnoDB 会根据主键 ID 作为 KEY 建立索引 B+树，如左下图所示，而 B+树的叶子节点存储的是主键 ID 对应的数据，比如在执行 select * from user_info where id=15 这个语句时，InnoDB 就会查询这颗主键 ID 索引 B+树，找到对应的 user_name=‘Bob’。

这是建表的时候 InnoDB 就会自动建立好主键 ID 索引树，这也是为什么 Mysql 在建表时要求必须指定主键的原因。当我们为表里某个字段加索引时 InnoDB 会怎么建立索引树呢？比如我们要给 user_name 这个字段加索引，那么 InnoDB 就会建立 user_name 索引 B+树，节点里存的是 user_name 这个 KEY，叶子节点存储的数据的是主键 KEY。注意，叶子存储的是主键 KEY！拿到主键 KEY 后，InnoDB 才会去主键索引树里根据刚在 user_name 索引树找到的主键 KEY 查找到对应的数据。

为什么 InnoDB 只在主键索引树的叶子节点存储了具体数据，但是其他索引树却不存具体数据呢，而要多此一举先找到主键，再在主键索引树找到对应的数据呢?

其实很简单，因为 InnoDB 需要节省存储空间。一个表里可能有很多个索引，InnoDB 都会给每个加了索引的字段生成索引树，如果每个字段的索引树都存储了具体数据，那么这个表的索引数据文件就变得非常巨大（数据极度冗余了）。从节约磁盘空间的角度来说，真的没有必要每个字段索引树都存具体数据，通过这种看似“多此一举”的步骤，在牺牲较少查询的性能下节省了巨大的磁盘空间，这是非常有值得的。（只在主键索引树的叶子节点存储了具体数据，在其他的索引树上都只记录主键 KEY）

 

3.为什么一定要设一个主键？

因为你不设主键的情况下，innodb也会帮你生成一个隐藏列，作为自增主键。所以啦，反正都要生成一个主键，那你还不如自己指定一个主键，在有些情况下，就能显式的用上主键索引，提高查询效率。

4. 正确使用索引(避免索引失效)？

1. 主键的数据列一定要建立索引，建表的时候 InnoDB 会自动建立好主键 ID 索引树
2. 有外键的数据列一定得建立索引。
3. 经常查询的列建立索引
4. 经常用在where子句里的列（数据列）
5. 需要在指定范围内快速或者频繁查询的数据列
6. order by、group by后面的字段要建立索引，如果建立的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，否则索引不会被使用。

使用索引注意事项：

1. 建立索引的列的重复度不能太高
2. 条件列不能参与计算，非要计算的话，把式子放等号后面
3. 不能使用函数
4. 条件中不能使用范围
5. 不要使用like ``'%c'（左模糊查询）
6. 条件中用or  ``a=0 or b=1 or c=2 or d=4 只要其中一列没有索引就无法命中
7. 最左前缀(a,b,c,d) 只适用于and条件的列,如果出现范围，从出现范围的字段开始就失效，必须带着最左侧的列 ``只要不带a就无法命中索引 ``a = 1 or b = 2  无法命中索引 （因为没带a）， ``a = 1 and b>100 a可以命中索引 b,c,d无法命中（因为从b开始出现范围了），  ``a>200 无法命中索引 因为联合索引一旦使用范围，从使用范围开始之后的索引都不生效 。

5.最左匹配原则

最左前缀原则：顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上

在创建多列索引时，我们根据业务需求，where子句中使用最频繁的一列放在最左边，因为MySQL索引查询会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候，如(key1,key2,key3)，相当于创建了（key1）、(key1,key2)和(key1,key2,key3)三个索引，如果最左边无法命中，后面索引也都失效，还有联合索引一旦使用范围，从使用范围开始之后的索引都不生效 。

6.索引有几种？

主键索引：数据记录里面不能有null，内容不能重复，在一张表中不能有多个主键索引。

普通索引：使用字段关键字建立的索引，主要是提高查询速度。

唯一索引：字段数据是唯一的，数据内容能为null。一张表中可以添加多个唯一索引。

全文索引：老版本中只有myisam引擎支持全文索引，（mysql5.5以后InnoDB支持全文索引）。mysql中全文索引不支持中文。一般使用sphinx集合coreseek来实现中文的全文索引。仅适用于 CHAR， VARCHAR和 TEXT列。

7. 创建了很多索引，怎么知道到底有没有生效？

通过通过explain查看sql语句的执行计划，通过执行计划ref和key_len列来分析索引使用情况。

8.InnoDB使用的B+ 树的索引模型，那么你知道为什么采用B+ 树吗？

因为Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的，所以，对于区间查询是无法直接通过索引查询的，就需要全表扫描。所以，哈希索引只适用于等值查询的场景。

而B+ 树是一种多路平衡查询树，所以他的节点是天然有序的（左子节点小于父节点、父节点小于右子节点），所以对于范围查询的时候不需要做全表扫描。所以左模糊查询会造成索引失效，右模糊不会。

对索引使用左模糊匹配或者全模糊匹配，也就是 like %xx 或者 like %xx% 这两种方式都会造成索引失效。原因在于查询的结果可能是多个，不知道从哪个索引值开始比较，于是就只能通过全表扫描的方式来查询。

9.B+树索引和Hash索引的区别？

• 哈希索引适合等值查询，但是无法进行范围查询
• 哈希索引没办法利用索引完成排序
• 哈希索引不支持多列联合索引的最左匹配规则
• 如果有大量重复键值的情况下，哈希索引的效率会很低，因为存在哈希碰撞问题

10.MySQL数据库优化

• 选取最适用的字段属性

• 使用连接（JOIN）来代替子查询(Sub-Queries)

• 事务

• 锁定表

• 使用外键

• 使用索引（一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDERBY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。）创建索引、创建索引、索引不会包含有NULL值的列、使用短索引

• 优化的查询语句（不要在列上进行运算、不使用NOT IN和<>操作NOT IN可以NOT EXISTS代替，id<>3则可使用id>3 or id<3来代替。）

11. MySQL大数据量处理常用解决方案

1、读写分离 读写分离，将数据库的读写操作分开，比如让性能比较好的服务器去做写操作，性能一般的服务器做读操作。

2、分库分表

垂直拆分表，例如将表的大文本字段分离出来，成为独立的新表。

水平拆分表，可以按时间，根据实际情况一个月或季度创建一个表，另外还可以按类型拆分。单表拆分数据应控制在1000万以内。

3、数据缓存

使用缓存技术降低对数据库直接访问的压力，比如使用Redis内存数据库存储热点数据，全量缓存内存占用太大，所以要识别出热点数据进行缓存，比用用户信息表，可以考虑缓存一段时间内的活跃用户。

4、SQL语句优化

尽量避免联表查询，避免递归等消耗性能的语句。表设计优化，例如单表字段不宜过多，时间类型使用TIMESTAMP，字段尽量避免NULL等。索引优化，合理创建索引，索引不是越多越好，也不是所有的字段都适合建立索引。

三、Redis缓存技术

1.为什么 Redis 是单线程？

在 redis 6.0 之前，redis 的核心操作是单线程的。

因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的大小或者网络带宽。

既然CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了，因为如果使用多线程的话会更复杂，同时需要引入上下文切换、加锁等等，会带来额外的性能消耗。

而随着近些年互联网的不断发展，大家对于缓存的性能要求也越来越高了，因此 redis 也开始在逐渐往多线程方向发展。

最近的 6.0 版本就对核心流程引入了多线程，主要用于解决 redis 在网络 I/O 上的性能瓶颈。而对于核心的命令执行阶段，目前还是单线程的。

2.Redis 为什么使用单进程、单线程也很快?

主要有以下几点：

1、基于内存的操作

2、使用了 I/O 多路复用模型（非阻塞IO。多路：多个网络连接 复用：复用同一个线程），select、epoll 等，基于 reactor 模式开发了自己的网络事件处理器

3、单线程可以避免不必要的上下文切换和竞争条件，不用去考虑各种锁问题，减少了这方面的性能消耗。

以上这三点是 redis 性能高的主要原因，其他的还有一些小优化，例如：对数据结构进行了优化，简单动态字符串、压缩列表等。

3.Redis 在项目中的使用场景?

缓存（核心）、分布式锁（set + lua 脚本）、排行榜（zset）、计数（incrby）、消息队列（stream）、地理位置（geo）、访客统计（hyperloglog）等。

4.Redis 常见的数据结构?

基础的5种：

String：字符串，最基础的数据类型。

List：列表。

Hash：哈希对象。

Set：集合。

Sorted Set：有序集合，Set 的基础上加了个分值。

高级的4种：

HyperLogLog：通常用于基数统计。使用少量固定大小的内存，来统计集合中唯一元素的数量。统计结果不是精确值，而是一个带有0.81%标准差（standard error）的近似值。所以，HyperLogLog适用于一些对于统计结果精确度要求不是特别高的场景，例如网站的UV统计。

Geo：redis 3.2 版本的新特性。可以将用户给定的地理位置信息储存起来， 并对这些信息进行操作：获取2个位置的距离、根据给定地理位置坐标获取指定范围内的地理位置集合。

Bitmap：位图。

Stream：主要用于消息队列，类似于 kafka，可以认为是 pub/sub 的改进版。提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

5.Redis 删除过期键的策略（缓存失效策略、数据过期策略）

定时删除：在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即执行对键的删除操作。对内存最友好，对 CPU 时间最不友好。

惰性删除：放任键过期不管，但是每次获取键时，都检査键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。对 CPU 时间最优化，对内存最不友好。

定期删除：每隔一段时间，默认100ms，程序就对数据库进行一次检査，删除里面的过期键。至 于要删除多少过期键，以及要检査多少个数据库，则由算法决定。前两种策略的折中，对 CPU 时间和内存的友好程度较平衡。

Redis 使用惰性删除和定期删除。

6.Redis 的持久化机制有哪几种，各自的实现原理和优缺点？

Redis 的持久化机制有：RDB、AOF、混合持久化（RDB+AOF，Redis 4.0引入）。

1）RDB

描述：类似于快照。是将某一个时刻的内存数据，以二进制的方式写入磁盘。

RDB 的优点

RDB 默认的保存文件为 dump.rdb，优点是以二进制存储的，因此占用的空间更小、数据存储更紧凑，并且与 AOF 相比，RDB 具备更快的重启恢复能力。

RDB 的缺点

RDB 在服务器故障时容易造成数据的丢失。RDB 允许我们通过修改 save point 配置来控制持久化的频率。但是，因为 RDB 文件需要保存整个数据集的状态， 所以它是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失5分钟数据。

2）AOF

描述：AOF（Append Only File，文件追加方式）是指将所有的操作命令，以文本的形式追加到文件中。

AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此丢失数据的风险就越低，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是占用空间大，重启之后的数据恢复速度比较慢。

RDB 具备更快速的数据重启恢复能力，并且占用更小的磁盘空间，但有数据丢失的风险；而 AOF 文件的可读性更高，但却占用了更大的空间，且重启之后的恢复速度更慢，于是在 Redis 4.0 就推出了混合持久化的功能。

开启：AOF 持久化默认是关闭的，可以通过配置：appendonly yes 开启。

关闭：使用配置 appendonly no 可以关闭 AOF 持久化。

AOF 持久化功能的实现可以分为三个步骤：命令追加、文件写入、文件同步。

命令追加：当 AOF 持久化功能打开时，服务器在执行完一个写命令之后，会将被执行的写命令追加到服务器状态的 aof 缓冲区（aof_buf）的末尾。

文件写入与文件同步：可能有人不明白为什么将 aof_buf 的内容写到磁盘上需要两步操作，这边简单解释一下。

Linux 操作系统中为了提升性能，使用了页缓存（page cache）。当我们将 aof_buf 的内容写到磁盘上时，此时数据并没有真正的落盘，而是在 page cache 中，为了将 page cache 中的数据真正落盘，需要执行 fsync / fdatasync 命令来强制刷盘。这边的文件同步做的就是刷盘操作，或者叫文件刷盘可能更容易理解一些。

在文章开头，我们提过 serverCron 时间事件中会触发 flushAppendOnlyFile 函数，该函数会根据服务器配置的 appendfsync 参数值，来决定是否将 aof_buf 缓冲区的内容写入和保存到 AOF 文件。

appendfsync 参数有三个选项：

always：每处理一个命令都将 aof_buf 缓冲区中的所有内容写入并同步到AOF 文件，即每个命令都刷盘。 everysec：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间距离现在超过一秒钟， 那么再次对 AOF 文件进行同步， 并且这个同步操作是异步的，由一个后台线程专门负责执行，即每秒刷盘1次。 no：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 但并不对 AOF 文件进行同步， 何时同步由操作系统来决定。即不执行刷盘，让操作系统自己执行刷盘。

AOF 的优点

• AOF 比 RDB可靠。你可以设置不同的 fsync 策略：no、everysec 和 always。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

• AOF文件是一个纯追加的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等）， 我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。

• AOF 文件有序地保存了对数据库执行的所有写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态

AOF 的缺点

1. 对于相同的数据集，AOF 文件的大小一般会比 RDB 文件大。

2. 根据所使用的 fsync 策略，AOF 的速度可能会比 RDB 慢。通常 fsync 设置为每秒一次就能获得比较高的性能，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快。

3）混合持久化

描述：混合持久化并不是一种全新的持久化方式，而是对已有方式的优化。混合持久化只发生于 AOF 重写过程。使用了混合持久化，重写后的新 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。

开启：混合持久化的配置参数为 aof-use-rdb-preamble，配置为 yes 时开启混合持久化，在 redis 4 刚引入时，默认是关闭混合持久化的，但是在 redis 5 中默认已经打开了。

关闭：使用 aof-use-rdb-preamble no 配置即可关闭混合持久化。

7.Redis 怎么保证高可用？

高可用是通过设计，减少系统不能提供服务的时间，是分布式系统的基础也是保障系统可靠性的重要手段。

Redis 高可用的手段主要有以下四种：

●数据持久化
●主从数据同步（主从复制）
●Redis 哨兵模式（Sentinel）
●Redis 集群（Cluster）

其中数据持久化保证了系统在发生宕机或者重启之后数据不会丢失，增加了系统的可靠性和减少了系统不可用的时间（省去了手动恢复数据的过程）；而主从数据同步可以将数据存储至多台服务器，这样当遇到一台服务器宕机之后，可以很快地切换至另一台服务器以继续提供服务；哨兵模式用于发生故障之后自动切换服务器；而 Redis 集群提供了多主多从的 Redis 分布式集群环境，用于提供性能更好的 Redis 服务，并且它自身拥有故障自动切换的能力。

1、数据持久化见上一题，即aof、rdb、混合持久化。

2、Redis 主从同步

主从同步是 Redis 多机运行中最基础的功能，它是把多个 Redis 节点组成一个 Redis 集群，在这个集群当中有一个主节点用来进行数据的操作，其他从节点用于同步主节点的内容，并且提供给客户端进行数据查询。

Redis 主从同步分为：主从模式和从从模式。

主从模式就是一个主节点和多个一级从节点

从从模式是指一级从节点下面还可以拥有更多的从节点

 

主从模式可以提高 Redis 的整体运行速度，因为使用主从模式就可以实现数据的读写分离，把写操作的请求分发到主节点上，把其他的读操作请求分发到从节点上，这样就减轻了 Redis 主节点的运行压力，并且提高了 Redis 的整体运行速度。

主从模式还实现了 Redis 的高可用，当主服务器宕机之后，可以很迅速的把从节点提升为主节点，为 Redis 服务器的宕机恢复节省了宝贵的时间。

并且主从复制还降低了数据丢失的风险，因为数据是完整拷贝在多台服务器上的，当一个服务器磁盘坏掉之后，可以从其他服务器拿到完整的备份数据。
3.Redis 哨兵模式

Redis 哨兵模式就是用来监视 Redis 主从服务器的，当 Redis 的主从服务器发生故障之后，Redis 哨兵提供了自动容灾修复的功能。（监视，Redis 的主节点宕机之后，自动切换服务器）

哨兵的工作原理是每个哨兵会以每秒钟 1 次的频率，向已知的主服务器和从服务器，发送一个 PING 命令。如果最后一次有效回复 PING 命令的时间，超过了配置的最大下线时间（Down-After-Milliseconds）时，默认是 30s，那么这个实例会被哨兵标记为主观下线。

如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有哨兵节点，要以每秒 1 次的频率确认主服务器是否进入了主观下线的状态。如果有足够数量（quorum 配置值）的哨兵证实该主服务器为主观下线，那么这个主服务器被标记为客观下线。此时所有的哨兵会按照规则（协商）自动选出新的主节点服务器，并自动完成主服务器的自动切换功能，而整个过程都是无须人工干预的。

4.Redis 集群

将数据分布在不同的主服务器上，以此来降低系统对单主节点的依赖，并且可以大大提高 Redis 服务的读写性能。Redis 集群除了拥有主从模式 + 哨兵模式的所有功能之外，还提供了多个主从节点的集群功能，实现了真正意义上的分布式集群服务

Redis 集群可以实现数据分片服务，也就是说在 Redis 集群中有 16384 个槽位用来存储所有的数据，当我们有 N 个主节点时，可以把 16384 个槽位平均分配到 N 台主服务器上。当有键值存储时，Redis 会使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位，再把此键值存储在对应的服务器上，读取操作也是同样的道理，这样我们就实现了数据分片的功能。

小结：

保障 Redis 高可用的 4 种手段：数据持久化保证了数据不丢失；Redis 主从让 Redis 从单机变成了多机。它有两种模式：主从模式和从从模式，但当主节点出现问题时，需要人工手动恢复系统；Redis 哨兵模式用来监控 Redis 主从模式，并提供了自动容灾恢复的功能。最后是 Redis 集群，除了可以提供主从和哨兵的功能之外，还提供了多个主从节点的集群功能，这样就可以把数据均匀的存储各个主机主节点上，实现了系统的横向扩展，大大提高了 Redis 的并发处理能力。

8、redis有哪些集群模式？

主从、哨兵、集群（cluster）。见上一题。

9、redis实现分布式锁

开启redis分布式锁

如果key不存在，设置它的值

setnx lock:codehole true

加入过期时间，防止死锁

set lock:codehole true ex 5 nx;

超时问题：如果在加锁和释放锁之间的逻辑执行的太长，以至于超出了锁的超时限制，就会出现问题。因为这时候锁过期了，第二个线程重新持有了这把锁，但是紧接着第一个线程执行完了业务逻辑，就把锁给释放了，第三个线程就会在第二个线程逻辑执行完之间拿到了锁。（加锁释放锁的时间太长，导致锁过期以后，第二个线程已经持有了这把锁，这时候第一个线程才把刚锁释放出去，这时候第三个线程就拿到了第一线程的锁）

超时的解决：

使用 Lua 脚本为 set 指令的 value 参数设置为一个随机数，释放锁时先匹配随机数是否一致，然后再删除 key

tag = random.nextint() # 随机数
if redis.set(key, tag, nx=True, ex=5):
    do_something()
    redis.delifequals(key, tag) # 假象的 delifequals 指令

过期时间到了防止其他线程拿到锁是通过设置value参数为随机数，释放时先匹配是否一致，如果该线程还未执行完毕，需要续期处理方式如下

Redission（Redis SDK客户端）中有个watch dog的自动延期机制，帮我们实现了自动续时功能。通过lock() 方法或者通过tryLock()方法获取锁时，只要在参数中，不传入leasetime或者传入-1，就会开启看门狗机制，默认看门狗续期时间30s，可以通过修改Config.lockWatchdogTimeout来另行指定。

• watch dog 在当前节点存活时每10s给分布式锁的key续期 30s；

• watch dog 机制启动，且代码中没有释放锁操作时，watch dog 会不断的给锁续期；
• 如果程序释放锁操作时因为异常没有被执行，那么锁无法被释放，所以释放锁操作一定要放到 finally {} 中；

集群之间出现拿到同一把锁：在主从发生failover（失败转移）的时候，从节点成为主节点可能会导致两个客户端拿到同一把锁。

采用redlock算法，加锁时会向过半节点发送set(key,value,nx=True,ex=xxx)指令，只要过半节点set成功，就认为加锁成功。释放锁时，需要向所有节点发送del指令。不过redlock算法还需要考虑出错重试，时钟漂移等很多细节问题，同事因为redlock需要向多个节点进行读写，意味着其相比单实例redis的性能会下降一。

四、Nginx

1. 什么是nginx？

Nginx是一个 轻量级/高性能的反向代理Web服务器，他实现非常高效的反向代理、负载平衡，他可以处理2-3万并发连接数，官方监测能支持5万并发

2. 为什么要用Nginx？

因为他的事件处理机制（异步非阻塞事件处理机制（AIO）：运用了epoll模型，提供了一个队列，排队解决）等使得它的性能很高。

• 跨平台、配置简单、方向代理、高并发连接：处理2-3万并发连接数，官方监测能支持5万并发，内存消耗小：开启10个nginx才占150M内存 ，nginx处理静态文件好，耗费内存少。

• Nginx内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。

• 使用Nginx的话还能：

  节省宽带：支持GZIP压缩，可以添加浏览器本地缓存

  稳定性高：宕机的概率非常小

  接收用户请求是异步的

3.什么是正向代理和反向代理？

1. 正向代理就是一个人发送一个请求直接就到达了目标的服务器

2. 反向代理就是请求统一被Nginx接收，nginx反向代理服务器接收到之后，按照一定的规 则分发给了后端的业务处理服务器进行处理了

4.Nginx应用场景？

（1）http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。 （2）虚拟主机。可以实现在一台服务器虚拟出多个网站，例如个人网站使用的虚拟机。 （3）反向代理，负载均衡。当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载，不会应为某台服务器负载高宕机而某台服务器闲置的情况。 （4）nginx中也可以配置安全管理、比如可以使用Nginx搭建API接口网关,对每个接口服务进行拦截。

5.location指令

location：用来设置请求的 URI

nginx服务器在搜索匹配location的时候，是先使用不包含正则表达式进行匹配，找到一个匹配度最高的一个，然后再通过包含正则表达式的进行匹配；如果能匹配到直接访问，匹配不到，就使用刚才匹配度最高的那个location来处理请求

具体属性介绍：

（1）不带符号

要求必须以指定模式开始

server {
    
    listen 80;
    server_name 127.0.0.1;
    location /abc {
        default_type text/plain;
        return 200 "access success";
    }
 
}

在这种情况下，只要是以 /abc开头的都能被匹配到，以下访问都是正确的：http://IP/abc

http://IP/abc?p1=TOM

http://IP/abc/

http://IP/abcdef

（2）=

= ：用于不包含正则表达式的uri前，必须与指定的模式精确匹配

（3）~

~：用于表示当前uri中包含了正则表达式，并且区分大小写

~*: 用于表示当前uri中包含了正则表达式，并且不区分大小写；

如果uri包含了正则表达式，需要用上述两个符合来标识；

^~: 用于不包含正则表达式的 uri 前

6.Nginx如何进行限流？

Nginx限流就是限制用户请求速度，防止服务器崩溃。

限流有3种：

1. 正常限制访问频率（正常流量）

2. 突发限制访问频率（突发流量）

3. 限制并发连接数

Nginx的限流都是基于漏桶流算法。

7.漏桶流算法和令牌桶算法

漏桶算法：

漏桶算法是网络世界中流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。也就是我们刚才所讲的情况。漏桶算法提供的机制实际上就是刚才的案例：突发流量会进入到一个漏桶，漏桶会按照我们定义的速率依次处理请求，如果水流过大也就是突发流量过大就会直接溢出，则多余的请求会被拒绝。所以漏桶算法能控制数据的传输速率。

令牌桶算法：

令牌桶算法是网络流量整形和速率限制中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。Google开源项目Guava中的RateLimiter使用的就是令牌桶控制算法。令牌桶算法的机制如下：存在一个大小固定的令牌桶，会以恒定的速率源源不断产生令牌。如果令牌消耗速率小于生产令牌的速度，令牌就会一直产生直至装满整个令牌桶。

漏桶和令牌桶主要区别在于“漏桶算法”能够强行限制数据的传输速率，而“令牌桶算法”在能够限制数据的平均传输速率外，还允许某种程度的突发传输。在“令牌桶算法”中，只要令牌桶中存在令牌，那么就允许突发地传输数据直到达到用户配置的门限，因此它适合于具有突发特性的流量

8.为什么要做动静分离？

• Nginx是当下最热的Web容器，网站优化的重要点在于静态化网站，网站静态化的关键点则是是动静分离，动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们则根据静态资源的特点将其做缓存操作。

• 让静态的资源只走静态资源服务器，动态的走动态的服务器

• Nginx的静态处理能力很强，但是动态处理能力不足，因此，在企业中常用动静分离技术。

• 对于静态资源比如图片，js，css等文件，我们则在反向代理服务器nginx中进行缓存。这样浏览器在请求一个静态资源时，代理服务器nginx就可以直接处理，无需将请求转发给后端服务器tomcat。

• 若用户请求的动态文件，比如servlet,jsp则转发给Tomcat服务器处理，从而实现动静分离。这也是反向代理服务器的一个重要的作用。

Nginx怎么做的动静分离：只需要指定路径对应的目录。location/可以使用正则表达式匹配。并指定对应的硬盘中的目录。

9.Nginx负载均衡的算法怎么实现的?策略有哪些?

为了避免服务器崩溃，大家会通过负载均衡的方式来分担服务器压力。将多台服务器组成一个集群，当用户访问时，先访问到一个转发服务器，再由转发服务器将访问分发到压力更小的服务器。

Nginx负载均衡实现的策略有以下五种：

1 轮询(默认)

• 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某个服务器宕机，能自动剔除故障系统。

2 权重 weight

• weight的值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。其次是为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。

3 ip_hash( IP绑定)

• 每个请求按访问IP的哈希结果分配，使来自同一个IP的访客固定访问一台后端服务器，并且可以有效解决动态网页存在的session共享问题

4 fair(第三方插件)

• 必须安装upstream_fair模块。

• 对比 weight、ip_hash更加智能的负载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，响应时间短的优先分配。

• 哪个服务器的响应速度快，就将请求分配到那个服务器上。

5 url_hash(第三方插件)

• 必须安装Nginx的hash软件包

• 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，可以进一步提高后端缓存服务器的效率。

10.cookie和session的区别？

Cookie：有时也用其复数形式Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。（就是把用户信息通过cookie保存在本地）

会话：用户开一个浏览器，点击多个超链接，访问服务器多个web资源，然后关闭浏览器，整个过程称之为一个会话

Session：会话控制，Session 对象存储特定用户会话所需的属性及配置信息。

给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie什么时候产生 ？

• Cookie的使用一先要看需求。因为浏览器可以禁用Cookie，同时服务端也可以不Set-Cookie。
• 客户端向服务器端发送一个请求的时，服务端向客户端发送一个Cookie然后浏览器将Cookie保存
• Cookie有两种保存方式，一种是浏览器会将Cookie保存在内存中，还有一种是保存在客户端的硬盘中，之后每次HTTP请求浏览器都会将Cookie发送给服务器端。

Cookie的生存周期？

• Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期，在这个周期内Cookie有效，超出周期Cookie就会被清除。有些页面将Cookie的生存周期设置为“0”或负值，这样在关闭浏览器时，就马上清除Cookie，不会记录用户信息，更加安全。

Cookie有哪些缺陷 ？

①数量受到限制。一个浏览器能创建的 Cookie 数量最多为 300 个，并且每个不能超过 4KB，每个 Web 站点能设置的Cookie 总数不能超过 20 个
②安全性无法得到保障。通常跨站点脚本攻击往往利用网站漏洞在网站页面中植入脚本代码或网站页面引用第三方法脚本代码，均存在跨站点脚本攻击的可能，在受到跨站点脚本攻击时，脚本指令将会读取当前站点的所有Cookie 内容（已不存在 Cookie 作用域限制），然后通过某种方式将 Cookie 内容提交到指定的服务器（如：AJAX）。一旦 Cookie 落入攻击者手中，它将会重现其价值。
③浏览器可以禁用Cookie，禁用Cookie后，也就无法享有Cookie带来的方便。
cookie的应用场景？

1、对安全性要求不高

2、不需要存储大量的数据

3、主要用来做客户端和服务器之间的状态保持技术

Session什么时候产生 ？

• 当用户请求来自应用程序的 Web 页时，如果该用户还没有会话，则 Web 服务器将自动创建一个 Session 对象。
• 这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。
• 
• 服务器会向客户浏览器发送一个每个用户特有的会话编号sessionID，让他进入到cookie里

• 服务器同时也把sessionID和对应的用户信息、用户操作记录在服务器上，这些记录就是session。再次访问时会带入会发送cookie给服务器，其中就包含sessionID。
• 
• 服务器从cookie里找到sessionID，再根据sessionID找到以前记录的用户信息就可以知道他之前操控些、访问过哪里。

 Session的生命周期 ？

根据需求设定，一般来说，半小时。举个例子，你登录一个服务器，服务器返回给你一个sessionID，登录成功之后的半小时之内没有对该服务器进行任何HTTP请求，半小时后你进行一次HTTP请求，会提示你重新登录

小结：Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

cookie和session结合使用？（两种方式）

1、存储在服务端：通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。
2、将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。
 

五、微服务

1.什么是微服务架构

微服务的定义：微服务架构是将单体应用拆分为多个高内聚低耦合的小型服务，每个服务运行在独立的进程，可由不同的团队开发和维护，服务间采用轻量通信机制，独立自动部署，可以采用不同的语言及数据库，以保证最低限度的集中式管理。

2.SpringCloud的优点？

• 易于开发与维护：微服务相对较小，易于理解，启动时间短，开发效率高。

• 独立部署，耦合度比较低：一个服务的修改不需要协调其他服务。

• 配置比较简单，基本用注解就能实现，不用使用过多的配置文件。

• 与组织结构匹配：更好的将架构和组织匹配，每个团队独立负责某些服务。

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本。

• 直接 写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。

3.什么是Dubbo？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目.

4.为什么要用Dubbo？

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。

5.Dubbo的使用场景有哪些？

远程方法的调用时，只需要简单配置就可以向调用本地方法一样调用远程方法，没有任何API侵入。

软负载均衡及容错机制：可在内网替代 F5 等硬件负载均衡器，降低成本，减少单点。

服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

6.Spring Cloud 和Dubbo区别?

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

2）注册中心

Dubbo 是zookeeper；springcloud是eureka，也可以是zookeeper

3）服务网关

Dubbo本身没有实现服务网关，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发

7.Dubbo集群容错有几种方案？六种

8.Dubbo使用过程中都遇到了些什么问题？

在注册中心找不到对应的服务,检查service实现类是否添加了@service注解无法连接到注册中心,检查配置文件中的对应的测试 ip是否正确。

9.Dubbo用到哪些设计模式？

观察者模式

Dubbo的Provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个listener。注册中心会每5秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个notify消息，provider接受到notify消息后，即运行NotifyListener的notify方法，执行监听器方法。

动态代理模式

Dubbo扩展JDK SPI的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是，获取URL参数中指定参数的值作为获取实现类的key。

10.Dubbo核心功能有哪些？

Remoting：网络通信框架，提供对多种NIO（同步非阻塞）框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。

Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

11. Zookeeper是什么？

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，主要为了解决分布式架构下数据一致性问题，典型的应用场景有分布式配置中心、分布式注册中心、分布式锁、分布式队列、集群选举、分布式屏障、发布/订阅等场景。

12.Zookeeper是怎样的一个数据结构？

Zookeeper是一个类似于文件系统的数据结构，最外层我们可以想象成一个大的文件夹，里面都是一些小的文件夹。

13.Zookeeper有几种常用的数据格式呢？

Zookeeper中每一个子目录项都是一个znode（目录节点），这些目录节点和我们普通的目录一样可以新建、删除、修改，我们常用的主要有四种类型的znode。

1、持久化目录节点： 客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他将永远存在。

2、持久化顺序编号目录节点： 客户端与zookeeper断开连接后，该节点依旧存在，只是zookeeper给该节点名称进行顺序编号。

3、临时目录节点： 客户端与zookeeper断开连接后，该节点被删除。

4、临时顺序编号目录节点： 客户端与zookeeper断开连接后，该节点被删除，只是zookeeper给该节点名称进行顺序编号。

14.Zookeeper 怎么保证主从节点的状态同步？

Zookeeper 的核心是原子广播机制，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

恢复模式 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。恢复模式是选举leader， 完成server和 leader 的状态同步

广播模式 一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。广播模式是广播消息

14.Zookeeper有哪些核心的功能呢？

zookeeper有监听通知机制，如果对某个节点进行监听，当这个节点被删除，或者被修改时，监听方会感知到修改消息。

可以监听到七种类型变化： 1、None：连接建立事件 2、NodeCreated：节点创建 3、NodeDeleted：节点删除 4、NodeDataChanged：节点数据变化 5、NodeChildrenChanged：子节点列表变化 6、DataWatchRemoved：节点监听被移除 7、ChildWatchRemoved：子节点监听被移除

16.在开发中使用Synchronized就可以保证线程安全了，为什么还需要使用zookeeper来实现分布式锁呢？

如果是单机情况下也就是只有一个进程的情况下使用Synchronized是可以保证线程安全的。但是分布式情况下是多个不同的进程，而不是一个进程里面不同的线程，所以Synchronized是无法保证多个进程安全的。

zookeepr分布式锁怎么实现？

实现方式有很多种，我们可以基于zookeeper的两个特性来实现分布式锁的操作。

唯一性节点

多个应用程序去抢占锁资源时，只需要在指定节点上创建一个 /Lock 节点，由于Zookeeper中节点的唯一性特性，使得只会有一个用户成功创建 /Lock 节点，剩下没有创建成功的用户表示竞争锁失败。这种方法虽然能达到目的，但是会有一个问题，如下图所示，假设有非常多的节点需要等待获得锁，那么等待的方式自然是使用watcher机制来监听/lock节点的删除事件，一旦发现该节点被删除说明之前获得锁的节点已经释放了锁，那么此时剩下的B、C、D节点会同时收到删除事件从而去竞争锁，这个过程会产生惊群效应。

什么是“惊群效应”呢？

简单来说就是如果存在许多的客户端在等待获取锁，当成功获取到锁的进程释放该节点后，所有处于等待状态的客户端都会被唤醒，这个时候zookeeper会在短时间内发送大量子节点变更事件给所有待获取锁的客户端，然后实际情况是只会有一个客户端获得锁。如果在集群规模比较大的情况下，会对zookeeper服务器的性能产生比较大的影响。

为了解决惊群效应，我们可以采用Zookeeper的有序节点特性来实现分布式锁。

如下图所示，每个客户端都往指定的节点下注册一个临时有序节点，越早创建的节点，节点的顺序编号就越小，那么我们可以判断子节点中最小的节点设置为获得锁。如果自己的节点不是所有子节点中最小的，意味着还没有获得锁。这个的实现和前面单节点实现的差异性在于，每个节点只需要监听比自己小的节点，当比自己小的节点删除以后，客户端会收到watcher事件，此时再次判断自己的节点是不是所有子节点中最小的，如果是则获得锁，否则就不断重复这个过程，这样就不会导致羊群效应，因为每个客户端只需要监控一个节点。

17.zookeeper的权限控制

zookeeper有ACL( Access Control List )权限控制，可以控制节点的读写操作，保证数据的安全性.

ACL权限设置由三部分组成：分别是权限模式、授权对象、权限信息。

权限模式： 就是zookeeper服务器进行权限验证的方式，大体分为两种类型：

1、范围验证： 范围就是zookeeper可以针对一个ip或者一段ip地址授予权限

2、口令验证： 可以理解为用户名密码的方式，这种就相当于密码解锁了，知道了用户名密码后所有的人都相当于授予了权限。

授权对象： 授权对象就是把权限授予给谁，如果是范围验证方式，那么授权对象就是ip地址，如果是口令验证，授权对象就是用户名。

授权信息： 授权信息就是指我们具体的权力是什么，比如我们解锁手机后可以打游戏还是可以听歌。

可以通过getAcl来获取某个节点的权限信息，通过setAcl来设置某个节点的权限信息。

18.zookeeper的数据是存储在内存中的吗，怎么进行持久化操作呢？

zookeeper和redis很像，数据都是在内存中的，持久化也是两种方式，一种是记录事务日志，一种是快照方式。

记录事务日志磁盘会进行IO操作，事务日志的不断增多会触发磁盘为文件开辟新的磁盘块，所以为了提升磁盘的效率，可以在创建文件的时候就向操作系统申请一块大一点的磁盘块，通过参数zookeeper.preAllocSize配置。

事务日志的存放地址通过zoo.cfg配置文件中的dataDir来指定。

19.Zookeeper 的典型应用场景

Zookeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员可以使用它来进行分布式数据的发布和订阅。

通过对 Zookeeper 中丰富的数据节点进行交叉使用，配合 Watcher 事件通知机制，可以非常方便的构建一系列分布式应用中年都会涉及的核心功能，如：

（1）数据发布/订阅

（2）负载均衡

（3）命名服务

（4）分布式协调/通知

（5）集群管理

（6）Zookeeper 分布式锁（文件系统、通知机制）

20.说一下 Zookeeper 的通知机制？

client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收到 zk 的通知，然后 client 可以根据 znode 变化来做出业务上的改变等。

21.Zookeeper 和 Dubbo 的关系？

Zookeeper的作用：

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务来支持高并发，服务的提供者多了能服务的客户就多了。

dubbo：

是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。 注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

zookeeper和dubbo的关系：

Dubbo 的将注册中心进行抽象，它可以外接不同的存储媒介给注册中心提供服务，有 ZooKeeper，Memcached，Redis 等。

引入了 ZooKeeper 作为存储媒介，也就把 ZooKeeper 的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个 ZooKeeper 群配合相应的 Web 应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper 集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入自己的 URL 地址，这个操作就完成了服务的发布。 其他特性还有 Master 选举，分布式锁等。

23.Zookeeper和Eueaka的区别

在Zookeeper集群中，Zookeeper的数据保证的是一致性的。当Leader出现问题时，整个Zookeeper不可用，需要花费30~120s来进行重新选择leader，当leader选举成功以后才能进行访问整个Zookeeper集群。通过这点也可以看出Zookeeper是强一致性的，集群所有节点必须能通信，才能用集群。虽然这样集群数据安全了，但是可用性大大降低了。

在Eureka集群中所有的节点都是保存完整的信息的，当Eureka Client向Eureka中注册信息时，如果发现节点不可用，会自动切换到另一台Eureka Sever，也就是说整个集群中即使只有一个Eureka可用，那么整个集群也是可用的。
 

23.RabbitMQ是什么？

rabbit是面向消息的一个中间件，也可以理解为一个很大的容器，a应用把消息发送到消息中间件，消息中间件再把消息发送给调用该消息的b、c。

24.消息队列的优点？

（1）解耦：将系统按照不同的业务功能拆分出来，消息生产者只管把消息发布到 MQ 中而不用管谁来取，消息消费者只管从 MQ 中取消息而不管是谁发布的。消息生产者和消费者都不知道对方的存在；

（2）异步：主流程只需要完成业务的核心功能；对于业务非核心功能，将消息放入到消息队列之中进行异步处理，减少请求的等待，提高系统的总体性能；

（3）削峰/限流：将所有请求都写到消息队列中，消费服务器按照自身能够处理的请求数从队列中拿到请求，防止请求并发过高将系统搞崩溃； 缺点就是系统复杂度提高、系统可用性降低（如果mq挂掉会导致整个系统崩溃）、数据一致性问题。

25.如何保证消息不被重复消费？

正常情况下，消费者在消费消息后，会给消息队列发送一个确认，消息队列接收后就知道消息已经被成功消费了，然后就从队列中删除该消息，也就不会将该消息再发送给其他消费者了。不同消息队列发出的确认消息形式不同，RabbitMQ是通过发送一个ACK确认消息。但是因为网络故障，消费者发出的确认并没有传到消息队列，导致消息队列不知道该消息已经被消费，然后就再次消息发送给了其他消费者，从而造成重复消费的情况。

重复消费问题的解决思路是：保证消息的唯一性，即使多次传输，也不让消息的多次消费带来影响，也就是保证消息幂等性；幂等性指一个操作执行任意多次所产生的影响均与一次执行的影响相同。具体解决方案如下：

（1）改造业务逻辑，使得在重复消费时也不影响最终的结果。例如对SQL语句： update t1 set money = 150 where id = 1 and money = 100; 做了个前置条件判断，即 money = 100 的情况下才会做更新，更通用的是做个 version 即版本号控制，对比消息中的版本号和数据库中的版本号。

（2）基于数据库的唯一主键进行约束。消费完消息之后，到数据库中做一个 insert 操作，如果出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。

（3）通过记录关键的key，当重复消息过来时，先判断下这个key是否已经被处理过了，如果没处理再进行下一步

26.如何保证消息不丢失，进行可靠性传输？

• 消息持久化：Exchange 设置持久化：durable:true；Queue 设置持久化；Message持久化发送。

• ACK确认机制：消息发送确认；消息接收手动确认ACK。

要从三个角度来分析：生产者丢数据、消息队列丢数据、消费者丢数据。

生产者丢数据：RabbitMQ提供事务机制（transaction）和确认机制（confirm）两种模式来确保生产者不丢消息。

（1）事务机制：

发送消息前，开启事务（channel.txSelect()），然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()），如果发送成功则提交事务（channel.txCommit()）该方式的缺点是生产者发送消息会同步阻塞等待发送结果是成功还是失败，导致生产者发送消息的吞吐量降下降。

（2）确认机制：

生产环境常用的是confirm模式。生产者将信道 channel 设置成 confirm 模式，一旦 channel 进入 confirm 模式，所有在该信道上发布的消息都将会被指派一个唯一的ID，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个确认给生产者（包含消息的唯一ID），这样生产者就知道消息已经正确到达目的队列了。如果rabbitMQ没能处理该消息，也会发送一个Nack消息给你，这时就可以进行重试操作。

Confirm模式最大的好处在于它是异步的，一旦发布消息，生产者就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者便可以通过回调方法来处理该确认消息。

消息队列丢数据

处理消息队列丢数据的情况，一般是开启持久化磁盘（发送消息的时候将 deliveryMode 设置为 2，将消息设置为持久化的）。持久化配置可以和生产者的 confirm 机制配合使用，在消息持久化磁盘后，再给生产者发送一个Ack信号。这样的话，如果消息持久化磁盘之前，即使 RabbitMQ 挂掉了，生产者也会因为收不到Ack信号而再次重发消息。这样设置以后，RabbitMQ 就算挂了，重启后也能恢复数据。在消息还没有持久化到硬盘时，可能服务已经死掉，这种情况可以通过引入镜像队列，但也不能保证消息百分百不丢失（整个集群都挂掉）

消费者丢数据

消费者丢数据一般是因为采用了自动确认消息模式。该模式下，虽然消息还在处理中，但是消费中者会自动发送一个确认，通知 RabbitMQ 已经收到消息了，这时 RabbitMQ 就会立即将消息删除。这种情况下，如果消费者出现异常而未能处理消息，那就会丢失该消息。

解决方案就是采用手动确认消息，设置 autoAck = False，等到消息被真正消费之后，再手动发送一个确认信号，即使中途消息没处理完，但是服务器宕机了，那 RabbitMQ 就收不到发的ack，然后 RabbitMQ 就会将这条消息重新分配给其他的消费者去处理。

但是 RabbitMQ 并没有使用超时机制，RabbitMQ 仅通过与消费者的连接来确认是否需要重新发送消息，也就是说，只要连接不中断，RabbitMQ 会给消费者足够长的时间来处理消息。另外，采用手动确认消息的方式，我们也需要考虑一下几种特殊情况：

如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ 会认为消息没有被消费，然后重新分发给下一个订阅的消费者，所以存在消息重复消费的隐患 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息

27.如何保证消息的有序性？

针对保证消息有序性的问题，解决方法就是保证生产者入队的顺序是有序的，出队后的顺序消费则交给消费者去保证。

（1）方法一：拆分queue，使得一个queue只对应一个消费者。由于MQ一般都能保证内部队列是先进先出的，所以把需要保持先后顺序的一组消息使用某种算法都分配到同一个消息队列中。然后只用一个消费者单线程去消费该队列，这样就能保证消费者是按照顺序进行消费的了。但是消费者的吞吐量会出现瓶颈。如果多个消费者同时消费一个队列，还是可能会出现顺序错乱的情况，这就相当于是多线程消费了。

（2）方法二：对于多线程的消费同一个队列的情况，可以使用重试机制：比如有一个微博业务场景的操作，发微博、写评论、删除微博，这三个异步操作。如果一个消费者先执行了写评论的操作，但是这时微博都还没发，写评论一定是失败的，等一段时间。等另一个消费者，先执行发微博的操作后，再执行，就可以成功。

28.如何处理消息堆积情况?

消息堆积往往是生产者的生产速度与消费者的消费速度不匹配导致的。有可能就是消费者消费能力弱，渐渐地消息就积压了，也有可能是因为消息消费失败反复复重试造成的，也有可能是消费端出了问题，导致不消费了或者消费极其慢。比如，消费端每次消费之后要写mysql，结果mysql挂了，消费端hang住了不动了，或者消费者本地依赖的一个东西挂了，导致消费者挂了。

所以如果是 bug 则处理 bug；如果是因为本身消费能力较弱，则优化消费逻辑，比如优化前是一条一条消息消费处理的，那么就可以批量处理进行优化。

临时扩容，快速处理积压的消息：

（1）先修复 consumer 的问题，确保其恢复消费速度，然后将现有的 consumer 都停掉；

（2）临时创建原先 N 倍数量的 queue ，然后写一个临时分发数据的消费者程序，将该程序部署上去消费队列中积压的数据，消费之后不做任何耗时处理，直接均匀轮询写入临时建立好的 N 倍数量的 queue 中；

（3）接着，临时征用 N 倍的机器来部署 consumer，每个 consumer 消费一个临时 queue 的数据

（4）等快速消费完积压数据之后，恢复原先部署架构 ，重新用原先的 consumer 机器消费消息。

这种做法相当于临时将 queue 资源和 consumer 资源扩大 N 倍，以正常 N 倍速度消费。

恢复队列中丢失的数据：

如果使用的是 rabbitMQ，并且设置了过期时间，消息在 queue 里积压超过一定的时间会被 rabbitmq 清理掉，导致数据丢失。这种情况下，实际上队列中没有什么消息挤压，而是丢了大量的消息。所以就不能说增加 consumer 消费积压的数据了，这种情况可以采取 “批量重导” 的方案来进行解决。在流量低峰期，写一个程序，手动去查询丢失的那部分数据，然后将消息重新发送到mq里面，把丢失的数据重新补回来。

MQ长时间未处理导致MQ写满的情况如何处理：

如果消息积压在MQ里，并且长时间都没处理掉，导致MQ都快写满了，这种情况肯定是临时扩容方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。首先，临时写个程序，连接到mq里面消费数据，消费一个丢弃一个，快速消费掉积压的消息，降低MQ的压力，然后在流量低峰期时去手动查询重导丢失的这部分数据。

预防措施

生产者层面：

• 给消息设置年龄，超时就丢弃

• 使用队列最大长度限制

• 减少发布频率

消费者层面：

• 增加消费端（减少发布频率）

• 建立新的queue，消费者同时订阅新旧queue，采用订阅模式。

综合：

生产者端缓存数据，在mq被消费完后再发送到mq，打破发送循环条件。设置合适的qos值（channel.BasicQos()方法：每次从队列拉取的消息数量），当qos值被用光，而新的ack没有被mq接收时，就可以跳出发送循环，去接收新的消息。 消费者主动block接收进程，消费者感受到接收消息过快时主动block，利用block和unblock方法调节接收速率，当接收线程被block时，跳出发送循环。

已经堆积：

• 修复consumer的问题，让他恢复消费速度，然后等待几个小时消费完毕

• 临时紧急扩容，等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息（新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量，然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue，接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据）

• 堆积的消息不需要使用的话直接删除。

29.如何保证消息队列的高可用？

RabbitMQ 是基于主从（非分布式）做高可用性的，RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式

10.1、单机模式：一般没人生产用单机模式

10.2、普通集群模式：

普通集群模式用于提高系统的吞吐量，通过添加节点来线性扩展消息队列的吞吐量。也就是在多台机器上启动多个 RabbitMQ 实例，而队列 queue 的消息只会存放在其中一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。消费的时候，如果连接到了另外的实例，那么该实例就会从数据实际所在的实例上的queue拉取消息过来，就是说让集群中多个节点来服务某个 queue 的读写操作

但普通集群模式的缺点在于：无高可用性，queue所在的节点宕机了，其他实例就无法从那个实例拉取数据；RabbitMQ 内部也会产生大量的数据传输。

镜像队列集群模式：

镜像队列集群是RabbitMQ 真正的高可用模式，集群中一般会包含一个主节点master和若干个从节点slave，如果master由于某种原因失效，那么按照slave加入的时间排序，"资历最老"的slave会被提升为新的master。

镜像队列下，所有的消息只会向master发送，再由master将命令的执行结果广播给slave，所以master与slave节点的状态是相同的。比如，每次写消息到 queue 时，master会自动将消息同步到各个slave实例的queue；如果消费者与slave建立连接并进行订阅消费，其实质上也是从master上获取消息，只不过看似是从slave上消费而已，比如消费者与slave建立了TCP连接并执行Basic.Get的操作，那么也是由slave将Basic.Get请求发往master，再由master准备好数据返回给slave，最后由slave投递给消费者。

从上面可以看出，队列的元数据和消息会存在于多个实例上，也就是说每个 RabbitMQ 节点都有这个 queue 的完整镜像，任何一个机器宕机了，其它机器节点还包含了这个 queue 的完整数据，其他消费者都可以到其它节点上去消费数据。

六、多线程

1.为什么要使用线程池？直接new个线程不是很舒服？

如果我们在方法中直接new一个线程来处理，当这个方法被调用频繁时就会创建很多线程，不仅会消耗系统资源，还会降低系统的稳定性。

如果我们合理的使用线程池，则可以避免把系统搞崩的窘境。总得来说，使用线程池可以带来以下几个好处：

（1）降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。

（2）提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。

（3）提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

2.线程池的核心属性有哪些？

threadFactory（线程工厂）：用于创建工作线程的工厂。

corePoolSize（核心线程数）：当线程池运行的线程少于 corePoolSize 时，将创建一个新线程来处理请求，即使其他工作线程处于空闲状态。

workQueue（队列）：用于保留任务并移交给工作线程的阻塞队列。

maximumPoolSize（最大线程数）：线程池允许开启的最大线程数。

handler（拒绝策略）：往线程池添加任务时，将在下面两种情况触发拒绝策略：1）线程池运行状态不是 RUNNING；2）线程池已经达到最大线程数，并且阻塞队列已满时。

keepAliveTime（保持存活时间）：如果线程池当前线程数超过 corePoolSize，则多余的线程空闲时间超过 keepAliveTime 时会被终止。

3.线程池的创建

线程池的真正实现类是 ThreadPoolExecutor，其构造方法有4种。

通过Executors执行器自动创建线程池。

public class ThreadPool {
    public static void main(String[] args) {
        //1.通过Executors执行器提供指定线程数量的线程池
        ExecutorService service = Executors.newFixedThreadPool(10);
        ThreadPoolExecutor service1 = (ThreadPoolExecutor) service;
        //1.1设置线程池的属性

//        System.out.println(service.getClass());
//        service1.setCorePoolSize(15);
//        service1.setKeepAliveTime();

        //2.执行指定的线程的操作。需要提供实现Runnable接口或Callable接口实现类的对象
        service.execute(new NumberThread());//适合适用于Runnable
        service.execute(new NumberThread1());//适合适用于Runnable

//        service.submit(Callable callable);//适合使用于Callable
        //3.关闭连接池
        service.shutdown();
    }

}

class NumberThread implements Runnable{

    @Override
    public void run() {
        for(int i = 0;i <= 100;i++){
            if(i % 2 == 0){
                System.out.println(Thread.currentThread().getName() + ": " + i);
            }
        }
    }
}

class NumberThread1 implements Runnable{

    @Override
    public void run() {
        for(int i = 0;i <= 100;i++){
            if(i % 2 != 0){
                System.out.println(Thread.currentThread().getName() + ": " + i);
            }
        }
    }
}

几个参数：

corePoolSize（必需）：核心线程数。默认情况下，核心线程会一直存活，但是当将 allowCoreThreadTimeout 设置为 true 时，核心线程也会超时回收。 maximumPoolSize（必需）：线程池所能容纳的最大线程数。当活跃线程数达到该数值后，后续的新任务将会阻塞。 keepAliveTime（必需）：线程闲置超时时长。如果超过该时长，非核心线程就会被回收。如果将 allowCoreThreadTimeout 设置为 true 时，核心线程也会超时回收。 unit（必需）：指定 keepAliveTime 参数的时间单位。常用的有：TimeUnit.MILLISECONDS（毫秒）、TimeUnit.SECONDS（秒）、TimeUnit.MINUTES（分）。 workQueue（必需）：任务队列。通过线程池的 execute() 方法提交的 Runnable 对象将存储在该参数中。其采用阻塞队列实现。 threadFactory（可选）：线程工厂。用于指定为线程池创建新线程的方式。 handler（可选）：拒绝策略。当达到最大线程数时需要执行的饱和策略。

4.线程池中的各个状态分别代表什么含义？这几个状态之间是怎么流转的？

线程池目前有5个状态：

RUNNING：接受新任务并处理排队的任务。

SHUTDOWN：不接受新任务，但处理排队的任务。

STOP：不接受新任务，不处理排队的任务，并中断正在进行的任务。

TIDYING：所有任务都已终止，workerCount 为零，线程转换到 TIDYING 状态将运行 terminated() 钩子方法。

TERMINATED：terminated() 已完成。

5.线程池有哪些队列？

常见的阻塞队列有以下几种：

ArrayBlockingQueue：基于数组结构的有界阻塞队列，按先进先出对元素进行排序。

LinkedBlockingQueue：基于链表结构的有界/无界阻塞队列，按先进先出对元素进行排序，吞吐量通常高于 ArrayBlockingQueue。Executors.newFixedThreadPool 使用了该队列。

SynchronousQueue：不是一个真正的队列，而是一种在线程之间移交的机制。要将一个元素放入 SynchronousQueue 中，必须有另一个线程正在等待接受这个元素。如果没有线程等待，并且线程池的当前大小小于最大值，那么线程池将创建一个线程，否则根据拒绝策略，这个任务将被拒绝。使用直接移交将更高效，因为任务会直接移交给执行它的线程，而不是被放在队列中，然后由工作线程从队列中提取任务。只有当线程池是无界的或者可以拒绝任务时，该队列才有实际价值。Executors.newCachedThreadPool使用了该队列。

PriorityBlockingQueue：具有优先级的无界队列，按优先级对元素进行排序。元素的优先级是通过自然顺序或 Comparator 来定义的。

6.线程池有哪些拒绝策略？

AbortPolicy：中止策略。默认的拒绝策略，直接抛出 RejectedExecutionException。调用者可以捕获这个异常，然后根据需求编写自己的处理代码。

DiscardPolicy：抛弃策略。什么都不做，直接抛弃被拒绝的任务。

DiscardOldestPolicy：抛弃最老策略。抛弃阻塞队列中最老的任务，相当于就是队列中下一个将要被执行的任务，然后重新提交被拒绝的任务。如果阻塞队列是一个优先队列，那么“抛弃最旧的”策略将导致抛弃优先级最高的任务，因此最好不要将该策略和优先级队列放在一起使用。

CallerRunsPolicy：调用者运行策略。在调用者线程中执行该任务。该策略实现了一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将任务回退到调用者（调用线程池执行任务的主线程），由于执行任务需要一定时间，因此主线程至少在一段时间内不能提交任务，从而使得线程池有时间来处理完正在执行的任务。

7. 线程只能在任务到达时才启动吗？

默认情况下，即使是核心线程也只能在新任务到达时才创建和启动。但是我们可以使用 prestartCoreThread（启动一个核心线程）或 prestartAllCoreThreads（启动全部核心线程）方法来提前启动核心线程。

8. Executors 提供了哪些创建线程池的方法？

newFixedThreadPool：固定线程数的线程池。corePoolSize = maximumPoolSize，keepAliveTime为0，工作队列使用无界的LinkedBlockingQueue。适用于为了满足资源管理的需求，而需要限制当前线程数量的场景，适用于负载比较重的服务器。

newSingleThreadExecutor：只有一个线程的线程池。corePoolSize = maximumPoolSize = 1，keepAliveTime为0， 工作队列使用无界的LinkedBlockingQueue。适用于需要保证顺序的执行各个任务的场景。

newCachedThreadPool： 按需要创建新线程的线程池。核心线程数为0，最大线程数为 Integer.MAX_VALUE，keepAliveTime为60秒，工作队列使用同步移交 SynchronousQueue。该线程池可以无限扩展，当需求增加时，可以添加新的线程，而当需求降低时会自动回收空闲线程。适用于执行很多的短期异步任务，或者是负载较轻的服务器。

newScheduledThreadPool：创建一个以延迟或定时的方式来执行任务的线程池，工作队列为 DelayedWorkQueue。适用于需要多个后台线程执行周期任务。

newWorkStealingPool：JDK 1.8 新增，用于创建一个可以窃取的线程池，底层使用 ForkJoinPool 实现。

9.在我们实际使用中，线程池的大小配置多少合适？

要想合理的配置线程池大小，首先我们需要区分任务是计算密集型还是I/O密集型。

对于计算密集型，设置 线程数 = CPU数 + 1，通常能实现最优的利用率。

对于I/O密集型，网上常见的说法是设置 线程数 = CPU数 * 2 ，这个做法是可以的，但个人觉得不是最优的。

在我们日常的开发中，我们的任务几乎是离不开I/O的，常见的网络I/O（RPC调用）、磁盘I/O（数据库操作），并且I/O的等待时间通常会占整个任务处理时间的很大一部分，在这种情况下，开启更多的线程可以让 CPU 得到更充分的使用，一个较合理的计算公式如下：

线程数 = CPU数 * CPU利用率 * (任务等待时间 / 任务计算时间 + 1)

例如我们有个定时任务，部署在4核的服务器上，该任务有100ms在计算，900ms在I/O等待，则线程数约为：4 * 1 * (1 + 900 / 100) = 40个。

当然，具体我们还要结合实际的使用场景来考虑。如果要求比较精确，可以通过压测来获取一个合理的值。

10.怎么保证线程安全？

• 第一种方法，使用Hashtable线程安全类；

• 第二种方法，使用Collections.synchronizedMap方法，对方法进行加同步锁；

• 第三种方法，使用并发包中的ConcurrentHashMap类；

七、设计模式

1.单例模式和多例模式

单例模式的关键有两点：

1、构造方法为私有，这样外界就不能随意调用。 2、get的方法为静态，由类直接调用

多例模式（Multiton）

1 、多例类可以有多个实例 2 、多例类必须能够自我创建并管理自己的实例，并向外界提供自己的实例。

什么是单例多例: 所谓单例就是所有的请求都用一个对象来处理，比如我们常用的service和dao层的对象通常都是单例的，

而多例则指每个请求用一个新的对象来处理，比如action;

单例在spring中是默认的，如果要产生多例，则在配置文件的bean中添加scope=”prototype”;

为什么用单例多例：

1).之所以用单例，是因为有一些对象我们只需要一个（比如线程池对象、缓存、系统全局配置对象等）没必要每个请求都新建一个对象，这样子既浪费CPU又浪费内存；

2).之所以用多例，是为了防止并发问题；即一个请求改变了对象的状态，此时对象又处理另一个请求，而之前请求对对象状态的改变导致了对象对另一个请求做了错误的处理；

2.单例模式的适用场景是什么样子的？

(1)需要生成唯一序列的环境；

(2)需要频繁实例化然后销毁的对象；

(3)创建对象时耗时过多或者耗资源过多，但又经常用到的对象；

(4)方便资源相互通信的环境。

3.实现java单例模式的几种模式？

(1)饿汉式—静态常量方式(线程安全)：类加载时就初始化实例，避免了多线程同步问题，天然线程安全。

饿汉式—静态代码块方式(线程安全)：其实就是在静态常量饿汉式实现上稍微变动了一下，将类的实例化放在了静态代码块中而已，其他没区别。

(2)懒汉式(线程不安全)：这是最基本的实现方式，第一次调用才初始化，实现了懒加载的特性。多线程场景下禁止使用，因为可能会产生多个对象，不再是单例。

懒汉式(线程安全，方法上加同步锁)：线程不安全懒汉式实现上唯一不同是：获取实例的getInstance()方法上加了同步锁。保证了多线程场景下的单例。但是效率会有所折损，不过还好。

(5)双重校验锁(线程安全，效率高)：此种实现中不用每次需要获得锁，减少了获取锁和等待的事件。注意volatile关键字的使用，保证了各线程对singleton静态实例域修改的可见性。

(6)静态内部类实现单例(线程安全、效率高)：这种方式下 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 SingletonHolder 类，从而实例化instance。

4.饿汉式和懒汉式的区别?

线程安全方面：饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题，懒汉式本身是非线程安全的。

资源加载和性能方面：饿汉式在类创建的同时就实例化一个静态对象出来，不管之后会不会使用这个单例，都会占据一定的内存，但是相应的，在第一次调用时速度也会更快，因为其资源已经初始化完成，而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。

八、Java Web

1、HTTP RestFul 和RPC的区别？什么时候用哪个？

1、从本质区别上看，RPC是基于TCP实现的，RestFul是基于HTTP来实现的。

2、从传输速度上来看，因为HTTP封装的数据量更多所以数据传输量更大，所以RPC的传输速度是比RestFul更快的。

3、RPC面向过程，RestFul是面向资源的。

• RPC面向过程，只发送 GET 和 POST 请求。GET用来查询信息，其他情况下一律用POST。请求参数是动词，直接描述动作本身。
• HTTP RestFul是面向资源的，使用 POST、DELETE、PUT、GET 请求，分别对应增、删、改、查操作。请求参数是名词，这个名词就是“增删改查”想要操作的对象。

4、因为HTTP协议是各个框架都普遍支持的。在to C情况下，因为不知道情况来源的框架、数据形势是什么样的，所以在网关可以使用RestFul利用http来接受。而在微服务内部的各模块之间因为各协议方案是公司内部自己定的，所以知道各种数据方式，可以使用TCP传输以使各模块之间的数据传输更快。所以可以网关和外界的数据传输使用RestFul，微服务内部的各模块之间使用RPC。

总结

RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。

HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

2、怎么选择rpc还是http？

速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩。
- 难度来看，RPC实现较为复杂，http相对比较简单
- 灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。

因此，两者都有不同的使用场景：

• 如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。
• 如果需要更加灵活，跨语言、跨平台，显然http更合适

微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用基于Http的Rest风格服务，像在公司对内系统用hsf协议，对接外部系统用微服务，调用RestTemplate这个类。

九、文件存储服务组件

1、MinIO和Fast DFS对比？

MinIO优点：

1）开发文档全面。MinIO作为一款基于Golang 编程语言开发的一款高性能的分布式式存储方案的开源项目，有十分完善的官方文档。

2）高性能。MinIO号称是目前速度最快的对象存储服务器。

3）SDK支持全面。目前MinIO支持市面主流的开发语言并且可以通过SDK快速集成快速集成使用。（SDK是一系列程序接口，文档，开发工具的集合）

4）安装部署简单。Linux环境下只需下载一个二进制文件然后执行，即可在几分钟内完成安装和配置MinIO。配置选项和变体的数量保持在最低限度，这样让失败的配置概率降低到几乎接近于0的水平。MinIO升级是通过一个简单命令完成的，这个命令可以无中断的完成MinIO的升级工作，并且不需要停机即可完成升级操作，大大降低总使用和运维成本。

5） 管理界面的支持。MinIO服务安装后，可以直接通过浏览器登录系统，完成文件夹、文件的管理。非常方便使用。

FastDFS架构：

FastDFS架构包括Tracker server（跟踪服务器）和Storage server（存储服务器），client（客户端）请求Tracker server 进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载。

• Tracker server：负责调度及负载均衡，通过Tracker server，在文件上传时可以根据一些策略找到Storage server来提供上传服务，可以将tracker称为追踪服务器或调度服务器；
• Storage server：负责文件最终存储，客户端上传的文件最终存储在storage服务器上，Storage server没有实现自己的文件系统，而是利用操作系统的文件系统来管理文件，可以将storage称为存储服务器。

FastDFS缺点：

• 没有管理界面
• 安装部署复杂度高
• 没有官方文档

十、ES

1、Elasticsearch 中的集群、节点、索引、文档、类型是什么？

集群是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名 称标识，默认情况下为"elasticsearch"。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分。
节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。MySQL =>数据库，Elasticsearch=>索引。
文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段)，但是对于通用字段应该具有相同的数据类型。MySQL => Databases => Tables => Columns / Rows，Elasticsearch=> Indices => Types =>具有属性的文档Doc。
类型是索引的逻辑类别/分区，其语义完全取决于用户。

2、Elasticsearch 中的倒排索引是什么？

倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。ES中的倒排索引其实就是 lucene 的倒排索引，区别于传统的正向索引， 倒排索引会再存储数据时将关键词和数据进行关联，保存到倒排表中，然后查询时，将查询内容进行分词后在倒排表中进行查询，最后匹配数据即可。

十一、Java基础

1、面向对象三大特性？

• 封装：隐藏对象的内部特性和行为。通过权限修饰符（比如把类的属性私有化，提供共有的方法来获取（get）和设置（set）此属性的值）。

好处：保护内部的状态，禁止对象之间的不良交互，提高模块化提高了代码的可用性和可维护性。

• 继承：从父类获取字段和方法的能力

好处：提供了代码的重用性，可以在不修改基类的情况下给现存的类添加新特性。

• 多态：父类的引用指向子类的对象（或子类的对象赋给父类的引用）

前提：① 类的继承关系  ② 方法的重写

好处：一个多态类型上的操作可以应用到其他类型的值上面