RocketMQ 5，学习 linux 系统管理

编辑 | Tina

RocketMQ 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

顶级项目。

2017 年 2 月 20 日，RocketMQ 正式发布 4.0 版本。差不多 5 年之后，我们终于等来了 5.0 版本。

RocketMQ 5.0 专注于消息基础架构的云原生化演进，聚焦在消息领域的后处理场景，支持消息的流式处理和轻计算，帮助用户实现消息的就近计算和分析，并将全面拥抱 Serverless 和 EDA。

据阿里云消息产品线负责人林清山介绍，这次发布的版本，因为进行了架构重塑，新增或者修改了超过 60% 的代码，但是对 4.0 的所有功能以及整体架构进行了无缝兼容，且没有引入任何外部依赖，保持了 RocketMQ 极简架构、极低运维成本的特点。

1 去 ZooKeeper、存储计算分离：消息系统走向大一统？

RocketMQ 从设计之初就立足于在线交易链路，因此主要应用在大型在线系统的异步化处理。

历经十年发展，目前的大规模落地场景有：电商物流的交易系统、在线教育课程系统、大型游戏信令系统、以及银行交易系统，这些都大量使用了 RocketMQ 来做异步解耦和削峰填谷；同时在非在线业务的场景里，大量车联网、电商网站基于 RocketMQ 实现 IoT 边缘数据以及 C 端用户行为数据采集传输和集成。

开源至今，RocketMQ 的核心架构大约经历了四个重要的演进阶段：

第一代 RocketMQ 其实是采用了推模式，数据存储采用关系型数据库。在这种模式下消息具有很低的延迟特性，并且很容易支持分布式事务。在阿里淘宝这种高频交易场景中，具有非常广泛的应用。

第二代 RocketMQ 在服务于交易场景基础上开始探索自研存储引擎，这个版本采用了拉模式和自研的专有消息存储，在日志处理方面能够媲美 Kafka 的吞吐性能。

在前两代初步打磨了自研的存储引擎后， RocketMQ 3.0 的重构前瞻性地去除了 ZooKeeper?等组件的外部依赖，并支持了单机海量 Topic。而刚好在前不久，我们也报道过消息系统 Kafka 去除 ZooKeeper 依赖。

第四代 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 的概念来描述各个组件的职责。

• 全新轻量级 SDK，基于 gRPC 协议重新打造的一批多语言客户端，采取 gRPC 的主要考虑其在云原生时代的标准性、兼容性以及多语言传输层代码的生成能力。

• 导航服务（Navigation Server），这是个可选组件，通过 LB Group 暴露给客户端。客户端通过导航服务获取数据面的接入点信息（Endpoint），随后通过计算集群 CBroker 的 LB Group 进行消息的收发。通过 EDS 暴露 CBroker 的接入点信息的方式比通过 DNS 解析的负载均衡更加智能且可以更精细实现流量控制等逻辑。

• NameServer，RocketMQ 原有的核心组件，主要提供 SBroker 的集群发现（CDS），存储单元 Topic 的路由发现（RDS）等，为运维控制台组件、用户控制台组件、计算集群 CBroker 提供 xDS 服务。

• Compute-Broker（CBroker），重构版本后抽象出的无状态计算集群，作为数据流量的入口，提供鉴权与签名、上层计量统计、资源管理、客户端连接管理、消费者管控治理、客户端 RPC 处理、消息编解码处理、流量控制、多协议支持等。

• Storage-Broker（SBroker），重构后下沉的存储节点，专注于提供极具竞争力的高性能、低延迟的存储服务。

• LB Group，根据用户的需求提供多样化的负载均衡接入能力。

但存储计算一体化在很多场景下依然是最佳选择，因此，RocketMQ 在 5.0 为存储计算分离架构提供了灵活的选择：可分可合。如上图所示，左边是一个分离部署的形态，右边是合并部署的形态，合并部署时计算节点可以作为存储节点的 SideCar，采用网格的思想部署，也可以将计算和存储揉进同一个进程部署。

在云原生架构设计中，我们常听到要让基础设施完全解耦，这意味着可以让用户在任意的基础设施上部署交付。现在公有云、专有云、混合云、多云下的基础设施均不相同，以存储为例，可能有云盘，也有可能是本地盘；以网络为例，可能是经典网络，也有可能是多 VPC 网络...... 这样的环境要求对于基础服务的云原生架构设计是一个非常大的挑战。所以，RocketMQ 5.0 架构的重塑，很重要的改变是在不同的应用场景下都能提供极致的弹性和统一的架构，“我们称之为场景多元化”，RocketMQ 创始人誓嘉表示。

举例来说，使用 RocketMQ 可以自由选择私有化多副本部署方式或者利用公共云云盘的方式，后者既能提升性能又能降低硬件成本及运维成本，也带来了更高的弹性能力。在对一致性要求非常高且需要主从自动切换能力的场景，Raft 又可以保证数据可靠性、业务可用性。同时，RocketMQ 还支持多元索引，可以基于一份原始数据构建多份索引来满足不同的业务场景，包括消费索引、查询索引、批索引、百万队列索引等，以便在同一套架构支撑着不同行业的各种差异化诉求。

2 融合“消息、事件、流”于一体