java面试总结

1排序算法

https://blog.csdn.net/weixin_39884521/article/details/120154088

2微服务

CAP理论

CAP理论是分布式架构中重要理论，分布式系统的架构设计需遵循这一原则。

• 一致性(Consistency) ： 即所有节点在同一时间具有相同的数据。
• 可用性(Availability) ： 保证每个请求不管成功或者失败都有响应。
• 分隔容忍(Partition tolerance) ： 系统中任意信息的丢失或失败不会影响系统的继续运作

CAP定律的内容是指的是在一个分布式系统中、Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼，CAP即三个英文单词的缩写，在分布式及微服务系统中统称为CAP定律或 CAP理论。

上图是一个经典的CAP定律解释图，下面我们来详细的解释下微服务、分布式经典的CAP定律相关概念。

2. Consistency（一致性）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
白话理解：
在设计或者部署一个分布式系统时，假设存在两个Redis库，分别是Redis主和Redis从库，用户在往数据库插入一笔记录 ，那么会在保存到数据库的同时也会实时的插入到Redis缓存中，并且主从库保持同步，如果这时候向数据库查询，在网络延迟的情况下，在同一时刻，Redis主和Redis从库查询到的数据应该是一致性的，每个节点的数据是相同的，不能允许有脏读。

3. Availability（可用性）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
白话理解：
假设在分布式部署中，有以下集群部署节点，如果Tomcat1出现故障，Nginx会自动做故障转移，自动将请求转移到Tomcat2和Tomcat3，Nginx故障转移可帮助我们实现集群环境的可用性

4. Partition tolerance（分区容错性）

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
白话理解：
分区容错性是指系统能够容忍节点之间的网络通信的故障，假设我们有一台Tomcat服务器，部署在全国各地，像浙江节点、上海节点、武汉节点，但是可能出现其中某个节点由于网络故障不能使用，无法进行通讯；一般来说，现实中分区容错是无法避免的，因此可以认为 CAP的 P总是成立。CAP定理告诉我们，剩下的 C 和 A 无法同时做到。

BASE基本理论

**BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）**三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

注意： 在分布式系统中，不可能存在强一致性问题

1、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3、最终一致性

最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

一、为什么使用微服务？

重点：节约成本，提高性能
举一个简单明了的例子，传统服务电商平台的重点是订单处理，如果不能下单，这个平台一切都没什么意义。当遇到双十一等活动的时候，服务器不足以支撑这么大的请求时候该怎么办？当然先可以搭建集群，当集群也不行的时候只能扩大服务器。但是其他的地方如商品管理、用户管理等不需要这么大的服务器。由于就一个订单的处理提升了整个平台的服务器，浪费了成本。所以此时就需要微服务的出现，把整个电商分解成微服务，如订单服务，用户服务，商品服务等。单独给订单服务配一个好的服务器，就解决了上诉问题。（个人理解）

二、微服务各组件的用途

1.eureka（注册中心）
所有的微服务模块统一到注册中心注册，生成注册表，进行统一管理。eureka既可以是生产者，也可以是消费者。
当然也可以搭建集群，如果其中一个eureka崩了，也不会影响其他微服务的使用，提高系统的性能。（下文会有具体搭建eureka集群的过程）

2.ribbon（负载均衡）

ribbon最牛的地方RoundRobinRule轮询算法，默认的是每个服务按顺序请求一次。
服务之间也需要进行通信，可以采用http或rpc(远程过程调用)。可以采用RestTemplate，RestTemplate内部封装了http，返回object，使用更方便快捷。

3.zuul（网关）

通俗的讲，是一个关口，想让那些东西通过就可以通过，不想让哪些东西通过就不能通过。
当请求从客服端发到服务器，如果经过网关的一系列验证和过滤符合访问要求，那么在之后访问其他微服务或由网关路由转发之后的访问时，不需要再做同样的安全认证。

4.Hystrix（熔断器）

简单来说，相当于电路中的保险丝。
举个例子说明下熔断器的用途。商品下单会调用订单服务，然后订单服务会通知仓库服务发货、订单服务通知积分服务给用户新增积分。如果积分服务挂了，每次订单服务请求积分服务线程会等待几秒钟然后返回一个异常。如果做秒杀的时候，大量的订单服务线程卡在积分服务这里，然后订单服务也挂了，完犊子，雪崩，整个服务炸了。如果第一次请求积分服务的时候发现它挂了，就不在管他，各服务都做它该做的事。这时就会用到Hystrix。最后积分服务进行降级处理，给用户一个提示，积分服务出现异常，待人工核实后添加积分。大不了最后积分服务恢复后人工进行积分处理，不影响整个服务的使用。Hystrix里面有个性能非常好，如果发现积分服务挂了，Hystrix自动打开，一段时间后，Hystrix会半开，放一个请求过积分服务，问问积分服务怎么样了，如果积分服务还挂着，Hystrix就继续打开，一旦积分服务请求成功，Hystrix自动关闭。（Hystrix小伙子是真的不错，让人也太省心了）

3.ElasticSearch

https://zhuanlan.zhihu.com/p/139762008

4.Redis

为什么那么快

• redis是纯内存操作：数据存放在内存中，内存的响应时间大约是100纳秒，这是Redis每秒万亿级别访问的重要基础。
• 非阻塞I/O：Redis采用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。
• 单线程避免了线程切换和竞态产生的消耗。
  Redis采用单线程模型，每条命令执行如果占用大量时间，会造成其他线程阻塞，对于Redis这种高性能服务是致命的，所以Redis是面向高速执行的数据库

为何不用多线程

缓存穿透、击穿、雪崩

持久化

16.Redis 持久化 地址:
http://www.redis.cn/topics/persistence.html

Redis 提供了不同级别的持久化方式

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的 操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大. 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数 据集要比RDB文件保存的数据集要完整.
  最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:

RDB的优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时 每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集. RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密)，非常适用于灾难恢复.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持 久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

• 如果你希望在redis意外停止工作(例如电源中断)的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每 隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存, 万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户 端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集 的耐久度.

AOF 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略:无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能 依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也 也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机， 现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操 作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对 文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单: 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文 件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的 状态。

AOF 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间(latency)。

如何选择使用哪种持久化方式?

• 一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
• 有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式: 因为定时生成 RDB 快照(snapshot)非常便于进行数据库备份， 并且 RDB 恢复数 据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。
  Note: 因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 (这是一个长期计划。) 接下来的几个小节将介绍 RDB 和 AOF 的更多细节。

快照

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改 动”这一条件被满足时， 自动保存一次数据集。你也可以通过调用 SAVE或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。
比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集:
1. save 60 1000

这种持久化方式被称为快照 snapshotting.


工作方式

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:
Redis 调用forks. 同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制(copy-on-write)机制中获益。

Redis事务

Redis事务的概念:
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执 行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis事务没有隔离级别的概念:
批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。
Redis不保证原子性:
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YNvrKg6G-1624002958697) (C:\Users\joker\AppData\Roaming\Typora\typora-user-images\image-20210302085845586.png)]

为什么 Redis 不支持回滚(roll back)

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。
以下是这种做法的优点:

• Redis 命令只会因为错误的语法而失败(并且这些问题不能在入队时发现)，或是命令用在了错误类型的键上面:这也就是说，从实用性
  的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你 本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

5.RabbitMQ

什么是RabbitMQ？为什么使用RabbitMQ？

答：采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦

可以用它来：解耦、异步、削峰。

为什么要使用rabbitmq

在分布式系统下具备异步,削峰,负载均衡等一系列高级功能
拥有持久化的机制，进程消息，队列中的信息也可以保存下来
实现消费者和生产者之间的解耦
对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作
可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单

使用rabbitmq的场景

• 服务间异步通信
• 顺序消费
• 定时任务
• 请求削峰

RabbitMQ有什么优缺点？

优点：

解耦
系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

异步
将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度

削峰
并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

缺点：

• 降低了系统的稳定性
  本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低

• 增加了系统的复杂性
  加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大

线程Queue，进程Queue和RabbitMQ区别

进程Queue用于父进程与子进程（或同一父进程中多个子进程）间数据传递
python自己的多个进程间交换数据或者与其他语言（如Java）进程queue就无能为力
RabbitMQ就是这样一个可以在不同程序间共享数据的代理

RabbitMQ 中的 broker 是指什么？cluster 又是指什么？

broker 是指一个或多个 erlang node 的逻辑分组，且 node 上运行着 RabbitMQ 应用程序
cluster 是在 broker 的基础之上，增加了 node 之间共享元数据的约束
RabbitMQ 概念里的 channel、exchange 和 queue 是逻辑概念，还是对应着进程实体？分别起什么作用？

queue 具有自己的 erlang 进程
exchange 内部实现为保存 binding 关系的查找表
channel 是实际进行路由工作的实体，即负责按照 routing_key 将 message 投递给 queue
由 AMQP 协议描述可知，channel 是真实 TCP 连接之上的虚拟连接，所有 AMQP 命令都是通过 channel 发送的，且每一个 channel 有唯一的 ID。一个 channel 只能被单独一个操作系统线程使用，故投递到特定 channel 上的 message 是有顺序的。但一个操作系统线程上允许使用多个 channel

消息基于什么传输？

由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制

消息如何分发？

若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）

如何确保消息正确地发送至RabbitMQ？

RabbitMQ使用发送方确认模式，确保消息正确地发送到RabbitMQ
发送方确认模式：

• 将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID
  一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）
• 如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息
• 发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息

如何确保消息接收方消费了消息？

接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）
只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除
这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息
也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息

下面列出几种特殊情况：

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

如何保证RabbitMQ的高可用？

答：没有哪个项目会搭建一台RabbitMQ服务器提供服务，风险太大；

如何保证RabbitMQ不被重复消费？

先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；

但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者

解决方法：

• 在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列
• 在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；
• 保证消息等幂性
  在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过

如何保证RabbitMQ消息的可靠传输？

答：消息不可靠的情况可能是消息丢失，劫持等原因；

丢失又分为：

1.生产者丢失消息

从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；

transaction机制就是说：

发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）
如果发送成功则提交事务（channel.txCommit()）
这种方式有个缺点：吞吐量下降
confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；

rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；

如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

消息列表丢失消息：

消息持久化。

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。

这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。

这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

那么如何持久化呢？

这里顺便说一下吧，其实也很容易，就下面两步

将queue的持久化标识durable设置为true,则代表是一个持久的队列
发送消息的时候将deliveryMode=2
这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

消费者丢失消息：

消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！

消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；

如果这时处理消息失败，就会丢失该消息；

解决方案：处理消息成功后，手动回复确认消息。

如何保证RabbitMQ消息的顺序性？

单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息

消息怎么路由？

从概念上来说，消息路由必须有三部分：交换器、路由、绑定
生产者把消息发布到交换器上；绑定决定了消息如何从路由器路由到特定的队列；消息最终到达队列，并被消费者接收。

消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。

消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。

常用的交换器主要分为一下三种：

direct：如果路由键完全匹配，消息就被投递到相应的队列
fanout：如果交换器收到消息，将会广播到所有绑定的队列上
topic：可以使来自不同源头的消息能够到达同一个队列。使用topic交换器时，可以使用通配符。比如：“*” 匹配特定位置的任意文本， “.” 把路由键分为了几部分，“#” 匹配所有规则等。
特别注意：发往topic交换器的消息不能随意的设置选择键（routing_key），必须是由"."隔开的一系列的标识符组成。

什么是元数据？元数据分为哪些类型？包括哪些内容？与 cluster 相关的元数据有哪些？元数据是如何保存的？元数据在 cluster 中是如何分布的？

在非 cluster 模式下:

元数据主要分为

Queue 元数据（queue 名字和属性等）
Exchange元数据（exchange 名字、类型和属性等）
Binding 元数据（存放路由关系的查找表）
Vhost元数据（vhost 范围内针对前三者的名字空间约束和安全属性设置）
在 cluster 模式下:

还包括 cluster 中 node 位置信息和 node 关系信息
元数据按照 erlang node 的类型确定是仅保存于 RAM 中，还是同时保存在 RAM 和 disk 上。元数据在 cluster 中是全 node 分布的。

在单node 系统和多 node 构成的 cluster 系统中声明 queue、exchange ，以及进行 binding 会有什么不同？

当你在单 node 上声明 queue 时，只要该 node 上相关元数据进行了变更，你就会得到 Queue.Declare-ok 回应；而在 cluster 上声明 queue ，则要求 cluster 上的全部 node 都要进行元数据成功更新，才会得到 Queue.Declare-ok 回应。另外，若 node 类型为 RAM node 则变更的数据仅保存在内存中，若类型为 disk node 则还要变更保存在磁盘上的数据。

死信队列&死信交换器：DLX 全称（Dead-Letter-Exchange）,称之为死信交换器，当消息变成一个死信之后，如果这个消息所在的队列存在x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换器上，这个交换器就称之为死信交换器，与这个死信交换器绑定的队列就是死信队列

消息在什么时候会变成死信?

• 消息拒绝并且没有设置重新入队
• 消息过期
• 消息堆积，并且队列达到最大长度，先入队的消息会变成DL

SpringBoot、SpringMVC、MyBatis

SpringBoot

1.对Spring的理解

2.什么是 Spring IOC 容器？

3.spring 中有多少种 IOC 容器？

4.IOC的优点：

5.IOC的实现机制：

6.什么是 spring bean？

7.Spring支持集中bead scope？

8.spring bean 容器的生命周期是什么样的？

9.什么是spring 的内部 bean？

10.什么是Spring装配？

10.1 自动装配的不同模式：

10.2 自动装配有什么局限？

11.注解

11.1 什么是基于注解的容器配置？

11.2 如何在spring中启动注解装配？

11.3 @Component, @Controller, @Repository, @Service 有何区别？

11.4 @Required注解作用

11.5 @Autowired注解作用

11.6 @RequestMapping 注解有什么用？

12.Spring DAO有什么作用？

13.Spring对象/关系映射继承模块？

14.Spring MVC框架作用？

15.DispatcherServlet

16.什么是 Spring MVC 框架的控制器？

17.Spring MVC的工作原理

1.对Spring的理解

Spring 是一个轻量级开源java web开发框架，为简化企业级应用开发而生。Spring 可以让简单的 JavaBean 实现以前只有EJB 才能 实现的功能。Spring 是一个 IOC 和 AOP 容器框架。

Spring 容器（容器：Spring 包含并管理应用中对象的生命周期和配置）的主要核心是：

控制反转（IOC），传统的 java 开发模式中，当需要一个对象时，我们会自己使用 new 或者 getInstance 等直接或者间接调用构造方法创建一个对象。而在 spring 开发模式中，spring 容器使用了工厂模式为我们创建了所需要的对象，不需要我们自己创建了，直接调用 spring 提供的对象就可以了，这是控制反转的思想。

如果我们要自己创建对象，就要自己实现工厂功能类和工厂功能类的对象实例返回factory类，即实现javabean，自定义初始化和销毁函数，factory类用@Configuration修饰；

依赖注入（DI），spring 使用 javaBean 对象的 set 方法或者带参数的构造方法为我们在创建所需对象时将其属性自动设置为所需要的值的过程，就是依赖注入的思想。

面向切面编程（AOP），在面向对象编程（oop）思想中，我们将事物纵向抽成一个个的对象。而在面向切面编程中，我们将一个个的对象某些类似的方面横向抽成一个切面，切面包含一些如权限控制、事务管理，记录日志等公用操作处理的过程就是面向切面编程的思想。AOP 底层是动态代理，如果是接口采用 JDK 动态代理，如果是类采用CGLIB 方式（创建代理对象时耗费的时间更多，但是创建的代理对象性能更好）实现动态代理。

如果 BeanPostProcessor 和 Bean 关联，则 Spring 将调用该接口的预初始化方法 postProcessBeforeInitialzation() 对 Bean 进行加工操作，此处非常重要，Spring 的 AOP 就是利用它实现的。AOP是通过代理实现的。

AOP 技术利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类 的公共行为封装到一个可重用模块，并将其名为“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。使用“横切”技术， AOP 把软件系统分为两个部分：核心关注点和横切关注点。业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。横切关注点的一个特点是，他们经常发生在核心 关注点的多处，而各处都基本相似。比如权限认证、日志、事务处理。Aop 的作用在于分 离系统中的各种关注点，将核心关注点和横切关注点分离开来。

2.什么是 Spring IOC 容器？

Spring 框架的核心是 Spring 容器。容器创建对象，将它们装配在一起，配置它们并管理它们的完整生命周期。Spring 容器使用依赖注入来管理组成应用程序的组件。容器通过读取提供的配置元数据来接收对象进行实例化、配置和组装的指令。该元数据可以通过 XML，Java 注解或 Java 代码提供。

3.spring 中有多少种 IOC 容器？

• BeanFactory - BeanFactory 就像一个包含 bean 集合的工厂类。它会在客户端要求时实例化bean。

• ApplicationContext - ApplicationContext 接口扩展了 BeanFactory 接口。它在 BeanFactory 基础上提供了一些额外的功能。

BeanFactory：
它使用懒加载；
它使用语法显式提供资源对象；
不支持国际化；
不支持基于依赖的注解；

** ApplicationContext **
它使用即时加载；
它自己创建和管理资源对象；
支持国际化；
支持基于依赖的注解；

4.IOC的优点：

它将最小化应用程序中的代码量。
它将使您的应用程序易于测试，因为它不需要单元测试用例中的任何单例或 JNDI 查找机制。
它以最小的影响和最少的侵入机制促进松耦合。
它支持即时的实例化和延迟加载服务。

5.IOC的实现机制：

Spring 中的 IoC 的实现原理就是工厂模式加反射机制。

public interface FactorySender {
public void send();
}
class MailSender implements FactorySender{

@Override
public void send() {
    System.out.println("this is a mail sender!");
}

}

class SmsSender implements FactorySender{

@Override
public void send() {
    System.out.println("this is a sms sender");
}

}

class SendFactory{
public FactorySender produce(String type){
FactorySender f=null;
try{
f=(FactorySender)Class.forName(type).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
return f;
}
}

public class usualFactory {
public static void main(String[] args){
SendFactory sendFactory=new SendFactory();
FactorySender sender=sendFactory.produce(“sms”);
sender.send();
}

}

6.什么是 spring bean？

它们是构成用户应用程序主干的对象。
Bean 由 Spring IoC 容器管理。
它们由 Spring IoC 容器实例化，配置，装配和管理。
Bean 是基于用户提供给容器的配置元数据创建。

7.Spring支持集中bead scope？

支持5种：

• Singleton：每个Spring IOC容器只有一个单实例，却不是线程安全的，更像是一个static变量，这个是个人感觉；

• Prototype：每次请求都会产生一个新的实例。

• Request - 每一次 HTTP 请求都会产生一个新的实例，并 且该 bean 仅在当前 HTTP 请求内有效。

• Session - 每一次 HTTP 请求都会产生一个新的 bean，同时该 bean 仅在当前 HTTP session 内有效。

• Global-session - 类似于标准的 HTTP Session 作用域，不过它仅仅在基于 portlet 的 web 应用中才有意义。Portlet 规范定义了全局 Session 的概念，

它被所有构成某个 portlet web 应用的各种不同的 portlet 所共享。在 global session 作用域中定义的 bean 被限定于全局 portlet Session 的生命周期范围内。如果你在 web 中使用 global session 作用域来标识 bean，那么 web会自动当成 session 类型来使用。

仅当用户使用支持 Web 的 ApplicationContext 时，最后三个才可用。

8.spring bean 容器的生命周期是什么样的？

Spring 容器根据配置中的 bean 定义实例化 bean。
Spring 使用依赖注入填充所有属性，如 bean 中所定义的配置。
如果 bean 实现 BeanNameAware 接口，则工厂通过传递 bean 的 ID 来调用 setBeanName()。
如果 bean 实现 BeanFactoryAware 接口，工厂通过传递自身的实例来调用 setBeanFactory()。
如果存在与 bean 关联的任何 BeanPostProcessors，则调用 preProcessBeforeInitialization() 方法。
如果为 bean 指定了 init 方法（ 的 init-method 属性），那么将调用它。实现 org.springframwork.beans.factory.InitializingBean 接口。
最后，如果存在与 bean 关联的任何 BeanPostProcessors，则将调用 postProcessAfterInitialization() 方法。
如果 bean 实现 DisposableBean 接口，当 spring 容器关闭时，会调用 destory()。
如果为 bean 指定了 destroy 方法（ 的 destroy-method 属性），那么将调用它。
有两个重要的 bean 生命周期方法，第一个是 setup ， 它是在容器加载 bean 的时候被调用。第二个方法是 teardown 它是在容器卸载类的时候被调用。 The bean 标签有两个重要的属性（init-method 和 destroy-method）。用它们 你可以自己定制初始化和注销方法。它们也有相应的注解（@PostConstruct 和 @PreDestroy）。

9.什么是spring 的内部 bean？

只有将 bean 用作另一个 bean 的属性时，才能将 bean 声明为内部 bean。 为了定义 bean，Spring 的基于 XML 的配置元数据在 或 中提供了 元素的使用。内部 bean 总是匿名的，它们总是作为原型。

例如，假设我们有一个 Student 类，其中引用了 Person 类。这里我们将只创建一个 Person 类实例并在 Student 中使用它。

public class Student {
private Person person;
//Setters and Getters
}
public class Person {
private String name;
private String address;
//Setters and Getters
}
<bean id=“StudentBean" class=“com.edureka.Student”>



<property name=“name” value=“Scott">
<property name=“address” value=“Bangalore">

10.什么是Spring装配？

当 bean 在 Spring 容器中组合在一起时，它被称为装配或 bean 装配。Spring 容器需要知道需要什么bean 以及容器应该如何使用依赖注入来将 bean绑定 在一起，同时装配 bean。

Spring 容器能够自动装配 bean。也就是说，可以通过检查 BeanFactory 的内容让 Spring 自动解析 bean 的协作者。

10.1 自动装配的不同模式：

• no - 这是默认设置，表示没有自动装配。应使用显式 bean 引用进行装配。
• byName - 通过参数名 自动装配，Spring 容器在配置文件中发现 bean的 autowire 属性被设置成 byname，之后容器试图匹配、装配和该 bean 的属性具有相同名字的 bean。它根据 bean 的名称注入对象依赖项。它匹配并装配其属性与 XML文件中由相同名称定义的 bean。
• byType - 它根据类型注入对象依赖项。如果属性的类型与 XML 文件中的一个 bean 名称匹配，则匹配并装配属性。
  构造函数 - 它通过调用类的构造函数来注入依赖项。它有大量的参数。
• autodetect - 首先容器尝试通过构造函数使用 autowire 装配，如果不能，则尝试通过 byType 自动装配。
• byType:： 通过参数类型自动装配，Spring 容器在配置文件中发现 bean 的 autowire 属性被设置成 byType，之后容器试图匹配、装配和该 bean 的属性具有相同类型的 bean。如果有多个 bean 符合条件，则抛出错误。
• constructor：这个方式类似于 byType， 但是要提供给构造器参数，如果没有确定的带参数的构造器参数类型，将会抛出异常。
• autodetect： 首先尝试使用 constructor 来自动装配，如果无法工作， 则使用 byType 方式。

10.2 自动装配有什么局限？

覆盖的可能性 - 您始终可以使用 和 设置指定依赖项，这将覆盖自动装配。基本元数据类型 - 简单属性（如原数据类型，字符串和类）无法自动装配。令人困惑的性质 - 总是喜欢使用明确的装配，因为自动装配不太精确。

11.注解

11.1 什么是基于注解的容器配置？

不使用 XML 来描述 bean 装配，开发人员通过在相关的类，方法或字段声明上使用注解将配置移动到组件类本身。它可以作为 XML 设置的替代方案。例如：

Spring 的 Java 配置是通过使用 @Bean 和 @Configuration 来实现。

@Bean 注解扮演与bean元素相同的角色； @Configuration 类允许通过简单地调用同一个类中的其他 @Bean 方法来定义 bean 间依赖关系。

@Configuration
public class StudentConfig {
@Bean
public StudentBean myStudent() {
return new StudentBean();
}
}

11.2 如何在spring中启动注解装配？

默认情况下，Spring 容器中未打开注解装配。因此，要使用基于注解装配，我们必须通过配置<context：annotation-config/> 元素在 Spring 配置文件中启用它。

11.3 @Component, @Controller, @Repository, @Service 有何区别？

@Component ：这将 java 类标记为 bean。它是任何 Spring 管理组件的通用构造型。spring 的组件扫描机制现在可以将其拾取并将其拉入应用程序环境中。

@Controller ：这将一个类标记为 Spring Web MVC 控制器，标有它的Bean 会自动导入到 IoC 容器中。

@Service ：此注解是组件注解的特化。它不会对 @Component 注解提供任何其他行为。您可以在服务层类中使用@Service 而不是 @Component，因为它以更好的方式指定了意图。

@Repository ：这个注解是具有类似用途和功能的 @Component 注解的特化。它为 DAO 提供了额外的好处。它将 DAO 导入 IoC 容器，并使未经检查的异常有资格转换为 Spring DataAccessException。

Springboot：@Controller@Autowired @Mapper @Service@Repository

11.4 @Required注解作用

@Required 应用于 bean 属性 setter 方法。此注解仅指示必须在配置时使用 bean 定义中的显式属性值或使用自动装配填充受影响的 bean 属性。如果尚未填充受影响的 bean 属性，则容器将抛出 BeanInitializationException。

public class Employee {
private String name;
@Required
public void setName(String name){
this.name=name;
}
public string getName(){
return name;
}
}

11.5 @Autowired注解作用

@Autowired 可以更准确地控制应该在何处以及如何进行自动装配。此注解用于在 setter 方法，构造函数，具有任意名称或多个参数的属性或方法上自动装配 bean。默认情况下，它是类型驱动的注入。

@Required：该注解应用于设值方法

@Autowired：该注解应用于有值设值方法、非设值方法、构造方法和变量。

@Qualifier：该注解和@Autowired 搭配使用，用于消除特定 bean 自动装配的歧义。

public class Employee {
private String name;
@Autowired
public void setName(String name) {
this.name=name;
}
public string getName(){
return name;
}
}

11.6 @RequestMapping 注解有什么用？

@RequestMapping 注解用于将特定 HTTP 请求方法映射到将处理相应请求的控制器中的特定类/方法。此注释可应用于两个级别：

类级别：映射请求的 URL 方法级别：映射 URL 以及 HTTP 请求方法。

12.Spring DAO有什么作用？

Spring DAO 使得 JDBC，Hibernate 或 JDO 这样的数据访问技术更容易以一种统一的方式工作。这使得用户容易在持久性技术之间切换。它还允许您在编写代码时，无需考虑捕获每种技术不同的异常。

13.Spring对象/关系映射继承模块？

Spring 通过提供 ORM 模块，支持我们在直接 JDBC 之上使用一个对象/关系映射 映射(ORM)工具，Spring 支持集成主流的 ORM 框架，如 Hiberate,JDO 和 iBATIS SQL Maps。Spring 的事务管理同样支持以上所有 ORM 框架及 JDBC。

14.Spring MVC框架作用？

Spring Web MVC 框架提供 模型-视图-控制器 架构和随时可用的组件，用于开发灵活且松散耦合的 Web 应用程序。MVC 模式有助于分离应用程序的不同方面，如输入逻辑，业务逻辑和 UI 逻辑，同时在所有这些元素之间提供松散耦合。

15.DispatcherServlet

Spring 的 MVC 框架是围绕 DispatcherServlet 来设计的，它用来处理所有的 HTTP请求和响应。

16.什么是 Spring MVC 框架的控制器？

控制器提供一个访问应用程序的行为，此行为通常通过服务接口实现。控制器解析用户输入并将其转换为一个由视图呈现给用户的模型。Spring 用一个非常抽象的方式实现了一个控制层，允许用户创建多种用途的控制器。

17.Spring MVC的工作原理

a. 用户向服务器发送HTTP请求，请求被 springMVC 前端控制器 DispatchServlet 捕获；

b. DispatcherServlet 对请求进行解析，得到请求资源标识符（URL），然后根据该 URL 调用HandlerMapping 将请求映射到处理器 HandlerExecutionChain；

c. DispatchServlet 根据获得 Handler 选择一个合适的 HandlerAdapter 适配器处理；

d. Handler 对数据处理完成以后将返回一个 ModelAndView（）对象给 DisPatcherServlet;

e. Handler 返回的 ModelAndView()只是一个逻辑视图并不是一个正式的视图，DispatcherSevlet 通过ViewResolver 视图解析器将逻辑视图转化为真正的视图 View;

h. DispatcherServle 通过 model 解析出 ModelAndView()中的参数进行解析最终展现出完整的 view 并

返回给客户端;

MyBatis

MyBatis是什么？

MyBatis 是一款优秀的持久层框架，一个半 ORM（对象关系映射）框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生类型、接口和 Java 的 POJO（Plain Old Java Objects，普通老式 Java 对象）为数据库中的记录。

ORM是什么

ORM（Object Relational Mapping），对象关系映射，是一种为了解决关系型数据库数据与简单Java对象（POJO）的映射关系的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系型数据库中。

为什么说Mybatis是半自动ORM映射工具？它与全自动的区别在哪里？

Hibernate属于全自动ORM映射工具，使用Hibernate查询关联对象或者关联集合对象时，可以根据对象关系模型直接获取，所以它是全自动的。

而Mybatis在查询关联对象或关联集合对象时，需要手动编写sql来完成，所以，称之为半自动ORM映射工具。

传统JDBC开发存在的问题

• 频繁创建数据库连接对象、释放，容易造成系统资源浪费，影响系统性能。可以使用连接池解决这个问题。但是使用jdbc需要自己实现连接池。
• sql语句定义、参数设置、结果集处理存在硬编码。实际项目中sql语句变化的可能性较大，一旦发生变化，需要修改java代码，系统需要重新编译，重新发布。不好维护。
• 使用preparedStatement向占有位符号传参数存在硬编码，因为sql语句的where条件不一定，可能多也可能少，修改sql还要修改代码，系统不易维护。
• 结果集处理存在重复代码，处理麻烦。如果可以映射成Java对象会比较方便。

JDBC编程有哪些不足之处，MyBatis是如何解决这些问题的？

1、数据库链接创建、释放频繁造成系统资源浪费从而影响系统性能，如果使用数据库连接池可解决此问题。

解决：在mybatis-config.xml中配置数据链接池，使用连接池管理数据库连接。

2、Sql语句写在代码中造成代码不易维护，实际应用sql变化的可能较大，sql变动需要改变java代码。

解决：将Sql语句配置在XXXXmapper.xml文件中与java代码分离。

3、向sql语句传参数麻烦，因为sql语句的where条件不一定，可能多也可能少，占位符需要和参数一一对应。

解决： Mybatis自动将java对象映射至sql语句。

4、对结果集解析麻烦，sql变化导致解析代码变化，且解析前需要遍历，如果能将数据库记录封装成pojo对象解析比较方便。

解决：Mybatis自动将sql执行结果映射至java对象。

Mybatis优缺点

优点

与传统的数据库访问技术相比，ORM有以下优点：

• 基于SQL语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL写在XML里，解除sql与程序代码的耦合，便于统一管理；提供XML标签，支持编写动态SQL语句，并可重用
• 与JDBC相比，减少了50%以上的代码量，消除了JDBC大量冗余的代码，不需要手动开关连接
• 很好的与各种数据库兼容（因为MyBatis使用JDBC来连接数据库，所以只要JDBC支持的数据库MyBatis都支持）
• 提供映射标签，支持对象与数据库的ORM字段关系映射；提供对象关系映射标签，支持对象关系组件维护
  能够与Spring很好的集成

缺点

• SQL语句的编写工作量较大，尤其当字段多、关联表多时，对开发人员编写SQL语句的功底有一定要求
• SQL语句依赖于数据库，导致数据库移植性差，不能随意更换数据库

MyBatis框架适用场景

MyBatis专注于SQL本身，是一个足够灵活的DAO层解决方案。
对性能的要求很高，或者需求变化较多的项目，如互联网项目，MyBatis将是不错的选择。