RocketMQ经典高频面试题大全（附答案）_rocketmq面试题

/**
* {@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的请求
* 没有
	+ 挂起consumer的请求，即不断开连接，也不返回数据
	+ 使用consumer的offset，
		- DefaultMessageStore#ReputMessageService#run方法
			* 每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable
			* 当有新消息的时候返回请求
		- PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消息，有的话立即推送


### 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 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、消息重复消费


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


**引起重复消费的原因**


* ACK


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


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


* 消费模式


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


**解决方案**


* 数据库表


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


* Map


单机时可以使用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 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），16次（默认16次）才会进入死信队列（%DLQ%+ConsumerGroup）。


源码如下：

public class SubscriptionGroupConfig {
private int retryMaxTimes = 16;
}

// {@link org.apache.rocketmq.broker.processor.SendMessageProcessor#asyncConsumerSendMsgBack}
// maxReconsumeTimes = 16
int maxReconsumeTimes = subscriptionGroupConfig.getRetryMaxTimes();
// 如果重试次数大于等于16，则创建死信队列
if (msgExt.getReconsumeTimes() >= maxReconsumeTimes || delayLevel < 0) {
// MixAll.getDLQTopic()就是给原有groupname拼上DLQ，死信队列
newTopic = MixAll.getDLQTopic(requestHeader.getGroup());
// 创建死信队列
topicConfig = this.brokerController.getTopicConfigManager().createTopicInSendMessageBackMethod(xxx)
}

扩展：每次重试的时间间隔：

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

> 
> 看到这个源码你可能蒙蔽了，这不是18个时间间隔嘛。怎么是16次？继续看下面代码，我TM也懵了。
> 
> 
> 
> ```
> /\*\*
>  \* {@link org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl#sendMessageBack()}
>  \*
>  \* sendMessageBack()这个方法是消费失败后会请求他，意思是把消息重新放到队列，进行重试。
>  \*/
> public void sendMessageBack(MessageExt msg, int delayLevel, final String brokerName) {
>     Message newMsg = new Message();
>     // ！！！我TM，真相了，3 + xxx。他是从第三个开始的。也就是舍弃了前两个时间间隔，18 - 2 = 16。也就是说第一次重试是在10s，第二次30s。
>     // TMD！！！
>     // TMD！！！
>     // TMD！！！
>     newMsg.setDelayTimeLevel(3 + msg.getReconsumeTimes());
> 	this.mQClientFactory.getDefaultMQProducer().send(newMsg);
>  }
> 
> ```
> 
> 


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



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


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


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


**RocketMQ实现方式：**




![img](https://img-blog.csdnimg.cn/img_convert/6c67ebcdde15536459db54381b3be187.png)
![img](https://img-blog.csdnimg.cn/img_convert/fa863216a3836b2a98147767729e67cf.png)

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


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



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


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


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


**RocketMQ实现方式：**




[外链图片转存中...(img-sOAaayNc-1726095921961)]
[外链图片转存中...(img-fKVNvvu6-1726095921961)]

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