消息队列面试

Tony_yitao

于 2024-09-07 22:01:47 发布

阅读量1.1k

点赞数 30

分类专栏： MQ 面试文章标签：面试中间件

本文链接：https://blog.csdn.net/tony_yitao/article/details/141854680

版权

面试同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

1 篇文章 0 订阅

订阅专栏

一、基础实战

（一）MQ的作用：异步、解耦、流量削峰填谷

（二）MQ应用场景

传统的金融项目一般使用IBMMQ（收费），比如某丰银行项目。ActiveMQ已经成为历史，因为现在很少使用。RabbitMQ（小项目使用较多）、Kafka（多用于大数据领域，支持大数据量的高并发吞吐量）、RocketMQ（支持10w/s的QPS）现在使用较多。

（三）RabbitMQ的AMQP

RabbitMQ的AMQP模型

1.交换机的类型

direct（直连交换机）,fanout（广播交换机）,topic（主题交换机）,headers（和direct一样不实用可忽略）。

2.RabbitMQ消息可靠性分析

RabbitMQ消息可靠性分析

为了保证RabbitMQ消息不丢失，需要确保图片中①②③④四个环节都是ok的。

（1）发布者确认机制：确保消息生产者将消息成功发送到RabbitMQ服务器端

RabbitMQ支持发布确认(Publisher Confirm)机制，即消息生产者将消息发送到RabbitMQ服务器后，如果服务器端将消息成功存储到队列中则会返回一个确认消息给消息生产者，否则会返回一个否定消息Nack（Negative Acknowledgement）给消息生产者。

（2）备份队列：确保消息在交换机中不会丢失

RabbitMQ支持备份队列（Alternate Exchange）机制，即消息到达队列之前，先将消息发送到备份队列中。如果主队列无法接收消息，RabbitMQ会将消息发送到备份队列中。备份队列通常是一个交换机，可以在创建队列时通过x-dead-letter-exchange属性来指定备份队列。

（3）持久化：确保消息在队列中不会丢失

在发送消息时，可以设置消息属性delivery_mode为2，表示该消息需要被持久化，即将消息保存到磁盘中，即使RabbitMQ服务器宕机也能够保证消息不回丢失。可以在创建队列时将队列的durable持久化属性设置为True，表示该队列也需要被持久化，以便在RabbitMQ服务器宕机后能够重新创建队列和绑定。

（4）消费者确认机制：确保消费者成功消费消息

在RabbitMQ中，消费者通过basic.ack命令向RabbitMQ服务器确认已经消费了某条消息。如果消费者在处理消息时发生错误或者宕机，RabbitMQ服务器会重新将消息发送给其他消费者。在确认消息消费成功之前，RabbitMQ会将消息保存在内存（队列）中，只有收到消费者的确认消息后才会删除内存中的消息。
除了RabbitMQ本身会自动确认消息是否消费成功之外，还可以手动确认消息是否消费成功。

（四）Kafka：topic、partition（分区）

1.Kafka可靠性分析

Kafka可靠性分析。1个主题A包含2个分区，每个分区各有2个副本，落地到集群共2*2即4个分区

Kafka 通过多种机制来确保消息不丢失，包括副本机制、ISR（In-Sync Replicas）机制、ACK 机制等。

（1）副本机制

Kafka 通过副本机制来确保消息不会丢失。在 Kafka 中，每个分区都可以配置多个副本，每个副本保存分区的完整副本，当一个副本宕机时，Kafka 会自动将副本切换到其他可用的副本上。因此，即使其中一个副本宕机，也能够保证消息不会丢失。

（2）ISR 机制

在 Kafka 中，副本分为 Leader 副本和 Follower 副本。Leader 副本负责处理消息，Follower 副本只是简单地复制 Leader 副本的数据。当 Follower 副本落后于 Leader 副本时，Kafka 会将 Follower 副本从 ISR 中移除。只有当 Follower 副本与 Leader 副本的差距不大时，才会将 Follower 副本重新加入 ISR，确保消息不会丢失。

（3）ACK 机制

在 Kafka 中，生产者发送消息时可以指定 acks 参数，表示生产者等待的确认数。acks 参数有三个取值：
acks=0 表示生产者不等待确认消息，直接将消息发送到 Kafka 集群。这种方式可能会导致消息丢失，不建议使用。
acks=1 表示生产者在 Leader 副本收到消息后，就将消息视为发送成功。如果 Leader 副本在发送消息后立即宕机，消息可能会丢失。如果 Follower 副本成功复制了消息，但 Leader 副本在宕机前没有来得及将消息写入磁盘，则这条消息将会丢失。
acks=all 表示生产者在所有 ISR 副本都确认接收到消息后，才将消息视为发送成功。这种方式可以最大程度地确保消息不会丢失，但是会降低消息发送的性能。
通过上述机制的使用，可以最大程度地确保 Kafka 中的消息不会丢失。需要根据实际场景选择合适的参数配置来平衡消息发送的性能和可靠性。

（五）RocketMQ：topic、queue（队列）

1.RocketMQ可靠性分析

RocketMQ可靠性分析

RocketMQ 通过多种机制来确保消息不丢失，包括刷盘机制、消息拉取机制、ACK 机制等。

（1）刷盘机制

RocketMQ 中的消息分为内存消息和磁盘消息，内存消息在 Broker 内存中进行读写，磁盘消息则保存在磁盘上。RocketMQ 支持同步刷盘和异步刷盘两种方式，通过刷盘机制可以确保消息在 Broker 宕机时不会丢失。在同步刷盘模式下，消息写入磁盘时，会等待磁盘的写入完成才返回写入成功的响应。在异步刷盘模式下，消息写入磁盘后立即返回写入成功的响应，但是不等待磁盘写入完成。

（2）ACK 机制

在RocketMQ中，Producer发送消息后，Broker会返回ACK确认信号，表示消息已经成功发送。如果Broker没有收到ACK 确认信号，就会尝试重新发送该消息，直到消息被确认为止。
RocketMQ采用主从复制机制，每个消息队列都有一个主节点和多个从节点，主节点负责消息的写入和读取，从节点负责备份数据。当主节点宕机时，从节点会自动接管主节点的工作，确保消息不会丢失。

（3）消息存储机制

RocketMQ 默认使用双写模式来存储消息，即将消息同时写入内存和磁盘中，然后再将内存中的消息异步刷盘到磁盘中。这种方式可以保证消息的可靠性，即使系统宕机，也能够尽可能地保证消息不会丢失。
除此之外，RocketMQ 还提供了多种机制来保证消息不丢失，例如事务消息、延迟消息、顺序消息等，这些机制可以根据业务需求进行选择和使用。
需要注意的是，为了确保消息的可靠性，RocketMQ 的发送消息的速度可能会受到一定的限制，需要在消息可靠性和性能之间进行权衡。

2.RocketMQ生产架构

RocketMQ生产架构

（六）如何防止消息重复消费：消费端幂等性处理

1.什么是幂等性？

针对消息消费端来说，幂等性是指针对相同的输入多次调用处理函数得到的结果不变，也就是不管生产者发送多少次消息给消息消费端，对业务结果不会产生不期望的结果。
例如SQL语句update stat_table set count= 10 where id =1不管执行多少次，count字段的值都是10，那么执行SQL的操作就是幂等性操作。
再看另外一个SQL的执行就不是幂等性操作：update stat_table set count= count +1 where id= 1，因为每次执行SQL的结果都不一样。

2.如何实现幂等性？

（1）MVCC

多版本并发控制，一种乐观锁的实现。在生产者发送消息进行数据更新时需要带上数据的版本号，消费者去消费消息时需要比对数据的版本号，版本号不一致的操作无法成功。例如博客点赞次数自动加1的接口：

public boolean addCount(Long id, Long version);
update blogTable set count= count+1,version=version+1 where id=321 and version=123

每个version只有一次执行成功的机会，如果执行失败必须重新获取数据的最新版本号再次发起更新操作。

（2）去重表

利用数据库的特性来实现幂等，常用的一个思路就是在表上建立唯一性索引，保证某一类数据一旦执行完成，后续同样的请求将不再重复处理（利用一张日志表来记录已经处理成功的消息的id，如果新到的消息的id已经包含在日志表中，那么新到的这条消息就不在处理了）。
以电商平台为例，电商平台订单的id就是最适合的token。当用户下单时，会经历过很多个环节，比如生成订单、减库存、减优惠卷等等。请求经历每一个环节时先检查该订单id是否已经执行过这一步骤，对未执行的请求，执行操作并缓存执行结果，对已经执行过的id，则直接返回之前的执行结果，不做任何操作。这样以来，可以最大程度上减少重复执行的问题，缓存起来的执行结果也能用于事务控制等等。

二、高级实战

（一）什么是延时消息，各种MQ的实现？

1.场景

（1）买电影票

购票->选座位（选完座位后系统会锁定座位）->支付（限定5分钟内完成支付，否则释放座位）。
处理方案：锁定座位后，推送一条只有5分钟有效期的延时消息。应用中消费者进行业务处理时5分钟内没有完成支付系统将释放座位给其他用户购买。
如果不实用MQ，而是定时扫描数据库来解决需要延时处理的业务场景，这种方案性能差（不能保证即时性）、不灵活（系统的业务中可能还有其他不同的需要延时处理的场景）。

（2）实现

①通过RabbitMQ的死信队列/消息实现

基于死信交换机和两个消息队列实现的。先将消息发送到过期队列中，如果过一段时间后消息仍然没有被消费，那么消息将会进入死信队列中。一旦监控到死信队列中有消息说明消息没有及时被消费，这个时候可以做进一步处理。

②通过RocketMQ延时消息来实现

RocketMQ发送消息的方法有很多重载方法，可以根据业务中需要的延时时间精确度来选择不同的发送延时消息的方法，因为这些多个发送延时消息的重载方法的区别就是它们可以通过不同参数来决定延时消息的时间单位和精度。
RocketMQ延时消息的原理：
生产者一旦发送了带有延时属性的消息，消息则不会立即进入目标主题，而是先进入一个临时主题（SCHEDULE_TOPIC_XXXX）。然后通过定时任务每秒运行一次去检查消息是否到达超时时间，如果消息到达超时时间会立即进入目标主题。
其中，SCHEDULE_TOPIC_XXXX主题有18个队列，每个队列对应一个延时消息等级，因为消息的延时等级有18个不同的时间。延时消息是放在队列中的，队列可以保证消息的顺序性，在定时任务遍历队列的时候只需要判断第一次消息是否过期，如果没有过期，那么其后面的消息肯定没有过期。