本文仅用作个人学习复习使用！

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

基础篇

1 消息队列的用途

消息队列三大用途 : 解耦异步削峰;
第一方面 : 解耦: 系统耦合度降低,没有强依赖关系;

第二方面 : 异步, 不需要同步执行的远程调用可有效提高响应时间

第三方面 : 削峰 , 请求达到峰值后,后端Service还可以保持固定消费速率消费,不会被压垮
消息队列合一用来削峰;
比如秒杀系统, 秒杀时候流量陡增,服务器,Redis,MySQL承受能力不一样,有可能直接挂了;
这时候把请求丢到队列里面,只放出服务能处理的流量,就能抗住短时间大流量;

2 RocketMQ的优缺点

类别	RabbitMQ	ActiveMQ	RocketMQ	Kafka
公司	Rabbit	Apache	Alibaba	Apache
语言	Erlang	Java	Java	Scala
协议支持	AMQP	REST AMQP…	自定义	自定义协议
单机吞吐量	万级别③2.6w/s	万级别	十万级别①11w/s	十万级别②17w/s
消息延迟	微秒	毫秒	毫秒	毫秒以内
消息可靠性	-	较低概率丢数据	参数优化配置,可做到0丢失	经过参数配置,可做到0丢失
优势	语言,性能极好,延时很低,吞吐量万级,MQ功能完备		接口简单易用,吞吐量大,分布式扩展,社区活跃,支持大规模Topic,支持复杂业务场景	超高吞吐量,ms级别延时
劣势	吞吐量较低
语言不容易定制开发		接口不是按照标准JMS规范走,有系统迁移要修改大量代码	可能进行消息重复消费
应用	都有使用	主用于解耦和异步	用于大规模吞吐,复杂业务中	大数据实时计算和日志采集中大规模使用

综上所述 :
RocketMQ 的优点 :

单机吞吐量:十万级别
可用性: 非常高,分布式结构
消息可靠性 : 经过参数优化配置,消息可以做到 0 丢失
功能支持 : MQ功能较为完善,分布式,扩展性好
支持10 亿级别消息堆积,不会因为堆积导致性能下降
源码Java,方便二次开发
:::info
系统面向用户的C端系统,有一定并发量,对性能也有较高要求,所以选择低延迟,吞吐量比较高,可用性比较好的RocketMQ;
:::
缺点 :
支持的客户端语言不多, 目前是Java和C++(其中C++不成熟)
没有在MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码;

3 消息队列的消息模型

队列模型和发布/订阅模型;
队列模型:

发布订阅模型:

发布者将消息发送到主题中,订阅者在接收消息之前需要先 “订阅主题”.
"订阅"在这里既是一个动作,也可以理解是主题在消费时的一个逻辑副本,每份订阅中,订阅者都可接收到主题的所有消息;

生产者就是发布者, 队列就是主题, 消费者就是订阅者, 无本质区别.
唯一的不同就是 : 一份消息数据能否被多次消费;

4 RocketMQ的消息模型

标准的发布/订阅模型,

RocketMQ本身消息由下面几个部分组成:
Message 消息必须有一个主题,也可以拥有一个可选标签Tag;
Topic 主题,看作消息归类, 主题和生产者多对多的关系,主题也可以被0个,1个,多个消费者订阅;
Tag 标签看成子主题;
Group 订阅者概念通过消费组体现,每个消费者都消费主题中一份完整的消息,消费组之间可重复消费,消费组内部是竞争关系
Message Queue 消息队列一个主题下可设置多个消息队列,
Offset 为每个消费者在每个队列维护一个消费位置(Consumer Offset)

5 消息消费模式

默认情况是集群消费 (Clustering) 这种模式下一个消费者组共同消费一个主题的多个队列,一个队列只会被一个消费者消费; 如果某个消费者挂掉,分组内其它消费者会接替挂掉的消费者继续消费;

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

广播消费消息会发给消费者组的每一个消费者进行消费;

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

6 RocketMQ基本架构

NameServer
动态列表,无状态服务器,. 好比ZK(但是ZK有状态);
特点 :

每个NS结点间相互独立,彼此没有任何信息交互;
功能一:和Broker结点保持长连接; 功能二:维护Topic的路由信息;

Broker
消息存储和中转角色,负责存储和转发消息; 就是MQ本身,收发消息/持久化消息等;

Broker内部维护 Consumer Queue 用来存储消息索引,真正存储消息的地方是 CommitLog(日志文件);
单个Broker和所有NS保持长连接和心跳,定时将 Topic 信息同步到NS,和NS通信底层是通过Netty实现;

Producer
消息生产者,业务端负责发送消息,用户自行实现和分布式部署

Producer用户进行分布式部署,消息通过多种负载均衡模式发送到Broker集群,发送低延时,支持快速失败;
RocketMQ提供三种方式发送消息
- 同步发送: 收到响应再发下一个数据包,用于重要通知消息,邮件和营销短信;
- 异步发送:不等回应,直接发下一个数据包,比如用户视频上传后通知启动转码服务;
- 单向发送:只负责发,不等服务器回应且没有回调函数触发,比如日志收集;

Consumer
消息消费者, 一般是后台系统负责异步消费

Consumer由用户部署,支持 PUSH 和 PULL 两种消费模式,支持集群消费和广播消费,提供实时消息订阅机制;
PULL 拉取型消费者,主动从消息服务器拉取信息,只要批量拉取到消息,用户应用就会启动消费过程,主动消费型
PUSH 推送型消费者,封装消息拉取,消费进度和其它内部维护工作,将消息到达时执行的回调接口留给用户应用程序实现,被动消费类型. 其实从实现看还是从消息服务器拉取消息,只不过PUSH首先要注册消费监听器,当监听器处触发后才开始消费消息;

进阶篇

7 保证消息不丢失/可用/可靠

生产阶段
主要通过请求确认机制,保证消息可靠传递.

1、同步发送的时候，要注意处理响应结果和异常。如果返回响应OK，表示消息成功发送到了Broker，如果响应失败，或者发生其它异常，都应该重试。
2、异步发送的时候，应该在回调方法里检查，如果发送失败或者异常，都应该进行重试。
3、如果发生超时的情况，也可以通过查询日志的API，来检查是否在Broker存储成功。

存储阶段
可以通过配置可靠性优先的 Broker 参数来避免因为宕机丢消息，简单说就是可靠性优先的场景都应该使用同步。

1、消息只要持久化到CommitLog（日志文件）中，即使Broker宕机，未消费的消息也能重新恢复再消费。
2、Broker的刷盘机制：同步刷盘和异步刷盘，不管哪种刷盘都可以保证消息一定存储在pagecache中（内存中），但是同步刷盘更可靠，它是Producer发送消息后等数据持久化到磁盘之后再返回响应给Producer。
3、Broker通过主从模式来保证高可用，Broker支持Master和Slave同步复制、Master和Slave异步复制模式，生产者的消息都是发送给Master，但是消费既可以从Master消费，也可以从Slave消费。同步复制模式可以保证即使Master宕机，消息肯定在Slave中有备份，保证了消息不会丢失。

消费
从Consumer角度分析，如何保证消息被成功消费？

Consumer保证消息成功消费的关键在于确认的时机，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。因为消息队列维护了消费的位置，逻辑执行失败了，没有确认，再去队列拉取消息，就还是之前的一条。

8 解决消息重复的问题

分布式消息队列,"有且仅有一次"就是确保一定投递和不重复投递比较难,RocketMQ选择了确保一定投递,保证消息不丢失,但可能造成消息重复.
就需要业务端自己保证,主要方式有两种: 业务幂等和消息去重;
业务幂等：第一种是保证消费逻辑的幂等性，也就是多次调用和一次调用的效果是一样的。这样一来，不管消息消费多少次，对业务都没有影响。
消息去重：第二种是业务端，对重复的消息就不再消费了。这种方法，需要保证每条消息都有一个惟一的编号，通常是业务相关的，比如订单号，消费的记录需要落库，而且需要保证和消息确认这一步的原子性。
具体做法是可以建立一个消费记录表，拿到这个消息做数据库的insert操作。给这个消息做一个唯一主键（primary key）或者唯一约束，那么就算出现重复消费的情况，就会导致主键冲突，那么就不再处理这条消息。

9 处理消息挤压

消费者扩容：如果当前Topic的Message Queue的数量大于消费者数量，就可以对消费者进行扩容，增加消费者，来提高消费能力，尽快把积压的消息消费玩。
消息迁移Queue扩容：如果当前Topic的Message Queue的数量小于或者等于消费者数量，这种情况，再扩容消费者就没什么用，就得考虑扩容Message Queue。可以新建一个临时的Topic，临时的Topic多设置一些Message Queue，然后先用一些消费者把消费的数据丢到临时的Topic，因为不用业务处理，只是转发一下消息，还是很快的。接下来用扩容的消费者去消费新的Topic里的数据，消费完了之后，恢复原状

10 顺序消息如何实现

顺序消息是指消息的消费顺序和产生顺序相同，在有些业务逻辑下，必须保证顺序，比如订单的生成、付款、发货，这个消息必须按顺序处理才行
顺序消息分为全局顺序消息和部分顺序消息，全局顺序消息指某个 Topic 下的所有消息都要保证顺序；
部分顺序消息只要保证每一组消息被顺序消费即可，比如订单消息，只要保证同一个订单 ID 个消息能按顺序消费即可。
#部分顺序消息
部分顺序消息相对比较好实现，生产端需要做到把同 ID 的消息发送到同一个 Message Queue ；在消费过程中，要做到从同一个Message Queue读取的消息顺序处理——消费端不能并发处理顺序消息，这样才能达到部分有序。
全局顺序消息
RocketMQ 默认情况下不保证顺序，比如创建一个 Topic ，默认八个写队列，八个读队列，这时候一条消息可能被写入任意一个队列里；在数据的读取过程中，可能有多个 Consumer ，每个 Consumer 也可能启动多个线程并行处理，所以消息被哪个 Consumer 消费，被消费的顺序和写人的顺序是否一致是不确定的。
要保证全局顺序消息，需要先把 Topic 的读写队列数设置为一，然后Producer Consumer 的并发设置，也要是一。简单来说，为了保证整个 Topic全局消息有序，只能消除所有的并发处理，各部分都设置成单线程处理，这时候就完全牺牲RocketMQ的高并发、高吞吐的特性了。

11 实现消息过滤

两种方案：

一种是在 Broker 端按照 Consumer 的去重逻辑进行过滤，这样做的好处是避免了无用的消息传输到 Consumer 端，缺点是加重了 Broker 的负担，实现起来相对复杂。
另一种是在 Consumer 端过滤，比如按照消息设置的 tag 去重，这样的好处是实现起来简单，缺点是有大量无用的消息到达了 Consumer 端只能丢弃不处理。

一般采用Cosumer端过滤，如果希望提高吞吐量，可以采用Broker过滤。
对消息的过滤有三种方式：

// 根据Tag过滤：这是最常见的一种，用起来高效简单
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_EXAMPLE");
consumer.subscribe("TOPIC", "TAGA || TAGB || TAGC");

// SQL 表达式过滤：SQL表达式过滤更加灵活
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name_4");
// 只有订阅的消息有这个属性a, a >=0 and a <= 3
consumer.subscribe("TopicTest", MessageSelector.bySql("a between 0 and 3");
consumer.registerMessageListener(new MessageListenerConcurrently() {
    
    
   @Override
   public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
    
    
       return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
   }
});
consumer.start();

Filter Server 方式：最灵活，也是最复杂的一种方式，允许用户自定义函数进行过滤

12 延时消息

//RocketMQ是支持延时消息的，只需要在生产消息的时候设置消息的延时级别：
// 实例化一个生产者来产生延时消息
DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
// 启动生产者
producer.start();
int totalMessagesToSend = 100;
for (int i = 0; i < totalMessagesToSend; i++) {
    
    
    Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
    // 设置延时等级3,这个消息将在10s之后发送(现在只支持固定的几个时间,详看delayTimeLevel)
    message.setDelayTimeLevel(3);
    // 发送消息
    producer.send(message);
}

//但是目前RocketMQ支持的延时级别是有限的：
private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

// 临时存储+定时任务
// Broker收到延时消息了，会先发送到主题（SCHEDULE_TOPIC_XXXX）的相应时间段的Message Queue中，
//然后通过一个定时任务轮询这些队列，到期后，把消息投递到目标Topic的队列中，
//然后消费者就可以正常消费这些消息。

13 死信队列

死信队列用于处理无法被正常消费的消息，即死信消息。
当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中，该特殊队列称为死信队列。
死信消息的特点：

不会再被消费者正常消费。
有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，需要在死信消息产生后的 3 天内及时处理。

死信队列的特点：

一个死信队列对应一个 Group ID，而不是对应单个消费者实例。
如果一个 Group ID 未产生死信消息，消息队列 RocketMQ 不会为其创建相应的死信队列。
一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。

RocketMQ 控制台提供对死信消息的查询、导出和重发的功能。

原理篇

14 RocketMQ 整体工作流程

简单来说，RocketMQ是一个分布式消息队列，也就是消息队列+分布式系统。
作为消息队列，它是发-存-收的一个模型，对应的就是Producer、Broker、Cosumer；作为分布式系统，它要有服务端、客户端、注册中心，对应的就是Broker、Producer/Consumer、NameServer
所以我们看一下它主要的工作流程：RocketMQ由NameServer注册中心集群、Producer生产者集群、Consumer消费者集群和若干Broker（RocketMQ进程）组成：

Broker在启动的时候去向所有的NameServer注册，并保持长连接，每30s发送一次心跳
Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择一台服务器来发送消息
Conusmer消费消息的时候同样从NameServer获取Broker地址，然后主动拉取消息来消费

15 RocketMQ怎么对文件进行读写的？

RocketMQ对文件的读写巧妙地利用了操作系统的一些高效文件读写方式——PageCache、顺序读写、零拷贝。

PageCache、顺序读取

在RocketMQ中，ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取，在page cache机制的预读取作用下，Consume Queue文件的读性能几乎接近读内存，即使在有消息堆积情况下也不会影响性能。而对于CommitLog消息存储的日志数据文件来说，读取消息内容时候会产生较多的随机访问读取，严重影响性能。如果选择合适的系统IO调度算法，比如设置调度算法为“Deadline”（此时块存储采用SSD的话），随机读的性能也会有所提升。
页缓存（PageCache)是OS对文件的缓存，用于加速对文件的读写。一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写速度，主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。对于数据的写入，OS会先写入至Cache内，随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。对于数据的读取，如果一次读取文件时出现未命中PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取。

零拷贝

另外，RocketMQ主要通过MappedByteBuffer对文件进行读写操作。其中，利用了NIO中的FileChannel模型将磁盘上的物理文件直接映射到用户态的内存地址中（这种Mmap的方式减少了传统IO，将磁盘文件数据在操作系统内核地址空间的缓冲区，和用户应用程序地址空间的缓冲区之间来回进行拷贝的性能开销），将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率（正因为需要使用内存映射机制，故RocketMQ的文件存储都使用定长结构来存储，方便一次将整个文件映射至内存）。

#说说什么是零拷贝?

在操作系统中，使用传统的方式，数据需要经历几次拷贝，还要经历用户态/内核态切换。

图片来源 <图解操作系统>

从磁盘复制数据到内核态内存；
从内核态内存复制到用户态内存；
然后从用户态内存复制到网络驱动的内核态内存；
最后是从网络驱动的内核态内存复制到网卡中进行传输。

所以，可以通过零拷贝的方式，减少用户态与内核态的上下文切换和内存拷贝的次数，用来提升I/O的性能。零拷贝比较常见的实现方式是mmap，这种机制在Java中是通过MappedByteBuffer实现的。

图片来源 <图解操作系统>

16 消息刷盘

RocketMQ提供了两种刷盘策略：同步刷盘和异步刷盘

同步刷盘：在消息达到Broker的内存之后，必须刷到commitLog日志文件中才算成功，然后返回Producer数据已经发送成功。
异步刷盘：异步刷盘是指消息达到Broker内存后就返回Producer数据已经发送成功，会唤醒一个线程去将数据持久化到CommitLog日志文件中。

Broker 在消息的存取时直接操作的是内存（内存映射文件），这可以提供系统的吞吐量，但是无法避免机器掉电时数据丢失，所以需要持久化到磁盘中。
刷盘的最终实现都是使用NIO中的 MappedByteBuffer.force() 将映射区的数据写入到磁盘，如果是同步刷盘的话，在Broker把消息写到CommitLog映射区后，就会等待写入完成。
异步而言，只是唤醒对应的线程，不保证执行的时机，流程如下图所示。

17 RocketMQ 的负载均衡如何实现

RocketMQ中的负载均衡都在Client端完成，具体来说的话，主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡。
Producer的负载均衡
Producer端在发送消息的时候，会先根据Topic找到指定的TopicPublishInfo，在获取了TopicPublishInfo路由信息后，RocketMQ的客户端在默认方式下selectOneMessageQueue()方法会从TopicPublishInfo中的messageQueueList中选择一个队列（MessageQueue）进行发送消息。具这里有一个sendLatencyFaultEnable开关变量，如果开启，在随机递增取模的基础上，再过滤掉not available的Broker代理。

// 选择一个消息队列
public MessageQueue test(){
    
    
    // 索引递增
    int index  = this.sendWhichQueue.incrementAndGet();
    // 利用索引取随机数,取余
    int pos = Math.abs(index) % this.messageQueueList.size();
    if (pos <0 )
        pos = 0;
    return this.messageQueueList.get(pos);
}

“latencyFaultTolerance”，是指对之前失败的，按一定的时间做退避。例如，如果上次请求的latency超过550Lms，就退避3000Lms；超过1000L，就退避60000L；如果关闭，采用随机递增取模的方式选择一个队列（MessageQueue）来发送消息，latencyFaultTolerance机制是实现消息发送高可用的核心关键所在。

默认策略随机选择:

producer维护一个index

每次取节点会自增

index向所有broker个数取余

自带容错策略

#Consumer的负载均衡
在RocketMQ中，Consumer端的两种消费模式（Push/Pull）都是基于拉模式来获取消息的，而在Push模式只是对pull模式的一种封装，其本质实现为消息拉取线程在从服务器拉取到一批消息后，然后提交到消息消费线程池后，又“马不停蹄”的继续向服务器再次尝试拉取消息。如果未拉取到消息，则延迟一下又继续拉取。在两种基于拉模式的消费方式（Push/Pull）中，均需要Consumer端知道从Broker端的哪一个消息队列中去获取消息。因此，有必要在Consumer端来做负载均衡，即Broker端中多个MessageQueue分配给同一个ConsumerGroup中的哪些Consumer消费。

Consumer端的心跳包发送

在Consumer启动后，它就会通过定时任务不断地向RocketMQ集群中的所有Broker实例发送心跳包（其中包含了，消息消费分组名称、订阅关系集合、消息通信模式和客户端id的值等信息）。Broker端在收到Consumer的心跳消息后，会将它维护在ConsumerManager的本地缓存变量—consumerTable，同时并将封装后的客户端网络通道信息保存在本地缓存变量—channelInfoTable中，为之后做Consumer端的负载均衡提供可以依据的元数据信息。

Consumer端实现负载均衡的核心类—RebalanceImpl

在Consumer实例的启动流程中的启动MQClientInstance实例部分，会完成负载均衡服务线程—RebalanceService的启动（每隔20s执行一次）。
通过查看源码可以发现，RebalanceService线程的run()方法最终调用的是RebalanceImpl类的rebalanceByTopic()方法，这个方法是实现Consumer端负载均衡的核心。

采用平均分配算法

18 RocketMQ 消息长轮询

长轮询，就是Consumer 拉取消息，如果对应的 Queue 如果没有数据，Broker 不会立即返回，而是把 PullReuqest hold起来，等待 queue 有了消息后，或者长轮询阻塞时间到了，再重新处理该 queue 上的所有 PullRequest。

//如果没有拉到数据
case ResponseCode.PULL_NOT_FOUND:
// broker 和 consumer 都允许 suspend，默认开启
if (brokerAllowSuspend && hasSuspendFlag) {
    
    
    long pollingTimeMills = suspendTimeoutMillisLong;
    if (!this.brokerController.getBrokerConfig().isLongPollingEnable()) {
    
    
        pollingTimeMills = this.brokerController.getBrokerConfig().getShortPollingTimeMills();
    }

    String topic = requestHeader.getTopic();
    long offset = requestHeader.getQueueOffset();
    int queueId = requestHeader.getQueueId();
    //封装一个PullRequest
    PullRequest pullRequest = new PullRequest(request, channel, pollingTimeMills,
            this.brokerController.getMessageStore().now(), offset, subscriptionData, messageFilter);
    //把PullRequest挂起来
    this.brokerController.getPullRequestHoldService().suspendPullRequest(topic, queueId, pullRequest);
    response = null;
    break;
}

// 挂起的请求，有一个服务线程会不停地检查，看queue中是否有数据，或者超时
@Override
public void run() {
    
    
    log.info("{} service started", this.getServiceName());
    while (!this.isStopped()) {
    
    
        try {
    
    
            if (this.brokerController.getBrokerConfig().isLongPollingEnable()) {
    
    
                this.waitForRunning(5 * 1000);
            } else {
    
    
                this.waitForRunning(this.brokerController.getBrokerConfig().getShortPollingTimeMills());
            }

            long beginLockTimestamp = this.systemClock.now();
            //检查hold住的请求
            this.checkHoldRequest();
            long costTime = this.systemClock.now() - beginLockTimestamp;
            if (costTime > 5 * 1000) {
    
    
                log.info("[NOTIFYME] check hold request cost {} ms.", costTime);
            }
        } catch (Throwable e) {
    
    
            log.warn(this.getServiceName() + " service has exception. ", e);
        }
    }

    log.info("{} service end", this.getServiceName());
}

写在最后，如果觉得对你有帮助，麻烦点赞加关注，谢谢！
周日愉快！⭐⭐⭐

RocketMQ面试题八股文【2023】

基础篇

1 消息队列的用途

2 RocketMQ的优缺点

3 消息队列的消息模型

4 RocketMQ的消息模型

5 消息消费模式

6 RocketMQ基本架构

进阶篇

7 保证消息不丢失/可用/可靠

8 解决消息重复的问题

9 处理消息挤压

10 顺序消息如何实现

11 实现消息过滤

12 延时消息

13 死信队列

原理篇

14 RocketMQ 整体工作流程

15 RocketMQ怎么对文件进行读写的？

#说说什么是零拷贝?

16 消息刷盘

17 RocketMQ 的负载均衡如何实现

18 RocketMQ 消息长轮询

猜你喜欢

RocketMQ面试题八股文 【2023】

基础篇

1 消息队列的用途

2 RocketMQ的优缺点

3 消息队列的消息模型

4 RocketMQ的消息模型

5 消息消费模式

6 RocketMQ基本架构

进阶篇

7 保证消息不丢失/可用/可靠

8 解决消息重复的问题

9 处理消息挤压

10 顺序消息如何实现

11 实现消息过滤

12 延时消息

13 死信队列

原理篇

14 RocketMQ 整体工作流程

15 RocketMQ怎么对文件进行读写的？

#说说什么是零拷贝?

16 消息刷盘

17 RocketMQ 的负载均衡如何实现

18 RocketMQ 消息长轮询

猜你喜欢

RocketMQ面试题八股文【2023】