常见面试题之MQ篇

news2024/10/5 15:30:48

1.1.你们为什么选择了`RabbitMQ`而不是其它的`MQ`？

如图：

在这里插入图片描述

话术：

kafka是以吞吐量高而闻名，不过其数据稳定性一般，而且无法保证消息有序性。我们公司的日志收集也有使用，业务模块中则使用的RabbitMQ。

阿里巴巴的RocketMQ基于Kafka的原理，弥补了Kafka的缺点，继承了其高吞吐的优势，其客户端目前以Java为主。但是我们担心阿里巴巴开源产品的稳定性，所以就没有使用。

RabbitMQ基于面向并发的语言Erlang开发，吞吐量不如Kafka，但是对我们公司来讲够用了。而且消息可靠性较好，并且消息延迟极低，集群搭建比较方便。支持多种协议，并且有各种语言的客户端，比较灵活。Spring对RabbitMQ的支持也比较好，使用起来比较方便，比较符合我们公司的需求。

综合考虑我们公司的并发需求以及稳定性需求，我们选择了RabbitMQ。

1.2.`RabbitMQ`如何确保消息的不丢失？

话术：

RabbitMQ针对消息传递过程中可能发生问题的各个地方，给出了针对性的解决方案：

生产者发送消息时可能因为网络问题导致消息没有到达交换机：
- RabbitMQ提供了publisher confirm机制
  - 生产者发送消息后，可以编写ConfirmCallback函数
  - 消息成功到达交换机后，RabbitMQ会调用ConfirmCallback通知消息的发送者，返回ACK
  - 消息如果未到达交换机，RabbitMQ也会调用ConfirmCallback通知消息的发送者，返回NACK
  - 消息超时未发送成功也会抛出异常
消息到达交换机后，如果未能到达队列，也会导致消息丢失：
- RabbitMQ提供了publisher return机制
  - 生产者可以定义ReturnCallback函数
  - 消息到达交换机，未到达队列，RabbitMQ会调用ReturnCallback通知发送者，告知失败原因
消息到达队列后，MQ宕机也可能导致丢失消息：
- RabbitMQ提供了持久化功能，集群的主从备份功能
  - 消息持久化，RabbitMQ会将交换机、队列、消息持久化到磁盘，宕机重启可以恢复消息
  - 镜像集群，仲裁队列，都可以提供主从备份功能，主节点宕机，从节点会自动切换为主，数据依然在
消息投递给消费者后，如果消费者处理不当，也可能导致消息丢失
- SpringAMQP基于RabbitMQ提供了消费者确认机制、消费者重试机制，消费者失败处理策略：
  - 消费者的确认机制：
    - 消费者处理消息成功，未出现异常时，Spring返回ACK给RabbitMQ，消息才被移除
    - 消费者处理消息失败，抛出异常，宕机，Spring返回NACK或者不返回结果，消息不被异常
  - 消费者重试机制：
    - 默认情况下，消费者处理失败时，消息会再次回到MQ队列，然后投递给其它消费者。Spring提供的消费者重试机制，则是在处理失败后不返回NACK，而是直接在消费者本地重试。多次重试都失败后，则按照消费者失败处理策略来处理消息。避免了消息频繁入队带来的额外压力。
  - 消费者失败策略：
    - 当消费者多次本地重试失败时，消息默认会丢弃。
    - Spring提供了Republish策略，在多次重试都失败，耗尽重试次数后，将消息重新投递给指定的异常交换机，并且会携带上异常栈信息，帮助定位问题。