RocketMQ面试题大全
目录
Q：使用RocketMQ过程中遇到过什么问题？又是怎么解决的？
文档索引
面试题汇总
Q：什么是消息中间件？有哪些消息中间件？你又是如何选型的？
A： 消息中间件：消息中间件-选型
Q：RocketMQ的总体架构，以及每个组件的功能
A：RocketMQ架构上分四部分构成：Producer、Consumer、Broker、NameServer
Producer
负责生产消息，通过MQ的负载均衡模块选择Broker集群队列进行消息投递，投递过程支持快速失败并且低延迟。
Consumer
消息消费者会从Broker服务器中获取消息，并对消息进行业务才处理
Broker
Broker主要用于存储和转发消息，Broker有几个子模块：
客户端管理器：管理客户端，并且维护consumer的的topic订阅信息
存储服务：提供简单api处理消息存储磁盘及消息查询功能
高可用服务：提供master和slave之间的消息同步功能
索引服务：为消息构建索引，并提供消息查找功能
NameServer
是一个轻量的注册中心，NameServer主要有以下两个功能
Broker管理：接受Broker集群的注册信息并保存作为路由信息的基本数据，提供心跳检测机制，检查Broker是否存活
路由信息管理：保存Broker集群整个路由信息和用于客户端查询的队列信息，Producer和Consumer通过NameServer获取整个Broker集群的路由信息，进行消息的投递和消费。
Q：什么是路由注册？RocketMQ如何进行路由注册？
A：Broker为证明自己存活，会将最新信息以心跳包的方式上报给NameServer，每30秒将BrokerId， Broker地址，Broker名称，所属集群名称等信息发送给NameServer，NameServer收到心跳包后会记录Broker的最新存活时间
Q：什么是路由剔除？RocketMQ如何进行路由剔除？
A：由于Broker关机，宕机或网络抖动等原因，NameServer会没有收到Broker的心跳，NameServer中有一个定时任务，每隔10秒扫描一次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker时效，将该Broker从列表中剔除
Q：什么是路由发现？RocketMQ如何进行路由发现？
A：RocketMQ的路由发现采用的是PULL模型，当Topic路由信息出现变化时，NameServer不会主动推送给客户端，客户端默认每30秒会从NameServer中拉取一次最新的路由
Q：客户端NameServer选择策略
A：客户端首先产生一个随机数，与NameServer节点数量取模，然后进行连接，如果连接失败，则会采用round-robin策略，逐个尝试与其他节点连接
Q：Broker的部署方式
A：
1）单Master
单机模式, 即只有一个Broker
2）多Master模式
组成一个集群, 集群每个节点都是Master节点
3）多Master多Slave模式
每个Master配置一个Slave，集群中存在多对Master-Slave，生产常用该部署方式。
| 单Master | 多Master | 多Master多Slave模式 | |
| 优点 | 成本低 | 性能高 | 节点宕机可切换至Slave继续消费，保证可用性 |
| 缺点 | 存在单点问题，不推荐 | 宕机节点消息不能被消费 | 成本高，性能较低 |
Q：Broker的刷盘策略有哪些？
A：
生产者将消息发送给Broker，此时Broker是将消息写入内存中，然后根据不同的刷盘策略，将消息持久化到磁盘中。
同步刷盘：当消息持久化当Broker磁盘后，消息才算是写入成功，Broker返回成功标识给到客户端
异步刷盘：当消息写入内存中，消息就算是写入成功，Broker返回成功标识给到客户端，不等待消息持久化到磁盘
| 同步刷盘 | 异步刷盘 | |
| 优点 | 保证消息持久化成功 | 吞吐量较高 |
| 缺点 | 吞吐量较低 | 宕机可能引起消息丢失 |
Q：Broker的复制策略有哪些？
A：
复制策略是Broker的master和slave之间的数据同步方式，分同步双写和异步复制
同步双写：只有master和slave都写成功以后，才会向客户端返回成功
异步复制：消息写入master成功后，就返回给客户端成功，不会等待Slave写入成功
| 同步双写 | 异步复制 | |
| 优点 | slave消息不会丢失 | 性能较同步双写高 |
| 缺点 | 吞吐量、性能较异步复制低10% | 节点宕机可能导致消息丢失 |
Q：Topic的配置信息
A：
Topic有两种模式进行创建，创建Topic时除TopicName外，还需配置读写队列数量及perm
创建模式
集群模式：创建的Topic在集群所有Broker中的Queue数量相同
Broker模式：创建的Topic指定存在哪些Broker中，并进行Queue数量设置
读写队列
物理上讲读写队列是同一个队列，读写队列是逻辑上进行区分，一般读写队列数量是相同的。
读写队列如设置不同数量，会存在消息不被消费或消费不到的问题，之所以如此设计，是为了方便Topic的缩容。
例如16个Queue的Topic如何缩容为8个Queue的Topic，如果读写队列同时减少为8，此时剩余的8个Queue里的消息将不被消费，如果先将写队列改为8，消费队列继续为16，等到剩下的8个队列都消费完了，再将消费队列改为8，这样就不会丢失消息。
perm
2表示只写，4表示只读，6表示读写
Q：使用RocketMQ过程中遇到过什么问题？又是怎么解决的？
A：
Consumer不消费消息问题
解决方案：Consumer数量应该小于等于订阅Topic的Queue数量，如果超出Queue数量，多出的Consumer将不能消费消息
622
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
