RocketMQ 面试题（爪哇程序员）

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

原文：https://zwmst.com/1451.html

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

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

原文：https://zwmst.com/1453.html

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

RocketMQ消费模式有几种？

原文：https://zwmst.com/1455.html

集群消费

一条消息只会被同Group中的一个Consumer消费

多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据

广播消费

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

消费消息是push还是pull？

原文：https://zwmst.com/1457.html

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

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

broker如何处理拉取请求的？

原文：https://zwmst.com/1459.html

Consumer首次请求Broker

Broker中是否有符合条件的消息 如果有

响应Consumer

等待下次Consumer的请求

如果没有

DefaultMessageStore#ReputMessageService#run方法

PullRequestHoldService 来Hold连接，每个5s执行一次检查pullRequestTable有没有消 息，有的话立即推送

每隔1ms检查commitLog中是否有新消息，有的话写入到pullRequestTable

当有新消息的时候返回请求

挂起consumer的请求，即不断开连接，也不返回数据

使用consumer的offset

RocketMQ如何做负载均衡？

原文：https://zwmst.com/1461.html

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

1）producer端

发送端指定message queue发送消息到相应的broker，来达到写入时的负载均衡： 提升写入吞吐量，当多个producer同时向一个broker写入数据的时候，性能会下降 消息分布在多broker中，为负载消费做准备

默认策略是随机选择：

producer维护一个index

每次取节点会自增

index向所有broker个数取余 自带容错策略

其他实现：

SelectMessageQueueByHash

hash的是传入的args

SelectMessageQueueByRandom SelectMessageQueueByMachineRoom 没有实现

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

2）consumer端

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

其他负载均衡算法

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

消息重复消费如何解决？

原文：https://zwmst.com/1463.html

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

引起重复消费的原因

1）ACK

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

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

2）消费模式

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

解决方案

1）数据库表

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

2）Map

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

3）Redis

分布式锁搞起来。

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

原文：https://zwmst.com/1465.html

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

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

RocketMQ如何保证消息不丢失？

原文：https://zwmst.com/1467.html

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

Producer端

Broker端

Consumer端

1）Producer端如何保证消息不丢失

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

producer.setRetryTimesWhenSendFailed(10);

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

2）Broker端如何保证消息不丢失

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

flushDiskType = SYNC_FLUSH

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

3）Consumer端如何保证消息不丢失

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

rocketMQ的消息堆积如何处理

原文：https://zwmst.com/1469.html

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

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

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

原文：https://zwmst.com/1471.html

分布式系统中的事务可以使用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。

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

原文：https://zwmst.com/1473.html

需要考虑能快速扩容、天然支持集群

持久化的姿势

高可用性

数据0丢失的考虑

服务端部署简单、client端使用简单

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

原文：https://zwmst.com/1475.html

1）开发

同一group下，多机部署，并行消费

单个Consumer提高消费线程个数

批量消费。消息批量拉取，业务逻辑批量处理。

2）运维

网卡调优

jvm调优

多线程与cpu调优 Page Cache

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

原文：https://zwmst.com/1477.html

在不开启容错的情况下，轮询队列进行发送，如果失败了，重试的时候过滤失败的Broker

如果开启了容错策略，会通过RocketMQ的预测机制来预测一个Broker是否可用

如果上次失败的Broker可用那么还是会选择该Broker的队列

如果上述情况失败，则随机选择一个进行发送

在发送消息的时候会记录一下调用的时间与是否报错，根据该时间去预测broker的可用时间

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

原文：https://zwmst.com/1479.html

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

---

我们一直在努力

apachecn/AiLearning

---