【Java超高频面试题&RocketMQ&rabbitMQ】MQ相关高频面试题汇总-CSDN博客

本文链接：https://blog.csdn.net/longshehui/article/details/142612093

简介：

本期文章将汇总MQ相关的高频面试题，给最近需要找工作的朋友们总结一波，帮助大家全面掌握MQ的核心知识点，提升竞争力，为你的面试之旅保驾护航！

接口幂等如何处理

接口幂等性是指一个接口被重复调用多次，其产生的结果应该是一致的。处理接口幂等性可以通过以下几种方式：

全局唯一ID：

为每次业务操作生成一个全局唯一的ID（如订单号、流水号等），并在执行操作前判断该ID是否已存在。如果不存在，则执行操作并持久化该ID；如果已存在，则说明该操作已被执行过，直接返回结果。

乐观锁：

在数据库中为需要幂等控制的表添加一个version字段（版本号），每次更新数据时，将该字段值加1。在更新数据时，检查版本号是否一致，一致则更新，不一致则说明数据已被其他操作修改过，返回错误信息。

Token机制：

在客户端发起请求时，生成一个唯一的Token，并将Token与请求一起发送到服务器。服务器在处理请求时，首先检查该Token是否已存在，若不存在则处理请求并存储Token，若已存在则说明请求已被处理过，直接返回结果。

MQ消息重复消费问题怎么处理

MQ的重复消费问题通常是由于消费者在处理完消息后未能正确地向MQ发送确认消息（ack），导致MQ认为消息处理失败并重新投递。

如果不加锁的话,

那主要是利用字段的唯一性来解决

1. 幂等性设计, 比如:可以使用唯一ID来确保同一笔订单只被处理一次

2. 去重机制, 消费者端每次执行之前检查redis中有无id

我们可以通过实现消息的幂等性来避免这种情况，比如说让生产者给每个消息携带一个唯一的id，消费者获取消息后根据这个 id 去查询数据库，如果不存在就正常消费，如果存在了就证明该消息被消费过，直接丢弃

3. 数据库设置unique 唯一索引

什么是死信队列，什么情况下消息会进入死信队列

死信队列（Dead Letter Queue, DLQ） 是一种特殊的队列，用于存储无法被正常处理的消息。当消息满足以下条件之一时，会被发送到死信队列中：

消息过期：消息在队列中的存活时间超过了设置的TTL（Time-To-Live）时间。
消息被拒绝且不再重新入队：消费者接收到消息后

消息消费失败怎么处理

全局唯一ID：

为每次业务操作生成一个全局唯一的ID（如订单号、流水号等），并在执行操作前判断该ID是否已存在。如果不存在，则执行操作并持久化该ID；如果已存在，则说明该操作已被执行过，直接返回结果。

乐观锁：

在数据库中为需要幂等控制的表添加一个version字段（版本号），每次更新数据时，将该字段值加1。在更新数据时，检查版本号是否一致，一致则更新，不一致则说明数据已被其他操作修改过，返回错误信息。

Token机制：

在客户端发起请求时，生成一个唯一的Token，并将Token与请求一起发送到服务器。服务器在处理请求时，首先检查该Token是否已存在，若不存在则处理请求并存储Token，若已存在则说明请求已被处理过，直接返回结果。

MQ的使用场景，举例说明

1.异步

rabbitMQ 消息队列可以用来做任务的异步处理，提高程序的响应时间

2.服务解耦

3.消除峰值

通过异步处理，消息传到 MQ 直接返回，接着等待排队处理，避免了线路拥堵

地铁闸机(延迟收费) / 短信邮件通知

MQ的执行原理(MQ的架构)

MQ（消息队列）的执行原理主要基于异步通信的架构。

其核心组成部分:

生产者、消息队列、消息存储区和消费者。

消息发送：生产者和Broker 建立 TCP 连接，创建信道。通过信道将消息发送给Broker，由 Exchange 将消息进行转发到指定的队列

消息接收：消费者和Broker 建立 TCP 连接，创建信道，然后监听指定的队列，当有消息到达队列时，Broker 默认将消息推送给消费者，消费者就能接收到消息

MQ如何数据存储在哪儿？如何保证性能

MQ中的消息通常存储在Broker节点的文件系统中。以RocketMQ为例，默认情况下，存储目录位于Broker节点的store目录下，具体路径可以在broker.properties配置文件中的storePathRootDir参数中设置。

为了保证性能，MQ通常会采用一系列策略。首先，消息在内存中存储可以提高处理速度，但重启后数据会丢失。为了解决这个问题，可以配置数据持久化，将交换机、队列和消息都设置为持久化模式。

此外，为了减少IO次数，发送到MQ的消息并不是逐条持久化到数据库的，而是每隔一段时间（如100毫秒左右）批量持久化。

MQ如何保证消息的顺序

保证MQ消息的顺序一致性可以采取以下几种方式：

使用单个消息队列：将所有需要保持顺序的消息发送到同一个消息队列中，这样可以确保消息的消费顺序和发送顺序一致。

使用消息分区：将消息按照某种规则进行分区，每个分区对应一个独立的消息队列。在消费消息时，按照分区顺序进行消费，这样可以保证每个分区内的消息顺序一致。

使用消息序列号：在消息中添加一个序列号字段，消费者在接收消息时，根据序列号进行排序。

使用分布式事务：在消息发送和消费过程用分布式事务来保证消息的顺序一致性。

按照发送的顺序进行消费就是顺序消息，遵循（FIFO）, 默认生产者以Round Robin轮询方式把消息发送到不同的Queue分区队列；消费者从多个队列中消费消息，这种情况没法保证顺序。

RocketMQ分为全局有序和部分有序：

全局有序，是一个topic下的所有消息都要保证顺序，如果要保证消息全局顺序消费，就需要保证使用一个队列存放消息，一个消费者从这一个队列消费消息就能保证顺序，即：单线程执行。

部分顺序，消息只要保证某一组消息被顺序消费，即：只需要保证一个队列中的消息有序消费即可。比如：保证同一个订单ID的生成、付款、发货消息按照顺序消费即可实现

MQ的延迟消息的使用场景，举例说明如何实现

MQ的延迟消息主要用于需要在特定时间后处理的业务场景。

订单超时: 创建订单后给一个超时时间,到时后改变订单状态

消息推送：在移动应用或web应用程序中，可以将用户订阅的消息发送到一个延

优惠券超时, 领取了优惠券像mq发送一个消息,超过有限时间后就改变其状态

优惠券发放：可以设置一个延时队列，将优惠券发放任务添加到队列中，设置一定的延时时间，以保证优惠券在特定时间后才能被消费。

RocketMQ如果发生大量消息堆积该如何解决?

当RocketMQ发生大量消息堆积时，会导致以下问题:

消费者消费速度跟不上生产者的生产速度，消息队列中的消息越来越多，最终可能导致00M(0ut Of Memory)或存储空间被耗尽。
堆积的消息可能会影响系统的性能和稳定性，从而降低系统的可用性和可靠性。

为了解决这个问题，可以采取以下措施:

增加消费者数量:通过增加消费者的数量来提高消息消费速度，减少消息堆积的风险。
扩大消息队列的容量:通过扩大消息队列的容量，可以存储更多的消息，减少消息堆积的风险。
调整消息发送速率:如果生产者的生产速率过快，可以适当调整发送速率，避免消息堆积的风险。
优化消费者的处理能力:对于消息处理较为复杂的消费者，可以优化其处理能力，提高消息的处理效率。
定期清理过期消息:对于长时间未被消费的消息，可以设置过期时间，并定期删除过期消息，以释放存储空间。
使用延迟消息:对于实时性要求不高的消息，可以使用延迟消息来缓解消息堆积的风险，避免瞬时大量消息导致消费者无法及时处理。
针对特定场景采取相应措施:根据具体场景和业务需求，针对性地采取相应的措施，如限流、分流等，以确保系统的可用性和可靠性。

需要注意的是，以上措施都是在消费者无法及时处理消息的情况下才会出现消息堆积。因此，在设计RocketMQ架构时，应该根据实际业务场景和需求，合理设置消息队列容量、消费者数量和处理能力，以避免消息堆积的风险。

结语

🔥如果文章对你有帮助的话，欢迎💗关注、👍点赞、⭐收藏、✍️评论，支持一下小老弟，蟹蟹大咖们~