RocketMQ 5，java面试选择题及答案

第四代 RocketMQ 在高可靠低延迟方面重点优化，构建了全新的低延迟存储引擎、新增了 Raft 多副本存储能力、提供了丰富的消息特性。

RocketMQ 架构演进的思考

目前社区开发者对 RocketMQ 的诉求来自于三个方面：首先，RocketMQ 如何更方便地与云原生生态整合是开发者最为关心的问题；其次，在流计算场景里，社区对 RocketMQ 的吞吐能力提出了更高的要求，企业客户也一直希望就近处理流转在 RocketMQ 系统中的如支付、交易等高价值的业务数据；还有一类则是在企业集成过程中，希望 RocketMQ 能提供更多 connector 帮助用户构建企业数据流转中心。

伴随如今企业全面上云以及云原生的兴起，新一代基础架构必须朝着云原生化演进，RocketMQ 在 5.0 里面提供了可分可合的存储计算分离架构以顺应这一趋势。

通过可分可合的存储计算分离架构，用户可以同一进程启动存储和计算的功能，也可以将两者分开部署。分开部署后的计算节点可以做到“无状态”，一个接入点可代理所有流量，在云上结合新硬件内核旁路技术，可以降低分离部署带来的性能及延迟问题。而选择“存储计算一体化”架构，同时也能契合“就近计算”的趋势，也就是在最靠近数据的地方做计算。

林清山表示新版本在存储计算分离的架构选择上非常慎重：“首先我们认为在云上多租、多 VPC、多种接入方式的场景下是非常有必要的，存储计算分离后能够避免后端存储服务直接暴露给客户端，便于实现流量的管控、隔离、调度、权限管理。”

但是有利必有弊，除了带来延迟的上升、成本的增加以外，存储计算分离也会给线上运维带来巨大挑战。在大多数场景下，用户更希望的还是存储计算一体化的架构，开箱即用、性能高、延迟低、运维轻松，尤其是在大数据场景下，能够极大降低机器及流量成本。其实这个问题本质上还是由消息产品的特性决定的，消息相比于数据库，计算逻辑相对简单，拆分后往往会沦为无计算场景可发挥、存储节点也得不到简化的状态，这个从 Kafka 的架构演进也可以得到印证。”

“存储计算分离只是适应了部分场景，架构的演进还是要回归到客户的真实场景。”

面向多场景的弹性架构

在 4.0 版本中，RocketMQ 主要由 NameServer、Broker、Producer 以及 Consumer 四部分构成。Producer 和 Consumer 由用户进行分布式部署。NameServer 以轻量级的方式提供服务发现和路由功能，每个 NameServer 存有全量的路由信息，提供对等的读写服务，支持快速扩缩容。Broker 负责消息存储，以 Topic 为纬度支持轻量级的队列，单机可以支撑上万队列规模。

在 5.0 版本中，对系统中的不同服务进行了解耦，比如 Nameserver 和 Broker，设计为以下架构：

图中借用了 Service Mesh 关于控制和数据面的划分思想以及 xDS 的概念来描述各个组件的职责。