一周一个技术点之-----------------RibbitMQ面试必备
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来转发消息到指定的队列。
3.3讲一下，为什么使用MQ
服务间高度解耦，异步通信性能高，流量削峰
1.服务间的解耦
这个问题我需要介绍下不用mq的情况，结合项目的业务场景来说下
不使用mq的场景：
不用mq的话，A系统需要在自己的代码里面分别调这些系统，给这些系统发送消息，这些其实也没啥，怕的就是，有一天突然B系统又不需要了，你又要去修改代码，维护起来相对比较麻烦，还有就是在A系统调用别的系统的时候，还要保证别的系统不能挂了总体来说，A系统和一些乱七八糟的系统结合在一起，导致系统的耦合性非常高，维护起来也很不方便。如果使用了mq，A系统只需要把产生的一条数据放到mq里面，别的系统只需要自己根据需要去mq去消费即可，A系统就不用和别的系统耦合到一块了，这就是mq的解耦的最明确的体现。
使用mq的情况：
2.mq的异步通信
不使用mq的时候，系统调用的时间，将会是几个系统耗时的相加，如下图：
使用mq之后
系统从A到返回结果，只是自己系统执行sql和发送mq的时间，可以节省很多时间，提高用户体验。
3.mq的削峰问题
比如说系统的某一个阶段的高峰期会有很多的用户请求过来，达到每秒钟上百万，这样的请求如果一下直接来访问我们的底层数据库，应该会把我们的底层数据库搞崩，如图：
这样我们可以利用mq把请求发送到mq上，而我们的系统还按照自己的消费速度去读取消息，等过了高峰期，我们的系统就能处理好这些积压的消息，如图：
3.4mq如何保证高可用
镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
3.4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？
发送方确认模式：将信道设置为confirm模式（发送发确认模式），则所有在信道上发布的消息，都会被指派
一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息
接收方确认机制：消费者接收的每一条消息后，都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息
3.5如何避免消息重复投递或者重复消费
1.在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。
2.比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
3.再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
3.6如何确保消息不丢失
消息持久化，当然前提是队列必须持久化
消息持久化的前提是：将交换器/队列的durable属性设置为true，表示交换器/队列是持久交换器/队列，在服务器崩溃或重启之后不需要重新创建交换器/队列（交换器/队列会自动创建）
RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。