Go最全RocketMQ 面试题总结_rocketmq面试，2024年最新小红书Golang面试题目

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

// 1. 创建消费者（Push）对象
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“GROUP_TEST”);

---


### 如何保证消息的顺序消费


首先多个 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 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);
}

---


### 消息重复消费


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


引起重复消费的原因  
 **ACK**  
 正常情况下在 consumer 真正消费完消息后应该发送 ack，通知 broker 该消息已正常消费，从 queue 中剔除  
 当 ack 因为网络原因无法发送到 broker，broker 会认为此条消息没有被消费，此后会开启消息重投机制把消息再次投递到 consumer


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


**解决方案**  
 去重操作直接放在了**消费端**，消费端处理消息的业务逻辑保持幂等性。那么不管来多少条重复消息，可以实现处理的结果都一样。




---


### Broker中的消息被消费后会立即删除吗？


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


追问：那么消息会堆积吗？什么时候清理过期消息？  
 默认72小时后会删除不再使用的 CommitLog 文件


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




---


### 如何保证消息不丢失


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


* Producer端
* Broker端
* Consumer端


#### Producer端如何保证消息不丢失


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


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


#### Broker端如何保证消息不丢失


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


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


#### Consumer端如何保证消息不丢失


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




---


### 消息堆积如何处理


首先要分析一下消息堆积可能造成的原因


1、如果是机器本身的原因，比如消费者组有几个消费者服务挂掉了，剩下少量消费者消费能力不足导致的消费积压，那就正常重新启动，然后慢慢再去消费积压的消息。


2、如果是生产者端由业务暴增引起的生产过快，而消费者端消费能力不足，这个时候就可以采取**生产者端限流**或者进行**消费者扩容**；这个时候要注意，如果生产者只是短期暴增或者消息的业务不是很重要可以采用限流，如果是长期暴增真正的业务量上涨就必须要进行消费者扩容。


3、如果是消费者挂了，然后 broker 堆积了很多消息，然后可以先把堆积的消息读到别的地方比如 mysql 或者 es 然后去后续进行处理，然后把 RocketMQ 堆积的消息删掉，启动消费者保障消费者正常消费，这里要注意的是删除堆积消息之前，需要停止 mq。




---


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


开发  
 同一 group 下，多机部署，并行消费  
 单个 Consumer 提高消费线程个数  
 批量消费  
 消息批量拉取  
 业务逻辑批量处理  
 运维  
 网卡调优  
 jvm 调优  
 多线程与 cpu 调优  
 Page Cache




---


### RocketMQ是如何保证数据的高容错性的?


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




---


### broker 如何处理拉取请求


Consumer 首次请求 Broker：  
 判断 Broker 中是否有符合条件的消息


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




---


### RocketMQ 的存储机制


RocketMq采用文件系统进行消息的存储，相对于ActiveMq采用关系型数据库进行存储的方式就更直接，性能更高了


RocketMq与Kafka在写消息与发送消息上，继续沿用了Kafka的这两个方面：顺序写和零拷贝


**1）顺序写**  
 我们知道，操作系统每次从磁盘读写数据的时候，都需要找到数据在磁盘上的地址，再进行读写。而如果是机械硬盘，寻址需要的时间往往会比较长而一般来说，如果把数据存储在内存上面，少了寻址的过程，性能会好很多；  
 但Kafka 的数据存储在磁盘上面，依然性能很好，这是为什么呢？  
 这是因为，Kafka采用的是顺序写，直接追加数据到末尾。实际上，磁盘顺序写的性能极高，在磁盘个数一定，转数一定的情况下，基本和内存速度一致  
 因此，磁盘的顺序写这一机制，极大地保证了Kafka本身的性能


**2）零拷贝**  
 比如：读取文件，再用socket发送出去这一过程


buffer = File.read  
 Socket.send(buffer)


传统方式实现：  
 先读取、再发送，实际会经过以下四次复制  
 1、将磁盘文件，读取到操作系统内核缓冲区Read Buffer  
 2、将内核缓冲区的数据，复制到应用程序缓冲区Application Buffer  
 3、将应用程序缓冲区Application Buffer中的数据，复制到socket网络发送缓冲区  
 4、将Socket buffer的数据，复制到网卡，由网卡进行网络传输  
 ![在这里插入图片描述](https://img-blog.csdnimg.cn/f5653c2e112046a7be4b48d0566ab7a9.png)


传统方式，读取磁盘文件并进行网络发送，经过的四次数据copy是非常繁琐的  
 重新思考传统IO方式，会注意到在读取磁盘文件后，不需要做其他处理，直接用网络发送出去的这种场景下，第二次和第三次数据的复制过程，不仅没有任何帮助，反而带来了巨大的开销。那么这里使用了零拷贝，也就是说，直接由内核缓冲区Read Buffer将数据复制到网卡，省去第二步和第三步的复制。


![img](https://img-blog.csdnimg.cn/img_convert/42fd4f8145e8be6b909dd96b6c98f8f5.png)
![img](https://img-blog.csdnimg.cn/img_convert/52ee98d17b925030781ebfe9a9f0b4a4.png)
![img](https://img-blog.csdnimg.cn/img_convert/a82654bad46deb5cf6d0e4fd582b3e21.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[如果你需要这些资料，可以戳这里获取](https://bbs.csdn.net/topics/618658159)**

中...(img-ujSfeqaq-1715818645707)]
[外链图片转存中...(img-RwDKcXvM-1715818645708)]

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[如果你需要这些资料，可以戳这里获取](https://bbs.csdn.net/topics/618658159)**