引言

RocketMQ 是阿里巴巴开源的分布式消息系统，依托高可用分布式集群架构，可提供低延时、高可靠的消息发布与订阅能力。它既是统一的消息引擎，也是轻量级数据处理平台。RocketMQ 脱胎于阿里早期五彩石项目，经过多年迭代优化，如今已成为业界处理大规模消息流转的主流中间件。

前世今生

• 起源：2001 年，阿里巴巴五彩石项目中的 Notify 组件，承担交易核心消息的流转工作。

• 早期使用：2010 年，B2B 业务大规模接入 ActiveMQ 作为消息内核。

• MetaQ 的诞生：2011 年，为满足顺序消息、海量消息堆积的业务需求，MetaQ 1.0 正式推出。

• RocketMQ 的发展

  • 2012 年：基于 MetaQ 3.0 重构开发，具备高吞吐量、低延迟、海量消息处理能力。

  • 2015 年：新增事务消息、SQL 过滤器、消息追溯、调度消息等高级功能。

  • 2016 年：上线全托管服务，项目正式捐赠给 Apache 基金会，进入孵化器阶段。

  • 2017 年：顺利晋升为 Apache 基金会顶级项目（TLP）。

  • 2018 年：获评中国最受欢迎开源软件奖项。

基本概念

消息模型

• Producer：消息生产者，负责生成消息并发送至 Broker 服务端。

• Broker：消息中转服务，核心职责为存储、转发消息，是整个架构的核心节点。

• Consumer：消息消费者，主动拉取或被动接收 Broker 中的消息并完成业务处理。

• Message Queue：消息物理存储单元，一个 Topic 会拆分出多个队列，实现负载均衡与并发处理。

• ConsumerGroup：多个 Consumer 实例组成的集合，主要用于实现消费端负载均衡与故障容错。

消息生产者

发送方式分为四类：同步发送、异步发送、顺序发送、单向发送。
同步发送与异步发送会等待 Broker 返回应答确认；单向发送仅投递消息，无需等待服务端回执，适用于对可靠性要求较低的场景。

消息消费者

消费形式分为拉取式消费（Pull Consumer）、推动式消费（Push Consumer）。

• 拉取式消费：客户端主动调用接口从 Broker 拉取消息，消费逻辑、轮询频率由客户端自主控制。

• 推动式消费：Broker 检测到新消息后主动推送至客户端，消息实时性更强，也是日常开发中主流使用方式。

主题

Topic 是同一类业务消息的集合，也是 RocketMQ 消息订阅、路由划分的基本单位，业务中通常按模块、场景划分不同 Topic。

代理服务器

Broker Server 是核心服务节点，负责接收生产者投递的消息、持久化存储数据，同时响应消费者的拉取请求，并维护消息路由、消费偏移量等元数据。Broker 支持集群部署，分为主节点（Master）与从节点（Slave），保障服务高可用。

名字服务

Name Server 作为独立路由服务，统一管理集群路由信息。生产者与消费者会先连接 Name Server，查询指定 Topic 对应的 Broker IP 地址列表，再建立通信。Name Server 可集群部署，无状态设计，部署简单且容错性高。

生产者组

Producer Group 是逻辑上归为一类的生产者集合，组内实例发送同一类消息、业务逻辑保持一致。当使用事务消息时，生产者组还具备故障重试、消息回查的能力。

消费者组

Consumer Group 是逻辑归类的消费者集合，组内实例消费同一类消息、业务处理逻辑统一。同一个消费者组支持两种消费模式：

• 集群消费：组内多个 Consumer 实例分摊消息，一条消息只会被组内某一个实例消费，实现消费端负载均衡。

• 广播消费：组内所有 Consumer 实例都会接收并处理全量消息，适用于配置同步、状态推送等全员通知场景。

消息模式

结合消费者组，分为集群消费、广播消费，两种模式相互独立，根据业务场景选择使用。

顺序消息

针对有序业务场景，RocketMQ 提供两类顺序消息：

• 普通顺序消息：单个消息队列内的消息保证有序，不同队列之间不做顺序约束，可实现部分并发消费。

• 严格顺序消息：全局所有消息严格按照发送顺序被消费，整个 Topic 仅使用单个队列，并发能力相对较弱。

消息

Message 是消息传输的最小载体，每一条消息必须归属一个 Topic。每条消息拥有全局唯一的 Message ID，同时支持自定义业务 Key，可根据 Key 快速检索定位消息。

标签

Tag 是 Topic 下的消息子分类标识，用于区分同一个主题内不同类型的业务消息。消费者可基于 Tag 做消息过滤，实现同一 Topic 下区分不同消费逻辑。

消费端实现类

• DefaultMQPushConsumer：推送式消费实现类，Broker 主动推送消息至客户端，开箱即用，实时性好，为业务常用实现。

• DefaultMQPullConsumer：拉取式消费实现类，客户端主动轮询拉取消息，灵活性更高，自主掌控消费节奏，多用于特殊定制化场景。

高级特性

• 事务消息：解决本地事务与消息发送的一致性问题，保证业务操作和消息投递要么同时成功，要么同时回滚。

• 消息过滤：除基础 Tag 过滤外，支持通过 SQL 表达式进行复杂条件过滤，精准筛选目标消息，减少无效消息消费，提升整体效率。

• 消息追溯：支持根据时间、偏移量回溯历史消息，方便线上问题排查、数据补漏等场景。

• 调度消息：包含延迟消息与定时消息，可指定消息延后消费的时间或固定消费时刻，适配延时任务、定时任务等业务。

• 多站点高可用：支持多数据中心集群部署、消息跨区域同步，依靠集群副本、故障转移机制，保障极端场景下消息服务不中断。