1.马上就要到了程序员的黄金时间了，也就是所谓的金三银四，作为一个实习生的我，也安耐不住我内心的骚动，也想试水自由市场，但是大家也都明白，不准备些面试题，是无法为自己加分的，我打算每周在上班之余抽时间研究一项技术，来和大家一起分享，打算研究的技术，都是现在比较主流的东西，弄明白了，基本面试就稳了，预计会在以后推出
- Redis
- RabbitMQ
- SpringCloud组件
- ElasticSearch
- Spring Security Oauth2
- zokeerper
- 其他
希望大家能够时刻关注我的，都会是第一手面试的资源和大家分享
2.废话不多说，直接进入今天的主题，由于是RabbitMQ的面试专题，一些rabbitmq是什么，怎么用我就不过多解释，默认大家都使用过rabbitmq，那下面进入今天的主题
3.RabbitMQ常见的面试题
3.1 .rabbitmq的工作原理(架构图)
3.2介绍下RabbitMQ的几种工作模式
1、Work queues
一条消息只会被一个消费者接收，rabbitmq采用轮询的方式将消息平均发给消费者的，消费者在处理完某条消息才会收到下一条消息
应用场景：
2、Publish/Subscribe（发布订阅模式）
每个消费者监听自己的队列，生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息
3、Routing（路由模式）
每个消费者监听自己的队列，并且设置routingkey，生产者将消息发给交换机，由交换机根据routingkey来转发消息到指定的队列。
4、Topics（通配符）
每个消费者监听自己的队列，并且设置带统配符的routingkey，
生产者将消息发给broker，由交换机根据routingkey来转发消息到指定的队列。
5、Header
6、RPC
3.3讲一下，为什么使用MQ
服务间高度解耦，异步通信性能高，流量削峰
不过这一点最好结合项目来说，我现在就在弄cms系统生成静态页面，用rabbitmq发送消息告知，等下好好把这个问题补充下
3.4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？
发送方确认模式：将信道设置为confirm模式（发送发确认模式），则所有在信道上发布的消息，都会被指派
一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息
接收方确认机制：消费者接收的每一条消息后，都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息
3.5如何避免消息重复投递或者重复消费
在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。
3.6如何确保消息不丢失
消息持久化，当然前提是队列必须持久化
消息持久化的前提是：将交换器/队列的durable属性设置为true，表示交换器/队列是持久交换器/队列，在服务器崩溃或重启之后不需要重新创建交换器/队列（交换器/队列会自动创建）
RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。