RocketMQ 面试题
?
以下面试题，基于网络整理，和自己编辑。具体参考的文章，会在文末给出所有的链接。如果胖友有自己的疑问，欢迎在星球提问，我们一起整理吊吊的 RocketMQ 的大保健。而题目的难度，尽量按照从容易到困难的顺序，逐步下去。
友情提示：在开始阅读之前，胖友至少对 《RocketMQ —— 角色与术语详解》 有简单的了解。另外，这个面试题是建立在胖友看过 《精尽【消息队列 】面试题》 。
RocketMQ 是什么？
RocketMQ 是阿里巴巴在 2012 年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于 2017 年9 月 25 日成为 Apache 的顶级项目。作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件，以其高性能、低延时和高可靠等特性近年来已经也被越来越多的国内企业使用。
如下是 RocketMQ 产生的原因：
淘宝内部的交易系统使用了淘宝自主研发的 Notify 消息中间件，使用 MySQL 作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011 年初，Linkin开源了 Kafka 这个优秀的消息中间件，淘宝中间件团队在对 Kafka 做过充分 Review 之后， Kafka 无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用 Java 语言编写了 RocketMQ ，定位于非日志的可靠消息传输（日志场景也OK），目前 RocketMQ 在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理， binglog 分发等场景。
RocketMQ 由哪些角色组成？
如下图所示：
生产者（Producer）：负责产生消息，生产者向消息服务器发送由业务应用程序系统生成的消息。消费者（Consumer）：负责消费消息，消费者从消息服务器拉取信息并将其输入用户应用程序。
消息服务器（Broker）：是消息存储中心，主要作用是接收来自 Producer 的消息并存储， Consumer 从这里取得消息。
名称服务器（NameServer）：用来保存 Broker 相关 Topic 等元信息并给 Producer ，提供 Consumer 查找Broker 信息。
请描述下 RocketMQ 的整体流程？
1、启动 Namesrv，Namesrv起 来后监听端口，等待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心。
2、Broker 启动，跟所有的 Namesrv 保持长连接，定时发送心跳包。
心跳包中，包含当前 Broker 信息(IP+端口等)以及存储所有 Topic 信息。 注册成功后，Namesrv 集群中就有 Topic 跟 Broker 的映射关系。
3、收发消息前，先创建 Topic 。创建 Topic 时，需要指定该 Topic 要存储在 哪些 Broker上。也可以在发送消息时自动创建Topic。4、Producer 发送消息。
启动时，先跟 Namesrv 集群中的其中一台建立长连接，并从Namesrv 中获取当前发送的 Topic 存在哪些 Broker 上，然后跟对应的 Broker 建立长连接，直接向 Broker 发消息。5、Consumer 消费消息。
Consumer 跟 Producer 类似。跟其中一台 Namesrv 建立长连接，获取当前订阅 Topic 存在哪些Broker 上，然后直接跟 Broker 建立连接通道，开始消费消息。
：下面，我们先逐步对 RocketMQ 每个角色进行介绍。对不了解 RocketMQ 的胖友来说，可能概念会有点多。淡定~
请说说你对 Namesrv 的了解？
1、 Namesrv 用于存储 Topic、Broker 关系信息，功能简单，稳定性高。
多个 Namesrv 之间相互没有通信，单台 Namesrv 宕机不影响其它 Namesrv 与集群。
多个 Namesrv 之间的信息共享，通过 Broker 主动向多个 Namesrv 都发起心跳。正如上文所说，Broker 需要跟所有 Namesrv 连接。
即使整个 Namesrv 集群宕机，已经正常工作的 Producer、Consumer、Broker 仍然能正常工作，但新起的 Producer、Consumer、Broker 就无法工作。
这点和 Dubbo 有些不同，不会缓存 Topic 等元信息到本地文件。
2、 Namesrv 压力不会太大，平时主要开销是在维持心跳和提供 Topic-Broker 的关系数据。但有一点需要注意，Broker 向 Namesr 发心跳时，会带上当前自己所负责的所有 Topic 信息，如果 Topic 个数太多（万级别），会导致一次心跳中，就 Topic 的数据就几十 M，网络情况差的话，网络传输失败，心跳失败，导致Namesrv 误认为 Broker 心跳失败。
当然，一般公司，很难达到过万级的 Topic ，因为一方面体量达不到，另一方面 RocketMQ 提供了 Tag属性。
另外，内网环境网络相对是比较稳定的，传输几十 M 问题不大。同时，如果真的要优化，Broker 可以把心跳包做压缩，再发送给 Namesrv 。不过，这样也会带来 CPU 的占用率的提升。
如何配置 Namesrv 地址到生产者和消费者？
将 Namesrv 地址列表提供给客户端( 生产者和消费者 )，有四种方法：
编程方式，就像 producer.setNamesrvAddr(\ 。Java 启动参数设置，使用 rocketmq.namesrv.addr 。环境变量，使用 NAMESRV_ADDR 。HTTP 端点，例如说：http://namesrv.rocketmq.xxx.com 地址，通过 DNS 解析获得 Namesrv 真正的地址。
请说说你对 Broker 的了解？
1、 高并发读写服务。Broker的高并发读写主要是依靠以下两点：
消息顺序写，所有 Topic 数据同时只会写一个文件，一个文件满1G ，再写新文件，真正的顺序写盘，使得发消息 TPS 大幅提高。
消息随机读，RocketMQ 尽可能让读命中系统 Pagecache ，因为操作系统访问 Pagecache 时，即使只访问 1K 的消息，系统也会提前预读出更多的数据，在下次读时就可能命中 Pagecache ，减少 IO 操作。
2、 负载均衡与动态伸缩。
负载均衡：Broker 上存 Topic 信息，Topic 由多个队列组成，队列会平均分散在多个 Broker 上，而Producer 的发送机制保证消息尽量平均分布到所有队列中，最终效果就是所有消息都平均落在每个Broker 上。
动态伸缩能力（非顺序消息）：Broker 的伸缩性体现在两个维度：Topic、Broker。
Topic 维度：假如一个 Topic 的消息量特别大，但集群水位压力还是很低，就可以扩大该 Topic 的队列数， Topic 的队列数跟发送、消费速度成正比。
Topic 的队列数一旦扩大，就无法很方便的缩小。因为，生产者和消费者都是基于相同的队列数来处理。 如果真的想要缩小，只能新建一个 Topic ，然后使用它。 不过，Topic 的队列数，也不存在什么影响的，淡定。
Broker 维度：如果集群水位很高了，需要扩容，直接加机器部署 Broker 就可以。Broker 启动后向 Namesrv 注册，Producer、Consumer 通过 Namesrv 发现新Broker，立即跟该 Broker 直连，收发消息。
新增的 Broker 想要下线，想要下线也比较麻烦，暂时没特别好的方案。大体的前提是，消费者消费完该 Broker 的消息，生产者不往这个 Broker 发送消息。
3、 高可用 & 高可靠。
高可用：集群部署时一般都为主备，备机实时从主机同步消息，如果其中一个主机宕机，备机提供消费服务，但不提供写服务。
高可靠：所有发往 Broker 的消息，有同步刷盘和异步刷盘机制。
同步刷盘时，消息写入物理文件才会返回成功。
异步刷盘时，只有机器宕机，才会产生消息丢失，Broker 挂掉可能会发生，但是机器宕机崩溃是很少发生的，除非突然断电。
如果 Broker 挂掉，未同步到硬盘的消息，还在 Pagecache 中呆着。
4、 Broker 与 Namesrv 的心跳机制。
单个 Broker 跟所有 Namesrv 保持心跳请求，心跳间隔为30秒，心跳请求中包括当前 Broker 所有的Topic 信息。
Namesrv 会反查 Broker 的心跳信息，如果某个 Broker 在 2 分钟之内都没有心跳，则认为该 Broker 下线，调整 Topic 跟 Broker 的对应关系。但此时 Namesrv 不会主动通知Producer、Consumer 有Broker 宕机。也就说，只能等 Producer、Consumer 下次定时拉取 Topic 信息的时候，才会发现有Broker 宕机。
从上面的描述中，我们也已经发现 Broker 是 RocketMQ 中最最最复杂的角色，主要包括如下五个模块：Broker 组件图远程处理模块：是 Broker 的入口，处理来自客户的请求。
Client Manager ：管理客户端（生产者/消费者），并维护消费者的主题订阅。Store Service ：提供简单的 API 来存储或查询物理磁盘中的消息。HA 服务：提供主节点和从节点之间的数据同步功能。
索引服务：通过指定键为消息建立索引，并提供快速的消息查询。
Broker 如何实现消息的存储？
关于 Broker 如何实现消息的存储，这是一个很大的话题，所以建议直接看如下的资料，保持耐心。
《读懂这篇文章，你的阿里技术面就可以过关了 | Apache RocketMQ》的如下部分：
「三、RocketMQ的存储模型」《RocketMQ 原理简介》的如下部分：
「6.3 数据存储结构」「6.4 存储目录结构」「7.1 单机支持 1 万以上持久化队列」「7.2 刷盘策略」癫狂侠
《消息中间件 —— RocketMQ消息存储（一）》《消息中间件 —— RocketMQ消息存储（二）》
请说说你对 Producer 的了解？
RocketMQ 面试题 - 图文
