RocketMQ 面试题

多个 MQ 如何选型？

MQ	描述
RabbitMQ	erlang 开发，对消息堆积的支持并不好，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。每秒钟可以处理几万到十几万条消息。
RocketMQ	Java 开发，面向互联网集群化功能丰富，对在线业务的响应时延做了很多的优化，大多数情况下可以做到毫秒级的响应，每秒钟大概能处理几十万条消息。
Kafka	Scala 开发，面向日志功能丰富，性能最高。当你的业务场景中，每秒钟消息数量没有那么多的时候， Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。
ActiveMQ	Java 开发，简单，稳定，性能不如前面三个。小型系统用也可以，但是不推荐。推荐用互联网主流的。

为什么要使用 MQ？

因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了 MQ。

作用	描述
解耦	系统耦合度降低，没有强依赖关系。
异步	不需要同步执行的远程调用可以有效提高响应时间。
削峰	请求达到峰值后，后端 service 还可以保持固定消费速率消费，不会被压垮。

RocketMQ 由哪些角色组成，每个角色作用和特点是什么？

角色	作用
Nameserver	无状态，动态列表；这是和 ZooKeeper 的重要区别之一。ZooKeeper 是有状态的。
Producer	消息生产者，负责发消息到 Broker。
Broker	就是 MQ 本身，负责收发消息、持久化消息等。
Consumer	消息消费者，负责从 Broker 上拉取消息进行消费，消费完进行 ack。

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

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

RocketMQ 消费模式有几种？

消费模型由 Consumer 决定，消费维度为 Topic。

集群消费

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

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

广播消费

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

Broker 如何处理拉取请求的？

Consumer 首次请求 Broker。

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

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<MESSAGEQUEUE> 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 空余出来，白白的浪费了。