1.前言

从初代开源消息队列崛起，到 PC 互联网、移动互联网爆发式发展，再到如今 IoT、云计算、云原生引领了新的技术趋势，消息中间件的发展已经走过了 30 多个年头。

目前，消息中间件在国内许多行业的关键应用中扮演着至关重要的角色。随着数字化转型的深入，客户在使用消息技术的过程中往往同时涉及交叉场景，比如同时进行物联网消息、微服务消息的处理，同时进行应用集成、数据集成、实时分析等，企业需要为此维护多套消息系统，付出更多的资源成本和学习成本。

在这样的背景下，2022 年，RocketMQ 5.0 正式发布，相对于 RocketMQ 4.0，架构走向云原生化，并且覆盖了更多的业务场景。想要掌握最新版本 RocketMQ 的应用，就需要进行更加体系化的深入了解。

基于此，阿里云消息产品线负责人，Apache RocketMQ PMC Member 林清山老师（花名：隆基），将为你深入剖析 RocketMQ 5.0 的核心原理，分享不同场景下的最佳实践。

2.背景

我们这一期的课程是 Apache RocketMQ 5.0 的通识课。为什么要讲这门课呢？在 2022 年，我们发布了RocketMQ 5.0 的正式版，相对于 4.0 来说，架构走向云原生化，并且覆盖更多的业务场景。而现在市面大部分的课程都是面向 RocketMQ 旧版本来讲解的。为了让大家能够对 RocketMQ 5.0 有更体系化的了解，更好的使用最新版本的 RocketMQ，于是我们开设了这门课程。

在这一期的课程中，首先我们会一起回顾 RocketMQ 的诞生背景和发展历程，如何面向云原生、IoT、实时数据的趋势演进到 5.0 的版本，然后再从整体技术架构上学习 RocketMQ 5.0 的云原生架构、一体化架构，最后再分别从业务场景切入，详细介绍 RocketMQ 5.0 在不同的业务场景提供的能力和关键技术原理，包括业务消息、流处理、物联网以及面向云时代的事件驱动场景。希望通过这门课，你能对 RocketMQ 有全新的了解。我们今天就从了解 Apache RocketMQ 开始。

软件如同生物，会随着环境的变化、技术趋势的变化不断进化，每个软件都有它自己的诞生背景和成长历程。通过今天这节课，我们会了解 RocketMQ 的诞生背景，理解为什么在当时已经有很多种流行消息队列的情况下，阿里还需要研发 RocketMQ 。同时，我们也会结合近几年的技术趋势发展，了解 RocketMQ 5.0 演进的驱动力有哪些，为什么 RocketMQ 5.0 会采用这样的技术实现，扩展这样的业务能力。

这节课我们分为三部分内容。首先我会带大家回顾一下整个消息队列的演进史，不同的时代背景下出现了哪些成功的消息队列。然后我们一起会回到 RocketMQ 的第一天，了解 RocketMQ 的诞生背景，以及优点。最后分析云时代的机遇和挑战，对 RocketMQ 5.0 的演进有更宏观的了解。

3. 消息队列演进史

操作系统、数据库、中间件是基础软件的三驾马车，而消息队列属于最经典的中间件之一，已经有 30 多年的历史。它的发展主要经历了以下几个阶段：

第一个阶段，2000 年之前。80 年代诞生了第一款消息队列是 The Information Bus，第一次提出发布订阅模式来解决软件之间的通信问题；到了 90 年代，则是国际商业软件巨头的时代，IBM、Oracle、Microsoft 纷纷推出了自己的 MQ，其中最具代表性的是 IBM MQ，价格昂贵，面向高端企业，主要是大型金融、电信等企业；这类商业 MQ 一般采用高端硬件，软硬件一体机交付，MQ 本身的软件架构是单机架构。

第二阶段，2000~2007 年。进入 00 年代后，初代开源消息队列崛起，诞生了 JMS、AMQP 两大标准，与之对应的两个实现分别为 ActiveMQ、RabbitMQ ，它们引领了初期的开源消息队列技术。开源极大的促进了消息队列的流行，降低了使用门槛，技术普惠化，逐渐成为了企业级架构的标配。相比于今天而言，这类 MQ 主要还是面向传统企业级应用，面向小流量场景，横向扩展能力比较弱。

第三阶段，2007~2017 年。PC 互联网、移动互联网爆发式发展。由于传统的消息队列无法承受亿级用户的访问流量和海量数据传输，诞生了互联网消息中间件，核心能力是全面采用分布式架构、具备很强的横向扩展能力，开源典型代表有 Kafka、RocketMQ ，闭源的还有淘宝 Notify 。Kafka 的诞生还将消息中间件从消息领域延伸到了流领域，从分布式应用的异步解耦场景延伸到大数据领域的流存储和流计算场景。

第四阶段，2014~至今。云计算、IoT、大数据引领了新的浪潮。

4. 互联网时代的 RocketMQ

4.1.互联网电商场景

接下来我们回到 RocketMQ，回到阿里的核心业务场景——电商，来看 RocketMQ 如何诞生，以及为业务创造哪些核心价值？

阿里的电商系统最初是个庞大的单体巨石应用，在研发效率、稳定性方面都无法满足淘宝、天猫飞速的发展。为了解决这个问题，2008 年淘宝和天猫发起一次最大规模的架构升级，启动了“五彩石”项目，把单体应用拆分成分布式应用，同时抽象淘宝、天猫的共同底座——业务中台，包括交易中心、商品中心、买家中心等。在业务中台之下，同时诞生了阿里中间件（初期三大件包括：消息、RPC、分布式数据层），RocketMQ 是其中之一。

虽然，在当时，业界已经存在不少商业或开源的消息队列，比如 IBM MQ、ActiveMQ、RabbitMQ，然而无一例外的是，这些消息队列都诞生于传统企业级应用的场景，无法承受互联网对于高并发、无限扩展的苛刻要求。以 RabbitMQ 举例，RabbitMQ 的队列流量和存储负载都是单机的，无法满足业务横向扩展的需求。当时另外一款具备无限横向扩展能力的消息队列是 Kafka，但是它主要用于日志类场景，稳定性方面不足，而且它偏向于简单的 log 型消息队列，无法满足电商对于复杂消息功能特性的诉求，比如消息过滤、延迟消息等。

另一方面，传统的消息队列无法解决电商业务对于分布式一致性的要求。通过消息队列实现应用异步解耦后，电商业务还需要保障不同上下游应用，对于订单状态要达成最终一致，否则会产生大量的脏数据造成业务错误。一个大规模的电商系统，既要高性能、又要一致性，传统的分布式事务技术束手无策。比如 IBM MQ，虽然可以使用 XA 事务来满足分布式一致性的功能诉求，但是 XA 带来的延迟和成本，对于海量的互联网流量难以承受。（参考链接：ActiveMQ XA）

为了解决电商业务对于消息队列的高性能、一致性、无限扩展等需求，自研消息队列成了当时唯一的出路。在这个大背景下，互联网消息队列 RocketMQ 应运而生。

4.2 RocketMQ 的解决之道

为了支持超大规模的复杂电商业务，RocketMQ 面向四个方面进行重点建设，形成四大优势能力。

支撑超大规模复杂业务的能力，具备丰富的消息特性

每一个大型互联网公司都会有主营业务（比如阿里是交易、蚂蚁是支付、饿了么是外卖），以主营业务为中心扩展业务能力，阿里电商就是围绕交易事件建设的电商操作系统，每笔交易事件都会触发不同的业务，不同细分业务会关注不同类型的交易事件，比如垂直市场只关注某个类目的交易事件、天猫超市只关注某个卖家的交易事件、购物车只关注下单成功的交易事件等，RocketMQ 的 SQL 订阅提供灵活的消息过滤能力，能够满足下游消费者按照不同的业务维度进行消息过滤的诉求。在大型互联网业务中，还会有各种定时事件触发场景，最典型的是交易超时关闭机制，阿里交易或者 12306 订票都有类似的机制。RocketMQ 的定时消息，能够很方便的满足这类诉求。

一致性

无论是阿里交易、还是蚂蚁支付，都天然对数据一致性有着极高的要求，RocketMQ 在一致性方面也打造了多个关键特性。最具代表性的是分布式事务消息，RocketMQ 是第一个实现这种特性的消息队列，这个特性能够保障交易的上下游对于订单状态达到最终一致。这个方案也成为异步消息一致性方案的事实标准，被多个互联网公司所采纳，甚至也有公司把它移植到定制版的 Kafka。除了分布式一致性之外，RocketMQ 还提供了顺序消息的特性，满足顺序一致性的需求。

稳定性

稳定性是交易和金融场景的基石特性，这也是 RocketMQ 的根本。RocketMQ 除了具备核心服务的 HA 之外，还具备了全局高可用能力，在阿里内部支持同城多活、异地多活、中心容灾等高阶 HA 能力。稳定性不局限于数据和服务的高可用，RocketMQ 从产品层面对稳定性进行了全方位的建设，如消息轨迹、消息回溯、消息死信机制。

高性能

在双十一的极限流量下，RocketMQ 写消息延迟 4 个 9 在 1ms 内，100% 在 100ms 内；RocketMQ 采用 share nothing 的分布式架构，在吞吐量方面也具备无限扩展的能力，已经连续 10 年支持了双十一万亿级消息洪峰，为百万级的应用实例提供低延迟消息服务。

5. 云计算时代的 RocketMQ 5.0

5.1 云计算的新挑战

互联网的故事还在进行，云计算规模化落地的时代悄然而来。2015 年，RocketMQ 的首个云消息服务在阿里云上线了，开启了大规模的云计算实践的序幕。同时 RocketMQ 也是业界第一个提供公有云服务的开源消息队列。在大规模的云计算业务场景下，RocketMQ 面临着全新的机遇和挑战。

多样性

它不再仅服务于某一家公司的内部业务，不再局限于互联网或者金融企业，它需要实现全行业、全场景的覆盖。

标准化

对于服务企业内部的自研消息队列而言，无需考虑协议或者 API 的标准化。但是对于云消息服务来说，因为服务对象是外部企业客户，据信通院统计，80% 多的企业客户已经采纳开源技术、标准技术。所以作为一款云消息服务需要提供对业界事实标准协议、接口、SDK 的兼容，才能保证客户能够平滑上云，同时打消客户技术绑定的担忧。

云原生理念深入人心

消息队列要更好的帮助客户实现云原生应用架构，为业务降本提效。

各种新技术的兴起

包括 IoT、5G、边缘计算、事件驱动，还有事件流技术。面向这些技术趋势和多样化的业务需求，RocketMQ 进行自我进化，演进到 5.0 版本。

5.2 RocketMQ 5.0 的云原生架构

为了充分释放云的技术红利，RocketMQ 5.0 在技术架构上进行了云原生的演进。这是 RocketMQ 的云原生架构全景图，从客户端、到服务端都进行了全方位的改造，更高弹性、可用性、更低成本。

客户端采用轻量 SDK 设计理念，将原来富客户端的逻辑下沉到 Broker，满足现代化应用轻量化、Serverless 的趋势。

Broker 彻底进行弹性架构改造，分离 RocketMQ Proxy 和 Store 层，其中 Proxy 是完全无状态的计算节点，专注多协议、多领域场景覆盖，可以面向不同工作负载独立弹性，如物联网、微服务、大数据不同场景有不同的资源诉求。Store 层则专注消息的高可用存储，包括副本复制、主备切换和云存储集成。同时对 RocketMQ 的 Topic 资源进行三层解耦，面向消息的 Topic、面向流的 Topic 逻辑分片、面向底层存储的 Topic 物理分片，每一层都可以独立弹性。

在存储层引入了 Leaderless 的高可用架构：

Store 节点身份对等，Leaderless 化，0外部依赖
多副本策略可定制，可用性+可靠性+成本灵活组合
面向多可用区、多 region 组建 GEO 高可用能力

5.3 RocketMQ 5.0 业务全景

为了满足云时代多样化的用户需求，RocketMQ 5.0 从原来的互联网业务消息中间件，扩展到“消息、事件、流”超融合处理平台，解锁更全面的能力。

在消息领域，全面拥抱云原生技术，更好的弹性架构和高可用能力。

在事件领域，支持 CloudEvent 规范，以事件为中心的产品新界面，助力客户建设跨业务、跨组织的数字化商业生态。

在流领域，流存储增强批量特性，大幅度提高数据吞吐量；新增逻辑队列能力，解耦逻辑资源和物理资源，在流场景也具备无缝伸缩能力；新增流数据库 RSQLDB，提供实时事件流处理、流分析能力。

RocketMQ 基于端云一体化架构实现了完整的物联网消息队列的能力，从原来的连接应用扩展到连接物联网设备。同时 RocketMQ 5.0 也继续保持极简架构的原则，能够以最低的资源消耗、运维成本搭建服务，适合边缘计算。

5.4 RocketMQ 5.0 生态系统

除了产品的核心能力之外，RocketMQ 5.0 积极建设开源生态。一方面是应用架构生态的建设，这里既有经典的开源项目、规范的集成，比如 JMS、AMQP 等，也会有云原生技术生态的集成，比如 CloudEvents、Dapr、Envoy 。同时 RocketMQ 也会进一步发力数据架构生态，从离线大数据到实时大数据，全链路集成大数据的摄入、数据存储、数据处理、数据分析组件。