最新RabbitMQ面试题

AMQP和JMS分别是什么 ,区别是什么?

答:

1. AMQP:是高级消息队列协议(SpringBoot内置了启动器) 定义数据的格式:json , 二进制 跨语言的
2. JMS:定义了操作消息的接口规范:发送消息,接收消息 只能用java
3. 两者的区别和联系:
   - JMS是定义了统一的接口,来对消息操作进行统一,AMQP是通过规定协议来统一数据交互的格式.
   - JMS限定了必须使用Java语言,AMMQP只是协议,不规定实现方式,是跨语言的.
   - JMS规定了两种消息模型,分别是点对点,和发布订阅两种,而AMQP的消息模型更加丰富.

为什么使用消息队列

答：

1. 解耦、异步、削峰

消息队列的优点与缺点

答：

1. 优点：解耦、异步、削峰
2. 缺点：
   • 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。例如：A系统直播调用BC两个系统就可以了，偏要加MQ进来，万一MQ挂了，整套系统就崩溃了。
   • 系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？
   • 一致性问题：A系统处理完了直接返回成功，人都以为你这个请求成功了，但是要是BC两个系统中有一个失败，数据就不一致了

如何保证消息队列高可用

使用镜像集群模式，在该模式下，你创建的queue，无论是元数据还是queue里面的消息 都会存在于多个Rabbit实例上，就是说，每个RabbitMQ节点都有这个queue的一个完整镜像，包含queue的全部数据的意思，然后每次你写消息到queue的时候，都会自动 把消息同步到多个实例的queue上

参考文章

保证消息不被重复消费(幂等)

• 举个例子吧。假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。
  一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性。

• 幂等性，通俗点说，就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错。

解决：

• 可以让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可
• 可以用Map集合，map集合中存储着一个标识，如果这个标识没有 ，可以进行处理，如果有，可以丢弃
• 基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。

消息丢失怎么办？

1. 生产者丢失数据：
   • . 开启confirm模式，每次写消息都会分配一个 唯一的id，然后成功写入到RabbitMQ中，RabbitMQ会返回一个ack消息，如果 RabbitMQ 没能处理这个消息，会回调你的一个 nack 接口，告诉你这个消息接收失败，你可以重试，
   • 开启Rabbit事务机制(不推荐)，不过事务机制和 cnofirm 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的
2. RabbitMQ 弄丢了数据:开启Rabbit持久化，就是消息写入之后会持久化到磁盘

   • 设置持久化有两个步骤：
     创建 queue 的时候将其设置为持久化
     这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。
     第二个是发送消息的时候将消息的 deliveryMode 设置为 2
     就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。
     必须要同时设置这两个持久化才行，RabbitMQ 哪怕是挂了，再次重启，也会从磁盘上重启恢复 queue，恢复这个 queue 里的数据。

   • 注意 哪怕是你给 RabbitMQ 开启了持久化机制，也有一种可能，就是这个消息写到了 RabbitMQ 中，但是还没来得及持久化到磁盘上，结果不巧，此时 RabbitMQ 挂了，就会导致内存里的一点点数据丢失。

     所以，持久化可以跟生产者那边的 confirm 机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 ack 了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到 ack，你也是可以自己重发的。

3. 消费端弄丢了数据:
   • 关闭 RabbitMQ 的自动 ack，等程序代码里确保处理完的时候，再在程序里 手动ack 一把。这样的话，如果你还没处理完，不就没有 ack 了？那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的

有几百万消息持续积压几小时如何解决？

回答思路：修复消费者，临时紧急扩容
方案一：
- 想办法修复consumer，然后让他慢慢把消息队列的消息消费完。这个是一个很low的办法，不要在面试这样答。
方案二：

• 1、先修复consumer的问题，确保其恢复消费速度，修复完成之后，先停掉它，停止所有的consumer
• 2、然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的N倍数量的queue
• 3、然后再搞N台机器去把临时queue的数据消费掉
• 4、等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息.