面试题：
如何确保RabbitMQ消息的可靠性？
1.开启生产者确认机制，确保生产者的消息能到达队列
2.开启持久化功能，确保消息未消费前在队列中不会丢失
3.开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
4.开启消费者失败重试机制，并设置MessageRecoverer，多次重试失败后将消息投递到异常交换机，交由人工处理
延迟消息问题
高可用问题：
1.普通集群：不能保证高可用
2.镜像集群：主从架构，可以有一个主节点，多个从节点，主节点宕机，从节点升级成主节点，保证高可用。缺点：一致性比较弱
3.3.8版本后出现仲裁队列，本质上还是主从，搭建简单，增加了Raft协议算法，加强了一致性
如何解决消息堆积问题：
1.增加更多消费者，提高消费者速度
2.在消费者内开启线程池加快消息处理速度
3.扩大队列容积，提高堆积上限
消息可靠性问题：
消息从生产者发送到交换机（exchange），再到队列（queue），再到消费者，有哪些可能性会导致消息丢失？
1.发送时丢失：
- 生产者发送的消息未送达交换机- 消息到达交换机后未到达队列中
2.MQ宕机，队列讲消息丢失
3.消费者接受的消息后未消费就宕机
针对这些问题，RabbitMQ分别给出了解决方案：
- 生产者确认机制
- publisher-confirm，发送者确认：
- 消息成功投递到交换机，返回ack
- 消息未投递到交换机，返回nack
- 消息发送过程中出现异常，没有收到回执
- publisher-return，发送者回执：
- 消息投递到交换机了，但是没有路由到队列。返回ACK，及路由失败原因。
- mq持久化（消息持久化）：MQ中交换机、队列、消息都可以设置内存存储或持久化到硬盘
- 交换机持久化：
- @Bean
public DirectExchange simpleExchange(){
// 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
return new DirectExchange(“simple.direct”, true, false);
}
- 队列持久化：
- @Bean
public Queue simpleQueue(){<br />_ //false： 表示非持久化, 默认为true_<br /> return new Queue("simple.queue",true);<br /> }
- 消息持久化，SpringAMQP中的消息默认是持久的，可以通过MessageProperties中的DeliveryMode来指定的：
- Message build = MessageBuilder._withBody_(message.getBytes(StandardCharsets._UTF_8_))<br /> _//NON_PERSISTENT表示非持久化<br /> _.setDeliveryMode(MessageDeliveryMode._PERSISTENT_) <br /> .build();
- 消费者确认机制
- RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：
- manual：手动ack，需要在业务代码结束后，调用api发送ack。
- auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack
- none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即删除。
- 配置方式是修改消费者yml文件，添加下面配置
- spring:
- rabbitmq:
- listener:
- simple:
- prefetch: 1
- #none：关闭ack；manual：手动ack；auto：自动ack
- acknowledge-mode: none
- 失败重试机制
- 当消费者出现异常后，消息会不断重新入队列，再重新发送给消费者，然后再次异常无限循环
- 配置方式是修改消费者yml文件，添加下面配置
- spring:
- rabbitmq:
- listener:
- simple:
- retry:
- enabled: true # 开启消费者失败重试
- initial-interval: 1000ms # 初识的失败等待时长为1秒
- # 失败的等待时长倍数，下次等待时长 = multiplier * last-interval
- multiplier: 1
- max-attempts: 3 # 最大重试次数
- # true无状态；false有状态。如果业务中包含事务，这里改为false
- stateless: true
- 在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecoverer接口来处理，它包含三种不同的实现：
- RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式
- ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
- RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机
死信交换机
初识死信交换机
当一个队列中的消息满足下列情况之一时，可以成为死信
1.消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false
2.消息是一个过期消息，超时无人消费
3.要投递的队列消息堆积满了，最早的消息可能成为死信
如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机。
什么样的消息会成为死信？
1.消息被消费者reject或者返回nack
2.消息超时未消费
3.队列满了
如何给队列绑定死信交换机？
1.给队列设置dead-letter-exchange属性，指定一个交换机
2.给队列设置dead-letter-routing-key属性，设置死信交换机与死信队列的RoutingKey
TTL
TTL，也就是Time-To-Live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况：
1.消息所在的队列设置了存活时间
2.消息本身设置了存活时间
消息超时的两种方式是？
1.给队列设置ttl属性，进入队列后超过ttl时间的消息变为死信
2.给消息设置ttl属性，队列接收到消息超过ttl时间后变为死信
3.两者共存时，以时间短的ttl为准
如何实现发送一个消息20秒后消费者才收到消息？
1.给消息的目标队列指定死信交换机
2.消费者监听与死信交换机绑定的队列
3.发送消息时给消息设置ttl为20秒
延迟队列
利用TTL结合死信交换机，我们实现了消息发出后，消费者延迟收到消息的效果。这种消息模式就称为延迟队列模式
延迟队列的使用场景包括：
延迟发送短信
用户下单，如果用户在15分组内未支付，则自动取消
预约工作会议，20分钟后自动通知所有参会人员
延迟队列插件的使用步骤包括哪些？
1.声明一个交换机，添加delayed属性为true
2.发送消息时，添加x-delay头，值为超时时间
惰性队列
消息堆积问题
当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积问题
解决消息堆积有三种思路：
1.增加更多消费者，提高消费者速度
2.在消费者内开启线程池加快消息处理速度
3.扩大队列容积，提高堆积上限
惰性队列的特征：
1.接收到消息后直接存入磁盘而非内存
2.消费者要消费消息时才会从磁盘中读取并加载到内存
3.支持数百万条的消息存储
惰性队列的优点有哪些？
1.基于磁盘存储，消息上限高
2.没有间歇性的page-out，性能比较稳定
惰性队列的缺点有哪些？
MQ集群
集群分类：RabbitMQ的是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。RabbitMQ的集群有两种模式：
普通集群：是一种分布式集群，将队列分散到集群的各个节点，从而提高整个集群的并发能力
镜像集群：是一种主从集群，普通集群的基础上，添加了主从备份功能，提高集群的数据可用性。
镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来代替镜像集群，底层采用Raft协议确保主从的数据一致性。
普通集群：也叫标准集群，具备以下特征：
1.会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。不包含队列中的消息。
2.当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回
3.队列所在节点宕机，队列中的消息就会丢失
镜像集群：本质是主从模式，具备以下特征：
1.交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份
2.创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点
3.所有操作都是主节点完成，然后同步给镜像节点
4.主节点宕机后，镜像节点会替代成新的主节点
仲裁队列：仲裁队列是3.8版本后才有的新功能，用来替代镜像队列，具备以下特征：
1.与镜像队列一样，都是主从模式，支持主从数据同步
2.使用非常简单，没有复杂的配置
3.主从同步基于Raft协议，强一致
若有收获，就点个赞吧
0 人点赞
