黑马Java面试笔记之 消息中间件篇（RabbitMQ）

一. 消息丢失问题

RabbitMQ如何保证消息不丢失？

 使用场景有：

• 异步发送（验证码、短信、邮件... ）
• MYSQL和Redis，ES之间的数据同步
• 分布式事务
• 削峰填谷
• ...... 

消息丢失原因会有三种情况，分别分析一下

1.1 生产者确认机制

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

1.2 消息持久化

        MQ默认是内存存储消息，开启持久化功能可以确保缓存MQ中的消息不丢失。

1.交换机持久化

2.队列持久化

3.消息持久化，SpringAMQP中的消息默认是持久的，可以通过MessageProperties中的DeliveryMode来指定

1.3 消费者确认

        RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

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

总结：

面试官：RabbitMQ如何保证消息不丢失？

候选人：

        我们使用RabbitMQ来确保MySQL和Redis间数据双写的一致性，这要求我们实现消息的高可用性，具体措施包括：

1. 开启生产者确认机制，确保消息能被送达队列，如有错误则记录日志并修复数据。

2. 启用持久化功能，保证消息在未消费前不会在队列中丢失，需要对交换机、队列和消息本身都进行持久化。

3. 对消费者开启自动确认机制，并设置重试次数。例如，我们设置了3次重试，若失败则将消息发送至异常交换机，由人工处理。

二. RabbitMQ消息的重复消费问题

解决方案：

• 每条消息设置一个唯一的标识id
• 幂等方案：分布式锁、数据库锁（悲观锁，乐观锁）

总结

面试官：RabbitMQ消息的重复消费问题如何解决？

• 候选人：我们遇到过消息重复消费的问题，处理方法是：

• 设置消费者为自动确认模式，如果服务在确认前宕机，重启后可能会再次消费同一消息。

• 通过业务唯一标识检查数据库中数据是否存在，若不存在则处理消息，若存在则忽略，避免重复消费。

三. RabbitMQ死信交换机

RabbitMQ中死信交换机？（RabbitMQ延迟队列有了解过吗？）

• 延迟队列：进入队列的消息会被延迟消费的队列
• 场景：超时订单、限时优惠、定时发布

3.1 死信交换机

        当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

• 消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false
• 消息是一个过期消息，超时无人消费
• 要投递的队列消息堆积满了，最早的消息可能成为死信

如果该队列设置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange,简称DLX）

3.2 TTL

        TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况：

• 消息所在队列设置了存活时间
• 消息本身设置了存活时间

3.3 延迟队列插件

DelayExchange插件，需要安装在RabbitMQ中

RabbitMQ有一个官方的插件社区，地址为 http://www.rabbitmq.com/community-plugins.html

        DelayExchange的本质还是官方的三种交换机，只是添加了延迟功能。因此使用时只需要声明一个交换机，交换机的类型可以是任意类型，然后设定delayed属性为true即可。

总结

面试官：RabbitMQ中死信交换机？（RabbitMQ延迟队列有了解过吗？）

候选人：了解。我们项目中使用RabbitMQ实现延迟队列，主要通过死信交换机和TTL（消息存活时间）来实现。

• 消息若超时未消费则变为死信，队列可绑定死信交换机，实现延迟功能。

• 另一种方法是安装RabbitMQ的死信插件，简化配置，在声明交换机时指定为死信交换机，并设置消息超时时间。

四. 消息堆积

        当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，知道队列存储消息达到上限，之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题

4.1 惰性队列

惰性队列特征如下：

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

总结

五. RabbitMQ的高可用机制

RabbitMQ的高可用机制有了解过吗?

5.1 普通集群

        普通集群，或者叫标准集群（classic cluster），具备以下特征：

• 会在集群的各个节点间共享部分数据，包括：交换机，队列元信息。不包含队列中的消息
• 当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回
• 队列所在节点宕机，队列中的消息就会丢失

5.2 镜像集群

        镜像集群：本质是主从模式，具备下面的特征：

• 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份
• 创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点
• 一个队列的主节点可能是另外一个队列的镜像节点
• 所有操作都是主节点完成，然后同步给镜像节点
• 主宕机后，镜像节点会替代新的主节点

5.3 仲裁队列

        仲裁队列：仲裁队列时3.8版本以后才有的新功能，用来替代镜像队列，具备下列特征：

• 与镜像队列一样，都是主从模式，支持主从数据同步
• 使用非常简单，没有复杂的配置
• 主从同步基于Raft协议，强一致

总结