RocketMQ 面试常问问题及答案

隔壁阿布都

已于 2024-03-27 16:23:51 修改

阅读量5.5k

点赞数 4

分类专栏：消息队列文章标签： rocketmq 面试职场和发展

于 2021-03-26 16:11:27 首次发布

本文链接：https://blog.csdn.net/qq_27828675/article/details/115248974

版权

消息队列专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1. RocketMQ是什么？

RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于2017年9月25日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件，具有高性能、低延时和高可靠等特性。主要用来提升性能、系统解耦、流量肖峰等。

2. RocketMQ有什么特点？

1. 灵活可扩展性
RocketMQ 天然支持集群，其核心四组件（Name Server、Broker、Producer、Consumer）每一个都可以在没有单点故障的情况下进行水平扩展。
2. 海量消息堆积能力
RocketMQ 采用零拷贝原理实现超大的消息的堆积能力，据说单机已可以支持亿级消息堆积，而且在堆积了这么多消息后依然保持写入低延迟。
3. 支持顺序消息
可以保证消息消费者按照消息发送的顺序对消息进行消费。顺序消息分为全局有序和局部有序，一般推荐使用局部有序，即生产者通过将某一类消息按顺序发送至同一个队列来实现。
4. 多种消息过滤方式
消息过滤分为在服务器端过滤和在消费端过滤。服务器端过滤时可以按照消息消费者的要求做过滤，优点是减少不必要消息传输，缺点是增加了消息服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活，缺点是很多无用的消息会传输给消息消费者。
5. 支持事务消息
RocketMQ 除了支持普通消息，顺序消息之外还支持事务消息，这个特性对于分布式事务来说提供了又一种解决思路。
6. 回溯消费
回溯消费是指消费者已经消费成功的消息，由于业务上需求需要重新消费，RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。

RocketMQ、RabbitMQ、Kafaka的区别？

RocketMQ、RabbitMQ和Kafka都是流行的消息队列服务，它们在许多方面有所不同，适用于不同的场景和需求。以下是对它们之间主要区别的概述：

RocketMQ：

特性：RocketMQ支持订阅与发布模式，允许生产者向特定主题发送消息，消费者则关注并消费这些主题中的消息。它特别关注消息的顺序性，可以确保消息按照发送的顺序被消费，这在某些业务场景中非常重要，如订单处理。此外，RocketMQ支持分布式事务消息，适用于涉及多个业务系统的分布式事务场景，确保消息的一致性和可靠性。
应用场景：RocketMQ适用于大规模数据处理和高吞吐量的场景，如实时日志处理、流式处理等。其高吞吐量和低延迟的特性使其成为这些场景的理想选择。

RabbitMQ：

特性：RabbitMQ是一个功能强大且灵活的消息代理，它支持多种消息传递协议（如AMQP、MQTT、STOMP等）。RabbitMQ具有可扩展性，可以通过添加更多的节点和队列来实现水平扩展。它还具有可靠性，通过持久化和通知机制确保消息被成功传递和处理。RabbitMQ支持多种交换机类型和绑定选项，提供了灵活的路由和消息传递方式。
应用场景：RabbitMQ适用于需要高度灵活性和可扩展性的场景，其丰富的交换机和绑定选项使得它可以适应各种复杂的消息传递需求。同时，RabbitMQ的可视化管理界面和多种编程语言的客户端库也使其易于使用和管理。

Kafka：

特性：Kafka是一个为发布和订阅提供高吞吐量的分布式流处理平台。它支持持久化操作，将消息持久化到磁盘，因此可用于批量消费和实时应用程序。Kafka是一个分布式系统，易于向外扩展，所有的生产者、代理和消费者都是分布式的。这使得Kafka能够处理大量的数据并提供高吞吐量。
应用场景：Kafka适用于高吞吐量的实时数据流处理和流式处理场景。由于其高吞吐量和持久化存储特性，Kafka成为构建可靠的数据管道和实时数据处理系统的理想选择。

总结来说，RocketMQ、RabbitMQ和Kafka在特性、应用场景和优势方面都有所不同。选择哪个消息队列服务取决于具体的业务需求、系统架构和性能要求。

例如，

如果需要处理大量数据并保持消息的顺序性，RocketMQ可能是一个好选择；

如果需要灵活的路由和消息传递方式，RabbitMQ可能更适合；

而如果需要高吞吐量的实时数据处理，Kafka则是一个不错的选择。

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

综上，各种对比之后，有如下总结：

一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；

后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

3、为什么要使用MQ？

因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了mq

作用描述解耦系统耦合度降低，没有强依赖关系异步不需要同步执行的远程调用可以有效提高响应时间削峰请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮

4、RocketMQ由哪些角色组成，每个角色作用和特点是什么？

角色作用Nameserver无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。Producer消息生产者，负责发消息到Broker。Broker就是MQ本身，负责收发消息、持久化消息等。Consumer消息消费者，负责从Broker上拉取消息进行消费，消费完进行ack。

5、RocketMQ中的Topic和JMS的queue有什么区别？

queue就是来源于数据结构的FIFO队列。而Topic是个抽象的概念，每个Topic底层对应N个queue，而数据也真实存在queue上的。

6、RocketMQ Broker中的消息被消费后会立即删除吗？

不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。

追问：那么消息会堆积吗？什么时候清理过期消息？

4.6版本默认48小时后会删除不再使用的CommitLog文件

检查这个文件最后访问时间
判断是否大于过期时间
指定时间删除，默认凌晨4点

源码如下：

/**
 * {@link org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogService#isTimeToDelete()}
 */
private boolean isTimeToDelete() {
    // when = "04";
    String when = DefaultMessageStore.this.getMessageStoreConfig().getDeleteWhen();
    // 是04点，就返回true
    if (UtilAll.isItTimeToDo(when)) {
        return true;
    }
 // 不是04点，返回false
    return false;
}

/**
 * {@link org.apache.rocketmq.store.DefaultMessageStore.CleanCommitLogService#deleteExpiredFiles()}
 */
private void deleteExpiredFiles() {
    // isTimeToDelete()这个方法是判断是不是凌晨四点，是的话就执行删除逻辑。
    if (isTimeToDelete()) {
        // 默认是72，但是broker配置文件默认改成了48，所以新版本都是48。
        long fileReservedTime = 48 * 60 * 60 * 1000;
        deleteCount = DefaultMessageStore.this.commitLog.deleteExpiredFile(72 * 60 * 60 * 1000, xx, xx, xx);
    }
}
                                                                       
/**
 * {@link org.apache.rocketmq.store.CommitLog#deleteExpiredFile()}
 */
public int deleteExpiredFile(xxx) {
    // 这个方法的主逻辑就是遍历查找最后更改时间+过期时间，小于当前系统时间的话就删了（也就是小于48小时）。
    return this.mappedFileQueue.deleteExpiredFileByTime(72 * 60 * 60 * 1000, xx, xx, xx);
}

7、RocketMQ消费模式有几种？

消费模型由Consumer决定，消费维度为Topic。

集群消费

1.一条消息只会被同Group中的一个Consumer消费
2.多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据

广播消费

消息将对一个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer 属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一次。

8、消费消息是push还是pull？

RocketMQ没有真正意义的push，都是pull，虽然有push类，但实际底层实现采用的是长轮询机制，即拉取方式

broker端属性 longPollingEnable 标记是否开启长轮询。默认开启

源码如下：

// {@link org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#pullMessage()}
// 看到没，这是一只披着羊皮的狼，名字叫PushConsumerImpl，实际干的确是pull的活。

// 拉取消息，结果放到pullCallback里
this.pullAPIWrapper.pullKernelImpl(pullCallback);

追问：为什么要主动拉取消息而不使用事件监听方式？

事件驱动方式是建立好长连接，由事件（发送数据）的方式来实时推送。

如果broker主动推送消息的话有可能push速度快，消费速度慢的情况，那么就会造成消息在consumer端堆积过多，同时又不能被其他consumer消费的情况。而pull的方式可以根据当前自身情况来pull，不会造成过多的压力而造成瓶颈。所以采取了pull的方式。

9、broker如何处理拉取请求的？

Consumer首次请求Broker

Broker中是否有符合条件的消息
有 ->
- 响应Consumer
- 等待下次Consumer的请求
没有
- DefaultMessageStore#ReputMessageService#run方法
- PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送
- 每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
- 当有新消息的时候返回请求
- 挂起consumer的请求，即不断开连接，也不返回数据
- 使用consumer的offset，

10、RocketMQ如何做负载均衡？

通过Topic在多Broker中分布式存储实现。

producer端

发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡

提升写入吞吐量，当多个producer同时向一个broker写入数据的时候，性能会下降
消息分布在多broker中，为负载消费做准备

默认策略是随机选择：

producer维护一个index
每次取节点会自增
index向所有broker个数取余
自带容错策略

其他实现：

SelectMessageQueueByHash
- hash的是传入的args
SelectMessageQueueByRandom
SelectMessageQueueByMachineRoom 没有实现

也可以自定义实现MessageQueueSelector接口中的select方法

MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);

consumer端

采用的是平均分配算法来进行负载均衡。

其他负载均衡算法

平均分配策略(默认)(AllocateMessageQueueAveragely) 环形分配策略(AllocateMessageQueueAveragelyByCircle) 手动配置分配策略(AllocateMessageQueueByConfig) 机房分配策略(AllocateMessageQueueByMachineRoom) 一致性哈希分配策略(AllocateMessageQueueConsistentHash) 靠近机房策略(AllocateMachineRoomNearby)

追问：当消费负载均衡consumer和queue不对等的时候会发生什么？

Consumer和queue会优先平均分配，如果Consumer少于queue的个数，则会存在部分Consumer消费多个queue的情况，如果Consumer等于queue的个数，那就是一个Consumer消费一个queue，如果Consumer个数大于queue的个数，那么会有部分Consumer空余出来，白白的浪费了。

11、消息重复消费

影响消息正常发送和消费的重要原因是网络的不确定性。

引起重复消费的原因

正常情况下在consumer真正消费完消息后应该发送ack，通知broker该消息已正常消费，从queue中剔除

当ack因为网络原因无法发送到broker，broker会认为词条消息没有被消费，此后会开启消息重投机制把消息再次投递到consumer

消费模式

在CLUSTERING模式下，消息在broker中会保证相同group的consumer消费一次，但是针对不同group的consumer会推送多次

解决方案

数据库表

处理消息前，使用消息主键在表中带有约束的字段中insert

单机时可以使用map ConcurrentHashMap -> putIfAbsent guava cache

Redis

分布式锁搞起来。

12、如何让RocketMQ保证消息的顺序消费

你们线上业务用消息中间件的时候，是否需要保证消息的顺序性?
如果不需要保证消息顺序，为什么不需要?假如我有一个场景要保证消息的顺序，你们应该如何保证?

首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：

同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候一个线程去消费一个queue里的消息。

追问：怎么保证消息发到同一个queue？

Rocket MQ给我们提供了MessageQueueSelector接口，可以自己重写里面的接口，实现自己的算法，举个最简单的例子：判断i % 2 == 0，那就都放到queue1里，否则放到queue2里。

for (int i = 0; i < 5; i++) {
    Message message = new Message("orderTopic", ("hello!" + i).getBytes());
    producer.send(
        // 要发的那条消息
        message,
        // queue 选择器 ，向 topic中的哪个queue去写消息
        new MessageQueueSelector() {
            // 手动 选择一个queue
            @Override
            public MessageQueue select(
                // 当前topic 里面包含的所有queue
                List<MessageQueue> mqs,
                // 具体要发的那条消息
                Message msg,
                // 对应到 send（） 里的 args，也就是2000前面的那个0
                Object arg) {
                // 向固定的一个queue里写消息，比如这里就是向第一个queue里写消息
                if (Integer.parseInt(arg.toString()) % 2 == 0) {
                    return mqs.get(0);
                } else {
                    return mqs.get(1);
                }
            }
        },
        // 自定义参数：0
        // 2000代表2000毫秒超时时间
        i, 2000);
}

13、RocketMQ如何保证消息不丢失

首先在如下三个部分都可能会出现丢失消息的情况：

Producer端
Broker端
Consumer端

13.1、Producer端如何保证消息不丢失

采取send()同步发消息，发送结果是同步感知的。
发送失败后可以重试，设置重试次数。默认3次。

producer.setRetryTimesWhenSendFailed(10);

集群部署，比如发送失败了的原因可能是当前Broker宕机了，重试的时候会发送到其他Broker上。

13.2、Broker端如何保证消息不丢失

修改刷盘策略为同步刷盘。默认情况下是异步刷盘的。

flushDiskType = SYNC_FLUSH

集群部署，主从模式，高可用。

13.3、Consumer端如何保证消息不丢失

完全消费正常后在进行手动ack确认。

14、rocketMQ的消息堆积如何处理

下游消费系统如果宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?
你们线上是否遇到过消息积压的生产故障?如果没遇到过，你考虑一下如何应对?

首先要找到是什么原因导致的消息堆积，是Producer太多了，Consumer太少了导致的还是说其他情况，总之先定位问题。

然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆积问题

追问：如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么办？

准备一个临时的topic
queue的数量是堆积的几倍
queue分布到多Broker中
上线一台Consumer做消息的搬运工，把原来Topic中的消息挪到新的Topic里，不做业务逻辑处理，只是挪过去
上线N台Consumer同时消费临时Topic中的数据
改bug
恢复原来的Consumer，继续消费之前的Topic

追问：堆积时间过长消息超时了？

RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在超时删除这情况。

追问：堆积的消息会不会进死信队列？

不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），18次（默认18次，网上所有文章都说是16次，无一例外。但是我没搞懂为啥是16次，这不是18个时间吗？）才会进入死信队列（%DLQ%+ConsumerGroup）。

源码如下：

public class MessageStoreConfig {
    // 每隔如下时间会进行重试，到最后一次时间重试失败的话就进入死信队列了。
 private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";
}

15、RocketMQ在分布式事务支持这块机制的底层原理?

你们用的是RocketMQ?RocketMQ很大的一个特点是对分布式事务的支持，你说说他在分布式事务支持这块机制的底层原理?

分布式系统中的事务可以使用TCC（Try、Confirm、Cancel）、2pc来解决分布式系统中的消息原子性

RocketMQ 4.3+提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致

RocketMQ实现方式：

**Half Message：**预处理消息，当broker收到此类消息后，会存储到RMQ_SYS_TRANS_HALF_TOPIC的消息消费队列中

**检查事务状态：**Broker会开启一个定时任务，消费RMQ_SYS_TRANS_HALF_TOPIC队列中的消息，每次执行任务会向消息发送者确认事务执行状态（提交、回滚、未知），如果是未知，Broker会定时去回调在重新检查。

**超时：**如果超过回查次数，默认回滚消息。

也就是他并未真正进入Topic的queue，而是用了临时queue来放所谓的half message，等提交事务后才会真正的将half message转移到topic下的queue。

16、如果让你来动手实现一个分布式消息中间件，整体架构你会如何设计实现?

我个人觉得从以下几个点回答吧：

需要考虑能快速扩容、天然支持集群
持久化的姿势
高可用性
数据0丢失的考虑
服务端部署简单、client端使用简单

17、看过RocketMQ 的源码没有。如果看过，说说你对RocketMQ 源码的理解?

要真让我说，我会吐槽蛮烂的，首先没任何注释，可能是之前阿里巴巴写了中文注释，捐赠给apache后，apache觉得中文注释不能留，自己又懒得写英文注释，就都给删了。里面比较典型的设计模式有单例、工厂、策略、门面模式。单例工厂无处不在，策略印象深刻比如发消息和消费消息的时候queue的负载均衡就是N个策略算法类，有随机、hash等，这也是能够快速扩容天然支持集群的必要原因之一。持久化做的也比较完善，采取的CommitLog来落盘，同步异步两种方式。

18、高吞吐量下如何优化生产者和消费者的性能?

开发

同一group下，多机部署，并行消费
单个Consumer提高消费线程个数
批量消费
- 消息批量拉取
- 业务逻辑批量处理

运维

网卡调优
jvm调优
多线程与cpu调优
Page Cache

19、再说说RocketMQ 是如何保证数据的高容错性的?

在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker
如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用
如果上次失败的Broker可用那么还是会选择该Broker的队列
如果上述情况失败，则随机选择一个进行发送
在发送消息的时候会记录一下调用的时间与是否报错，根据该时间去预测broker的可用时间

其实就是send消息的时候queue的选择。源码在如下：
org.apache.rocketmq.client.latency.MQFaultStrategy#selectOneMessageQueue()

20、任何一台Broker突然宕机了怎么办？

Broker主从架构以及多副本策略。Master收到消息后会同步给Slave，这样一条消息就不止一份了，Master宕机了还有slave中的消息可用，保证了MQ的可靠性和高可用性。而且Rocket MQ4.5.0开始就支持了Dlegder模式，基于raft的，做到了真正意义的HA。

21、Broker把自己的信息注册到哪个NameServer上？

这么问明显在坑你，因为Broker会向所有的NameServer上注册自己的信息，而不是某一个，是每一个，全部！

隔壁阿布都

关注

4
点赞
踩
21

收藏

觉得还不错? 一键收藏
0
评论
RocketMQ 面试常问问题及答案

1. RocketMQ是什么？RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于2017年9月25日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件，具有高性能、低延时和高可靠等特性。主要用来提升性能、系统解耦、流量肖峰等。2. RocketMQ有什么特点？1. 灵活可扩展性RocketMQ 天然支持集群，其核心四组件（Name Server、Broker、...
复制链接

扫一扫