0


RabbitMQ面试题

RabbitMQ面试题

RabbitMQ如何保证消息不丢失

出现消息丢失可能会出现在以下场景:

  • 异步发送(验证码,短信,邮件)
  • MySQL和Redis,ES之间的数据同步
  • 分布式事务
  • 削峰消谷

总结为:消息未达到交换机,消息未达到队列,队列中丢失消息,消费者未接收到消息

  1. 解决办法:生产者确认机制:

生产者确认机制是指生产者发送消息后,需要等待RabbitMQ服务器的确认消息,以确保消息已经被成功地发送到RabbitMQ服务器。如果RabbitMQ服务器没有收到消息或者消息发送失败,生产者会收到一个确认消息,从而可以进行重发或者其他处理。

消息失败之后如何处理呢?

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

MQ宕机导致消息丢失:

  1. 解决办法:消息持久化

MQ默认是内存存储消息,开启持久化可以确保缓存中MQ消息不丢失

主要是交换机,队列,消息持久化

交换机持久化

@BeanpublicDirectExchangesimpleExchange(){//三个参数分别是:交换机名称,durable是否持久化,autoDelete是否自动删除returnnewDirectExchange("simple.direct",true,true);}

队列持久化

@BeanpublicQueuesimpleQueue1(){//使用QueueBuilder创建队列,durable就是持久化returnQueueBuilder.durable("simple.queue1").build();}

消息持久化,通过MessageDeliveryMode.PERSISTENT实现

Message message =MessageBuilder.withBody("hello".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.PERSISTENT).build();// 持久化消息
  1. 解决办法消费者确认机制

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

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

我们可以利用Spring的retry机制,在消费者出现异常时利用本地重试,设置重试次数,当次数达到了以后,如果消息依然失败,将消息投递到异常交换机,交由人工处理

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

回答:

  • 开启生产者确认机制,确保生产者的消息能到达队列
  • 开启持久化功能,确保消息未消费前在队列中不会丢失
  • 开启消费者确认机制为auto,由spring确认消息处理成功后完成ack
  • 开启消费者失败重试机制,多次重试失败后将消息投递到异常交换机,交由人工处理

RabbitMQ消息的重复消费问题如何解决

消息重复消费出现场景:

  • 网络抖动导致消息投递失败,RabbitMQ会重试投递消息。
  • 消费者在处理消息过程中发生异常,导致消息未被确认,RabbitMQ会重新投递消息。
  • 负载均衡导致消息被多个消费者消费。

解决办法:

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

RabbitMQ中死信交换机(延迟队列有了解过吗)

死信交换机是 RabbitMQ 中的一个特殊交换机,用于处理无法投递的消息。当消息无法投递到任何队列时,它会被路由到死信交换机。死信交换机可以将消息路由到另一个队列或执行其他操作。

当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter):

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

延迟队列是一种特殊的队列,消息在队列中会等待一段指定的时间后才会被投递给消费者。

场景:超时订单,限时优惠,定时发布

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

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

Delay Exchange插件:使用时只需要声明一个交换机,delayed属性为true即可

回答:

  • 我们当时一个什么业务使用到了延迟队列(超时订单、限时优惠、定时发布.…)
  • 其中延迟队列就用到了死信交换机和TTL(消息存活时间)实现的
  • 消息超时未消费就会变成死信(死信的其他情况:拒绝被消费,队列满了)

延迟队列插件实现延迟队列DelayExchange

  • 声明一个交换机,添加delayed属性为true
  • 发送消息时,添加x-delay头,值为超时时间

如果有100万消息堆积在MQ , 如何解决 ?

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

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

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

惰性队列的特征如下:

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

回答:

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

  • 增加更多消费者,提高消费速度
  • 在消费者内开启线程池加快消息处理速度
  • 扩大队列容积,提高堆积上限,采用惰性队列 - 在声明队列的时候可以设置属性x-queue-mode为lazy,即为惰性队列- 基于磁盘存储,消息上限高- 性能比较稳定,但基于磁盘存储,受限于磁盘O,时效性会降低

RabbitMQ的高可用机制有了解过嘛

在生产环境下,使用集群来保证高可用性

  • 普通集群、镜像集群、仲裁队列

RabbitMQ 提供了多种高可用机制来确保消息队列的可靠性和稳定性,包括:

1. 普通集群

普通集群模式会在各个节点间共享部分数据(交换机和队列元信息),但不包含队列里的消息;如果队列不在该节点,会从数据所在节点传递到当前节点并返回;当所在节点宕机,队列中的消息就会丢失。

2. 镜像集群

镜像集群本质是主从模式。镜像集群特征如下:

  • 交换机、队列、队列中的消息会在各个MQ的镜像节点之间同步备份。

  • 创建队列的节点称为该队列的主节点,备份的其他节点叫该队列的镜像节点。

  • 一个队列的主节点可能是另一个队列的镜像节点。

3. 仲裁队列

仲裁队列用于解决镜像集群中主节点故障时的数据一致性问题。仲裁队列使用 Raft 协议保证强一致性。

回答:

  • 在生产环境下,我们当时采用的镜像模式搭建的集群,共有3个节点
  • 镜像队列结构是一主多从(从就是镜像),所有操作都是主节点完成,然后同步给镜像节点
  • 主宕机后,镜像节点会替代成新的主(如果在主从同步完成前,主就已经宕机,可能出现数据丢失)

出现数据丢失如何解决:我们可以采用仲裁队列,与镜像队列一样,都是主从模式,支持主从数据同步,主从同步基于Rft协议,强一致。并且使用起来也非常简单,不需要额外的配置,在声明队列的时候只要指定这个是仲裁队列即可

标签: rabbitmq 分布式 java

本文转载自: https://blog.csdn.net/m0_74085417/article/details/136149653
版权归原作者 重生之我是cxk 所有, 如有侵权,请联系我们删除。

“RabbitMQ面试题”的评论:

还没有评论