40道RocketMQ高频题整理(附答案背诵版)

最新推荐文章于 2024-09-04 22:38:24 发布

置顶编程大全

最新推荐文章于 2024-09-04 22:38:24 发布

阅读量1.1k

点赞数 33

分类专栏：面试题文章标签： rocketmq 面试 java-rocketmq

本文链接：https://blog.csdn.net/IT6666_it/article/details/139067489

版权

面试题专栏收录该内容

49 篇文章 0 订阅

订阅专栏

简述什么是RocketMQ ？

RocketMQ是一款分布式、队列模型的消息中间件，它具有以下特点：

支持严格的消息顺序；
支持Topic与Queue两种模式；
具有亿级消息堆积能力；
分布式特性比较友好；
同时支持Push与Pull方式消费消息。

RocketMQ的优势在于它支持事务型消息，能够保持消息发送和DB操作两方的最终一致性，这是主流MQ中唯独RocketMQ支持的。此外，RocketMQ还支持结合多个系统之间数据最终一致性、18个级别的延迟消息、指定次数和时间间隔的失败消息重发等特性，这些也是其他MQ产品所不具备的。

简述RocketMQ 整体架构？

RocketMQ是一款具有低延迟、高性能和可靠性、可灵活扩展的分布式消息平台。它由四部分组成：NameServer、Broker、生产者和消费者。

NameServer是一个轻量级的服务注册中心，每个NameServer节点中有全量的Broker中topic的路由信息。

Broker负责消息存储，以topic为维度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型，具备多副本容错机制（2副本或3副本）、强大的削峰填谷以及上亿级消息堆积能力，同时可严格保证消息的有序性。

ProducerClient是用户部署的消息发布客户端，支持push和pull模型，支持广播模式和集群模式。

Queue是topic的细分。

以上各部分都可以在没有单点故障的情况下进行水平扩展。

简述RocketMQ的执行流程？

RocketMQ的执行流程包括以下步骤：

启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来。
Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。
在收发消息前，需要先创建Topic。创建Topic时，需要指定该Topic要存储在哪些Broker上。也可以在发送消息时自动创建Topic。
Producer发送消息。
Consumer消费消息。

简述RocketMQ特点？

RocketMQ是一款分布式、队列模型的消息中间件，具有以下特点：

具有灵活的可扩展性：RocketMQ天然支持集群，其核心四大组件（NameServer、Broker、Producer、Consumer）的每一个都可以在没有单点故障的情况下进行水平扩展。
具有海量消息堆积能力：RocketMQ采用零拷贝原理实现了超大量消息的堆积能力，据说单机已经支持亿级消息堆积，而且在堆积了这么多消息后保持写入低延迟。
支持顺序消息：RocketMq可以保持消息消费者按照消息的发送顺序对消息进行消费。顺序消息分为全局有序消息和局部有序消息，一般推荐使用局部有序消息，即生产者通过将某一类消息按照顺序发送至同一队列中来实现。
支持多种消息过滤方式：消息过滤分为在服务器端过滤和在消费端过滤。在服务器端过滤时可以按照消息消费者的要求进行过滤，优点是减少不必要的消息传输，缺点是增加了消息服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活。
具有高性能、高可靠、高实时、分布式特点：RocketMQ是一个队列模型的消息中间件，同时支持Push与Pull方式消费消息。
提供丰富的消息拉取模式：RocketMQ支持多种拉取模式，可以满足不同的使用需求。
具有高效的订阅者水平扩展能力：RocketMQ支持高效的订阅者水平扩展，可以轻松应对大规模的并发访问。
具有实时的消息订阅机制：RocketMQ支持实时的消息订阅机制，可以满足不同场景下的实时性需求。
具有较少的依赖：RocketMQ对其他系统的依赖较少，可以更好地适应不同的环境。

总的来说，RocketMQ具有灵活可扩展、高性能、高可靠、高实时、分布式等特点，同时支持顺序消息和多种过滤方式，提供丰富的消息拉取模式和高效的订阅者水平扩展能力，以及实时的消息订阅机制和较少的依赖。

简述什么是RocketMQ的名称服务器？

RocketMQ的名称服务器（NameServer）是一个轻量级的服务注册中心，它保存了Broker的相关元信息并给Producer和Consumer查找Broker信息。NameServer被设计成几乎无状态的，可以横向扩展，节点之间相互之间无通信，通过部署多台机器来标记自己是一个伪集群。每个Broker在启动的时候会到NameServer注册，Producer在发送消息前会根据Topic到NameServer获取到Broker的路由信息，进而和Broker取得连接。Consumer也会定时获取Topic的路由信息。

简述RocketMQ的 Broker 的存储机制和文件结构？

RocketMQ的Broker存储机制和文件结构如下：

Broker主要负责处理普通消息、定时消息、顺序消息、未消费的消息和已消费的消息的存储逻辑。
消息保存结构如下：在CommitLog目录下有多个CommitLog文件，其实只有一个文件，为了方便保存和读写被切分为多个子文件，所有的子文件通过其保存的第一个和最后一个消息的物理位点进行连接。Broker按照时间和物理的offset顺序写CommitLog文件，每次写的时候需要加锁。每个CommitLog子文件的大小默认是1GB，可以通过mapedFileSizeCommitLog进行配置。当一个CommitLog写满后，创建一个新的CommitLog，继续上一个ComiitLog的Offset写操作，直到写满换成下一个文件。所有CommitLog子文件之间的Offset是连续的，所以最后一个CommitLog总是被写入的。

简述RocketMQ的消息模型（Mess ？age Model）

RocketMQ的消息模型主要包括Producer、Broker和Consumer三部分。

Producer主要负责生产消息，一般由业务系统负责生产消息。它会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。

Broker负责存储消息，在实际部署过程中对应一台服务器，每个Broker可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的Broker。Broker还提供了MessageQueue用于存储消息的物理地址，每个Topic中的消息地址存储于多个MessageQueue中。

Consumer负责消费消息。ConsumerGroup由多个Consumer实例构成。

RocketMQ消费模式有几种？

RocketMQ主要有两种消费模式：CLUSTERING集群消费（默认）和BROADCASTING广播消费。

在CLUSTERING模式下，一个ConsumerGroup中的Consumer实例根据队列分配策略算法为Consumer分配队列，平均分摊（默认）消费消息。例如，如果Topic是Test的消息发送到该主题的不同队列中，发送了有100条消息，其中一个ConsumerGroup有3个Consumer实例，那么根据队列分配算法，每个队列都会有消费者，每个消费者实例只消费自己队列上的数据，消费完的消息不能被其他消费实例消费。

在BROADCASTING模式下，消息会被所有在该Topic的ConsumerGroup中的Consumer实例共同消费。

请注意，消费模式在创建Consumer时指定，不同的消费模式其内部机制也不同，消息的消费方式、记录消费进度、消息的消费状态等也都各不相同。

列举RocketMQ发送的三种策略？

RocketMQ发送的三种策略如下：

同步（sync）：发送者向 MQ 执行发送消息API 时，同步等待，直到消息服务器返回发送结果。
异步（async）：发送者向MQ 执行发送消息API 时，指定消息发送成功后的回调函数，然后调用消息发送API 后，立即返回，消息发送者线程不阻塞，直到运行结束，消息发送成功或失败的回调任务在一个新的线程中返回。
单向（oneway）：消息发送者向MQ 执行发送消息API 时，直接返回，不等待消息服务器的结果，也不注册回调函数，只管发，不管是否成功存储在消息服务器上。

RocketMQ消费消息是push还是pull？

RocketMQ在消费消息时，既支持push模式，也支持pull模式。

push模式是指MQ主动推送信息给Consumer，但是可能会导致Consumer跟不上MQ的推送速度。为了解决这个问题，RocketMQ采用了一种长轮询的方式，即客户端访问MQ，有信息就拉取关闭连接消费，然后再请求并拉取。没有信息请求就会等待新信息，知道超时，超时会关闭连接并再次发送新的请求。实际上，RocketMQ的push模式也是拉取，源码证明。

pull模式是指由客户端主动向MQ请求数据，主动权在客户端，先拉取数据再消费。这种方式不会因为推送太快而处理不及时。

总的来说，RocketMQ的消费消息模式可以根据实际需求进行选择。

简述RocketMQ Producer 端的负载均衡机制？

RocketMQ Producer端的负载均衡机制主要依赖于一些负载均衡策略来实现。

首先，当Producer发送消息到Broker集群时，会利用一些负载均衡机制来平均分配给不同的Broker。具体来说，Producer在发送消息时，会根据指定的负载均衡策略（如轮询、随机等），将消息发送到不同的Broker。

另外，Producer还增加了隔离机制，这个功能默认是关闭的，但在高可用场景下建议开启。开启隔离机制后，每次发送消息时都会判断一下这个Broker是否被隔离，还会判断这个Broker是否是上一次选择的那个Broker。如果没有合适的Broker提供，则会启动默认的负载均衡策略进行重新选择。

解释Rebalance的危害？

Rebalance机制的本意是为了提升消息的并行消费能力，确保消息能被更有效地处理。然而，Rebalance机制在实际运行过程中，可能会出现一些问题，这就是我们所说的“Rebalance危害”。

首先，对于一个消费者组下的消费者实例数量大于队列的数量的情况，如果Rebalance机制启动，多余的消费者实例将分配不到任何队列，导致消费者空耗。

其次，提交间隔越长，可能会造成的重复消费就越多。这是因为Rebalance机制并不会等待Consumer1提交完offset后，再进⾏Rebalance。因此，如果提交间隔太长，可能会导致同一批消息被多个消费者同时消费，从而产生重复消费。

解释什么是RocketMQ的Rebalance机制？

RocketMQ的Rebalance机制是指在消息消费端，当新的消费者加入或退出消费组时，RocketMQ会自动重新平衡各个消费者的消费队列，以保证消费能力的最大化。

具体来说，RocketMQ采用的是Pull模式，消费者会定时向Broker发起拉取请求，获取可用的消息。在初始启动时，消费者会向Broker注册并获取分配到的消费队列，如果有新的消费者加入了消费组，Broker会重新计算消费队列的分配情况，将部分消费队列分配给新的消费者。如果有消费者退出消费组，则会重新将其所消费的队列分配给其他消费者。

简述RocketMQ的Broker消费者服务器的运行模式？

RocketMQ的Broker消费者服务器是一种消息中间件，它作为消息的生产者和消费者的中介，主要负责存储消息、转发消息。在RocketMQ系统中，Broker Server负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备，存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

Broker服务器一般以集群方式部署，可以支持多个Broker同时运行。在运行过程中，Broker服务器会根据一定的负载均衡策略将消息分配给不同的Broker。同时，Broker服务器还支持多种消息消费模式，包括Pull模式和Push模式。

在Pull模式下，消费者会定时向Broker发起拉取请求，获取可用的消息。在Push模式下，Broker服务器会主动将消息推送给消费者。此外，RocketMQ还支持多种发送方式，包括同步发送、异步发送、顺序发送和单向发送。其中同步和异步方式均需要Broker返回确认信息，而单向发送则不需要。

总的来说，RocketMQ的Broker消费者服务器运行模式是一种灵活、高效、可靠的消息传递模式，能够满足不同场景下的实时性、可靠性和可扩展性等需求。