消息中间件常见面试题（RabbitMQ）

MQ场景：

• 异步发送（验证码、短信、邮件）
• MySQL、Redis、ES之间的数据同步
• 分布式事务等

一、RabbitMQ

1.1 消息不丢失

提问：如果保证消息不丢失呢？

流程：生产者将消息发送给交换机，交换机发送给指定的消息队列中，消费者再从消息队列中取出消息

（1） 消息丢失的原因：

1. 生产者发送给交换机的过程中就丢失了消息，

2. 交换机发送到指定的队列中消息丢失了，

3. 消费者还没来得及消费消息的过程中丢失消息。

RabbitMQ中提供了publisher comfirm机制来避免消息发送到MQ的过程中丢失，消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。

（2） 消息发送失败的后处理方式：

• 回调方法即时重发
• 记录日志
• 保存到数据库然后定时重发，成功发送后即刻删除表中的数据

 

（3） 开启消息持久化

因为MQ默认是内存存储消息，重启或者宕机会导致消息的丢失，所以要开启消息持久化的功能，保证缓存在MQ中的消息不丢失

1.交换机持久化

2.队列持久化

3.消息持久化

（4） 消费者确认

RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息（也就是确保消费者消息了消息，才从消息将消息队列中对应的消息删除）

SpringAMQP的配置三种确认模式：

• manual：手动ack，需要业务代码结束后，调用api发送ack
• auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack
• none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除

利用Spring的retry机制，在消费者出现异常时进行本地重试，设置重试次数，当次数达到之后，如果消息任然失败，则将消息投递到异常交换机，由人工处理。

1.2 消息重复消费

当服务发送网络问题或服务宕机导致出现RabbiMQ消息的重复消费问题

解决方案：

给每条消息设置唯一的标识

幂等方案有分布式锁、数据库锁（悲观锁、乐观锁）

1.3 消息堆积 

当生产者生成消息的速度大于消费者消费消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限，之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

解决消息堆积的三种思路:

• 增加更多的消费者，提高消费速度
• 在消费者内开启线程池加快消息处理速度
• 扩大队列容器，提高堆积上限，采用惰性队列

惰性队列

• 接收到消息后直接存入磁盘而非内存
• 消费者要消费消息时才会从磁盘中读取并加载到内存
• 支持数百万条的消息存储

1.4 延迟队列（死信队列）

延迟队列：进入队列的消息会被延迟消费的队列

场景：超时订单、限时优惠、定时发布

延时队列 相当于 死信交换机 + TTL（生存时间）

消息超时未消费都会进入死信队列中，再通过对死信队列中的消息进行消费

1.5 高可用机制

RabbitMQ的镜像队列功能允许队列在不同的节点上拥有多个副本。如果主节点发生故障，一个副本可以自动升级为新的主节点。在主从同步完成之前，主节点就已经宕机，可能出现数据丢失。

出现数据丢失如何解决呢？

我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，强一致性。

使用方式：

只需要在声明队列时指定这个是仲裁队列即可。