消息中间件入门认知：从0开始认识消息队列与RocketMQ

系列第一篇：入门认知篇

你好，欢迎来到 RocketMQ 学习之旅的第一站。本篇内容主要是了解内容，熟悉即可，干货少少，泛泛而读即可

在正式开始之前，我想先问你一个问题：你有没有遇到过这样的场景——双十一凌晨，成千上万的用户同时下单，你的系统扛不住这么高的并发，直接崩溃了？或者，你的订单系统和库存系统耦合得太紧，库存系统一挂，整个下单流程都跟着瘫痪？

如果你的答案是“遇到过”或者“听说过”，那么恭喜你，你已经摸到了消息队列存在的意义。这篇文章，我们就从最基础的概念开始，一步步走进消息队列的世界，再认识一下今天的主角——RocketMQ。

一、消息中间件基础概念

什么是消息队列（MQ）？

用最通俗的话说，消息队列（Message Queue，MQ）就像是一个“信箱” 。

假设你是一个快递员（生产者），你把包裹放到小区的快递柜（消息队列）里，收件人（消费者）有空的时候自己去取。你们俩不需要见面，不需要约定时间，快递柜帮你们完成了“中转”。

在计算机世界里，消息队列就是这样一个存放消息的容器。一个应用（生产者）把消息发到队列里，另一个应用（消费者）从队列里取出来处理。生产者和消费者不需要同时在线，也不需要知道对方的存在，一切通过消息队列来沟通。

消息队列的核心作用：解耦、异步、削峰

消息队列之所以在分布式系统中如此重要，主要因为它解决了三个核心问题：

1. 解耦（Decoupling）

没有消息队列的时候，系统 A 调用系统 B、C、D，系统之间紧紧“绑”在一起——B 挂了，A 受影响；D 改了个接口，A 也要跟着改。这种强耦合就像家里所有电器共用一个开关，关一个全灭。

有了消息队列，A 只管把消息往队列里一扔，谁要消费谁自己来取。系统之间不再直接依赖，各自独立演进。A 不用关心下游有几个系统、它们是否在线——松耦合让系统更加灵活、易于维护。

2. 异步（Asynchronous）

同步调用就像你去银行办业务，柜员办完一项才能办下一项，你只能干等着。异步则像你点了个外卖，下单后该干嘛干嘛，外卖到了自然会通知你。

在系统里，如果用户下单后要等库存扣减、积分更新、短信通知等一系列操作全部完成才能收到“下单成功”的响应，用户体验会非常差。引入消息队列后，订单系统把消息发到队列就立刻返回“下单成功”，后续操作异步处理，响应时间从秒级降到毫秒级。

3. 削峰（Peak Cutting）

这是消息队列最经典的应用场景。双十一零点，流量像海啸一样涌来——几万甚至几十万笔订单同时生成。如果所有请求直接打到数据库，数据库瞬间就被冲垮了。

消息队列就像一个“水库”，把瞬间的洪峰先接住，然后再以平稳的速度“放水”给下游系统处理。这就是削峰填谷——把流量高峰“削”掉，填到低谷时段去处理，保证系统不会因为突发流量而崩溃。

消息队列的两种模型：点对点与发布订阅

消息队列主要分为两种使用模型：

点对点模型（Point-to-Point）

生产者把消息发到一个队列（Queue） 里，一条消息只能被一个消费者消费。就像快递柜里的一个包裹，只能被指定的收件人取走。

如果有多个消费者监听同一个队列，消息会在它们之间负载均衡——比如轮着来，你一条我一条。

适用场景：任务分发、订单处理、邮件发送等需要“一消息一处理”的场景。

发布订阅模型（Publish/Subscribe）

生产者把消息发到一个主题（Topic） 里，所有订阅了这个主题的消费者都能收到这条消息的副本。就像公众号发文——一篇推文发出去，所有关注的人都能看到。

这是一种一对多的广播模式，生产者和消费者互相不知道对方的存在。

适用场景：事件通知（用户注册后通知多个下游系统）、实时数据分发、日志聚合等。

💡 小贴士：RocketMQ 同时支持这两种模型。在实际使用中，点对点对应的是“集群消费”模式，发布订阅对应的是“广播消费”模式。

消息的消费模式：推（Push）与拉（Pull）

消费者怎么从消息队列里拿消息？主要有两种方式：

拉模式（Pull）

消费者主动去队列里“拉”消息——就像你去快递柜自己取件。优点是消费者可以自己控制拉取的频率和批量大小，灵活性高。缺点是如果队列里没消息，消费者频繁去拉就会浪费资源。

推模式（Push）

消息队列主动把消息“推”给消费者——就像外卖小哥把餐送到你手上。优点是实时性好，消息一来就能处理。缺点是如果消费者处理不过来，推送太多会把消费者压垮。

💡 小贴士：RocketMQ 两种模式都支持，但底层实现上其实都是基于拉模式——Push 模式也是消费者不断拉取，只是封装成了“推送”的感觉。

同步、异步、单向发送的区别与适用场景

在消息发送这个环节，RocketMQ 提供了三种发送方式，它们的区别在于对发送结果的关注程度不同：

方式	特点	适用场景
同步发送	发消息后等待 Broker 返回确认，收到确认才继续	关键业务，如交易消息、订单消息，丢不起
异步发送	发消息后不阻塞，通过回调函数处理结果	对延迟敏感但需要知道结果的场景
单向发送	只管发，不管结果，不等待任何响应	日志上报、监控数据等丢了也无所谓的场景

简单说：同步要结果，异步等回调，单向爱咋咋地。

消息中间件的发展演进历程

消息中间件不是一天建成的。它的演进大致经历了三个阶段：

第一阶段：诞生（2000年代初）

早期的消息中间件主要是 IBM MQ、ActiveMQ 等，解决的是企业应用集成（EAI）中的系统间通信问题。那时候的 MQ 功能相对单一，主要做点对点的消息传递。

第二阶段：互联网爆发（2010年代）

随着互联网业务的快速发展，传统的消息中间件已经扛不住海量数据和高并发了。Kafka 在 2011 年由 LinkedIn 开源，主打高吞吐，专门为日志收集和数据管道而生。RocketMQ 也在 2012 年诞生于阿里巴巴，专为电商场景设计。

第三阶段：云原生与AI时代（2020年代至今）

消息中间件开始走向云原生，存算分离、弹性伸缩成为标配。同时，AI 场景的爆发也给消息中间件带来了新的挑战和机遇——RocketMQ 5.5 就开始支持 LiteTopic 等 AI 原生特性。

主流消息队列对比：RocketMQ vs Kafka vs RabbitMQ

目前市面上最主流的三个消息队列，各有各的擅长领域：

对比维度	RabbitMQ	Kafka	RocketMQ
开发语言	Erlang	Scala/Java	Java
吞吐量	万级 QPS	百万级 QPS	十万级 QPS
消息顺序	不支持	分区级有序	分区级严格有序
事务消息	支持（XA）	不支持	原生支持
延迟消息	支持	不支持	支持
消息过滤	有限	仅 Topic	SQL+Tag 过滤
适用场景	中小规模、灵活路由	大数据、日志、流处理	金融级业务、核心交易链路

简单总结选型建议：

• RabbitMQ：轻量灵活，适合中小型项目和对功能丰富度要求高的场景
• Kafka：吞吐量之王，适合日志收集、大数据分析、实时流处理
• RocketMQ：金融级可靠，适合核心交易链路、对消息顺序和事务有严格要求的场景

二、RocketMQ 概述与历史

了解了消息队列的基础知识，现在我们正式进入 RocketMQ 的世界。

RocketMQ 的诞生背景：阿里的分布式消息需求演进

RocketMQ 的故事，要从阿里巴巴的“五彩石”项目说起。

2007年：Notify 诞生

淘宝电商系统从单体架构向分布式架构演进，实施了“五彩石”项目。在这个过程中，交易系统需要一种可靠的消息流转机制——Notify 应运而生，这就是 RocketMQ 最早的雏形。

早期的 Notify 有个特点：基于关系型数据库存储消息，采用推模式。这在当时够用，但随着业务量暴涨，瓶颈很快就出现了。

2010年：ActiveMQ 的尝试

到了 2010 年，阿里巴巴 B2B 业务开始大规模使用 ActiveMQ 作为消息内核。但 ActiveMQ 也有它的天花板——无法满足阿里对顺序消息和海量消息堆积能力的需求。

阿里的业务体量太大了，市面上根本找不到现成的消息中间件能满足需求。那就自己造吧。

2011年：MetaQ 诞生

2011 年，阿里自研了 MetaQ（Metamorphosis） ，以文件系统作为存储，解决了 Notify 基于关系型数据库存储的隐患。MetaQ 1.0 的诞生，标志着阿里消息中间件进入了新阶段。

2012年：RocketMQ 正式诞生

经过不断的探索和迭代，在重写 MetaQ 2.0 之后，第一代 RocketMQ 正式诞生，命名为 RocketMQ 3.0。同年，阿里巴巴正式开源了 RocketMQ 的第一个版本。

下图为 RocketMQ 的演进脉络，可以帮你更直观地理解这段历史：

timeline title RocketMQ 演进历程 2007 : Notify 诞生 : 基于关系型数据库 : 推模式 2010 : 尝试 ActiveMQ : 无法满足海量堆积需求 2011 : MetaQ 1.0 诞生 : 基于文件系统存储 2012 : RocketMQ 3.0 发布 : 正式开源 2013 : 开源社区活跃 2015 : 事务消息等重磅功能 : 取代 Notify 2016 : 捐赠 Apache 基金会 2017 : 成为 Apache 顶级项目 2021 : RocketMQ 5.0 发布 : 云原生消息/事件/流融合平台 2026 : RocketMQ 5.5 发布 : AI 原生能力（LiteTopic）

RocketMQ 的发展历程与版本演进（4.x → 5.x）

4.x 时代：金融级业务消息的首选

RocketMQ 进入 Apache 基金会后，4.x 版本迎来了快速发展。这个阶段，RocketMQ 在多副本能力、消息类型丰富度、消息治理等方面都有了巨大飞跃。

4.x 的核心定位是 “金融级可靠业务消息” 。它具备了事务消息、顺序消息、延迟消息等特性，被广泛应用于各大企业的核心交易链路。

5.x 时代：云原生消息/事件/流融合平台

RocketMQ 5.0 是一次重大的架构升级，被定义为 “云原生的消息、事件、流的超融合平台” 。

5.x 的核心变化包括：

• 存算分离架构：Proxy 层无状态，支持弹性伸缩
• gRPC 多语言 SDK：支持 Java、Go、C++、Rust、Python、Node.js 等
• 多协议支持：原生支持 gRPC、MQTT、AMQP、HTTP/REST
• Kubernetes 原生：提供 Helm Charts 和 Operator

从 4.x 到 5.x，RocketMQ 从一个“消息队列”演进成了一个 “统一消息平台” 。

RocketMQ 成为 Apache 顶级项目的历程

RocketMQ 的开源之路，是中国开源史上的一个重要里程碑。

2016年11月：阿里巴巴将 RocketMQ 捐赠给 Apache 软件基金会，正式成为孵化项目。

2017年9月：仅用了 不到10个月，RocketMQ 就从 Apache 社区正式毕业，成为 Apache 顶级项目（TLP）。

这不仅是速度上的奇迹——更值得一提的是，RocketMQ 是国内首个非 Hadoop 生态的 Apache 顶级项目。

在孵化期间，社区完成了编码规范、分支模型、持续交付、发布规约等方面的全面规范化。从中国本土的开源项目，到登上全球顶级开源舞台，RocketMQ 的成功离不开创始团队和无数开发者的持续贡献。

RocketMQ 的核心特性一览

RocketMQ 之所以能成为众多企业核心交易链路的首选，靠的是下面这些硬核特性：

1. 金融级可靠性

• 基于 DLedger 的 Raft 一致性协议，保证消息零丢失
• 支持自动选主和多副本同步复制

2. 丰富的事务消息

• 原生两阶段提交，保证分布式事务的最终一致性

3. 严格顺序消息

• 分区级 FIFO 顺序保证，完美支撑订单创建、支付扣款等场景

4. 延迟/定时消息

• 支持任意精度的定时投递，用于订单超时取消、重试调度等

5. 强大的消息过滤

• 支持 SQL92 和 Tag 两种过滤方式

6. 海量消息堆积

• 单机支持上亿级消息堆积

7. 消息轨迹

• 内置全链路消息追踪能力

8. 高可用架构

• NameServer 无状态设计，Broker 主从同步

RocketMQ 与双十一万亿级流量的故事

说到 RocketMQ，就绕不开 双十一。

每年的双十一零点，都有数亿用户同时下单，瞬间产生千万级的并发请求。RocketMQ 就是扛住这波流量洪峰的核心基础设施之一。

RocketMQ 是怎么做到的？核心靠的是 “六大武器” ：

• 异步解耦：把复杂的下单链路拆成多个异步步骤，缩短用户等待时间
• 削峰填谷：用消息队列缓冲海量请求，保护下游系统不被冲垮
• 分布式事务：保证订单、库存、积分等多系统数据最终一致

阿里双十一当天，RocketMQ 要支撑 数万亿条消息的流转。这不是实验室里的理论数据，而是实打实的生产环境验证。

更厉害的是，经历了阿里内部万亿级流量的考验后，RocketMQ 在云上还要服务成千上万不同规模、不同流量模型的企业客户。这种“从内部验证到外部服务”的历练，让 RocketMQ 的稳定性达到了行业顶尖水平。

RocketMQ 的应用场景与适用范围

基于以上特性，RocketMQ 主要适用于以下场景：

电商交易：订单创建、支付回调、库存扣减、物流通知等核心交易链路

金融场景：转账、对账、风控等对数据一致性要求极高的业务

IoT 场景：海量终端设备的数据采集和消息过滤

AI Agent 通信：多智能体系统间的异步通信和事件驱动编排

RocketMQ 5.x 新特性概览

最后，我们来快速浏览一下 RocketMQ 5.x 有哪些值得关注的新特性：

AI 原生能力（5.5 版本）

2026年4月发布的 5.5.0 版本，引入了面向 AI 场景的战略升级：

• LiteTopic：专为 AI Agent 会话管理设计，以极低资源开销支持百万级轻量通道
• Lite Mode 轻量订阅：面向 AI 场景的轻量级订阅模型，资源消耗更低
• 智能计算调度：解决 AI 工作流中的长会话断连、资源浪费等问题

云原生架构

• 存算分离，弹性伸缩
• Kubernetes 原生支持
• gRPC 多语言 SDK

功能增强

• 消息类型强制校验，每个 Topic 只允许一种消息类型
• 流量控制支持 client、user、Topic 多级别
• 默认开启消息轨迹

💡 小贴士：5.x 的 gRPC SDK 和 4.x 的 Remoting SDK 可以共存，但 gRPC SDK 仅支持 5.x 版本的服务端。如果你是新项目，建议直接上手 5.x。

小结

这篇文章我们完成了两件事：

第一，搭建了消息队列的认知框架——知道了什么是 MQ、它的三大核心作用（解耦、异步、削峰）、两种模型（点对点、发布订阅）、两种消费模式（推、拉），以及 RocketMQ 在主流 MQ 中的定位。

第二，了解了 RocketMQ 的前世今生——从 2007 年的 Notify 到 2012 年的 RocketMQ，从 Apache 孵化到成为顶级项目，从支撑双十一万亿流量到拥抱云原生和 AI。

下一篇文章，我们将正式进入 RocketMQ 的架构与核心概念篇，带你拆解 NameServer、Broker、Producer、Consumer 这四大组件，搞懂 Topic、Queue、Tag 这些核心概念。敬请期待！

---