消息中间件面试题-参考回答.pdfVIP

消息中间件面试题-参考回答

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

嗯！我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步

的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三

个层面考虑

第一个是开启生产者确认机制，确保生产者的消息能到达队列，如果报错可

以先记录到日志中，再去修复数据

第二个是开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交

换机、队列、和消息都要做持久化

第三个是开启消费者确认机制为auto，由spring确认消息处理成功后完成

ack，当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次

还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理

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

嗯，这个我们还真遇到过，是这样的，我们当时消费者是设置了自动确认机

因为我们当时处理的支付（订单|业务唯一标识），它有一个业务的唯一标

识，我们再处理消息时，先到数据库查询一下，这个数据是否存在，如果不

存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果已经存

在这个数据了，就说明消息重复消费了，我们就不需要再消费了

面试官：那你还知道其他的解决方案吗？

嗯，想~

其实这个就是典型的幂等的问题，比如，redis分布式锁、数据库的锁都是可

以的

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

嗯！了解过！

我们当时的xx项目有一个xx业务，需要用到延迟队列，其中就是使用

RabbitMQ来实现的。

延迟队列就是用到了死信交换机和TTL（消息存活时间）实现的。

如果消息超时未消费就会变成死信，在RabbitMQ中如果消息成为死信，队列

可以绑定一个死信交换机，在死信交换机上可以绑定其他队列，在我们发消

息的时候可以按照需求指定TTL的时间，这样就实现了延迟队列的功能了。

我记得RabbitMQ还有式可以实现延迟队列，在RabbitMQ中安装一个

死信插件，这样更方便一些，我们只需要在交互机的时候，指定这个就

是死信交换机，然后在发送消息的时候直接指定超时时间就行了，相对于死

信交换机+TTL要省略了一些步骤

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

我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解

决方案也所有很多的

第一:提高消费者的消费能力,可以使用多线程消费任务

第二：增加消费者，提高消费速度

使用工作队列模式,设置多个消费者消费消费同一个队列中的消息

第三：扩大队列容积，提高堆积上限

可以使用RabbitMQ惰性队列，惰性队列的好处主要是

①接收到消息后直接存入磁盘而非内存

②消费者要消费消息时才会从磁盘中并加载到内存

③支持数百万条的消息

面试官：RabbitMQ的高可用机制有了解过嘛

嗯，熟悉的~

我们当时项目在生产环境下，使用的集群，当时是镜像模式集群，使用

了3台机器。

镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节

点，如果主节点宕机后，镜像节点会替代成新的主节点，不过在主从同步完

成前，主节点就已经宕机，可能出现数据丢失

面试官：那出现丢数据怎么解决呢？

我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同

步，主从同步基于Raft协议，强一致。

并且使用起来也非常简单，不需要额外的配置，在队列的时候只要指定

这个是仲裁队列即可

面试官：Kafka是如何保证消息不丢失

嗯，这个保证机制很多，在发送消息到消费者接收消息，在每个阶段都有可

能会丢失消息，所以我们解决的话也是从多个方面考虑

第一个是生产者发送消息的时候，可以使用异步回调发送，如果消息发送失

败，我们可以通过回调获取失败后的消息信息，可以考虑重试或记录日志，

后边再做补偿都是可以的。同时在生产者这边还可以设置