1.前言

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

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

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

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

2.背景

今天我们要学习的内容是 RocketMQ 5.0 的消息基础。前面我们提到了 RocketMQ 5.0 是“消息事件流”一体的实时数据处理平台。我们经常会常说 RocketMQ 在是业务消息领域的事实标准，也经常能够看到有很多互联网公司，在业务消息场景会使用 RocketMQ，在大数据的场景使用 Kafka。

这里，我们反复提到两个词“消息、业务消息”，指的就是分布式应用解耦，这个是 RocketMQ 的业务基本盘。通过这节课，你可以深入了解 RocketMQ 5.0 在业务消息场景的优势能力，了解为什么 RocketMQ 能够成为业务消息领域的事实标准。

这门课分为三部分内容。第一部分讲业务消息的应用解耦场景，具体解耦什么？第二部分讲 RocketMQ 在业务消息场景的基础特性。第三部分会再去做进一步的阐述，业界那么多消息队列能实现应用解耦，RocketMQ 在基础特性上有哪些增强？

3. 消息场景

RocketMQ 在业务消息领域的经典场景是应用解耦，这也是 RocketMQ 诞生初期解决阿里电商分布式互联网架构的核心场景。主要承担分布式应用（微服务）的异步集成，达到应用解耦的效果，解耦是所有的软件架构最重要的追求。

以下图为例，分布式应用（微服务）采用同步 RPC 和异步消息的对比。图例是在一个业务系统中，有三个上游应用和四个下游应用，采用同步 RPC 的方式，会有“3*4”的依赖复杂度；而采用异步消息的方式，则可以化繁为简，简化成“3+4”的依赖复杂度，从乘法简化为加法。通过引入消息队列实现应用的异步集成可以获得四大解耦优势。

第一个是代码解耦，这个极大提升业务敏捷度。如果用同步调用的方式，每次扩展业务逻辑，都需要上游应用显式调用下游应用接口，代码直接耦合，上游应用要做变更发布，业务迭代互相掣肘。通过使用消息队列，扩展新的业务逻辑，只需要增加下游应用订阅某个 Topic，上下游应用互相透明，业务可以保持灵活独立快速迭代。

第二个是延迟解耦，如果用同步调用的方式，随着业务逻辑的增加，一个用户操作的远程调用次数越来越多，业务响应越来越慢，性能衰减，业务发展不可持续。通过使用消息队列，无论增加多少业务，上游应用只要调用一次消息队列的发送接口就可以响应线上用户，它的延迟是个常量，RocketMQ 的生产消息延迟基本上都在 5ms 以内。

第三个是可用性解耦。如果用同步调用的方式，任何一个下游业务不可用，都会导致整个链路失败。这种结构下的可用性就如何串联电路，随着调用次数，可用性衰减。甚至在部分调用失败的情况下，还会出现状态不一致。而采用 RocketMQ 进行异步集成，只要 RocketMQ 服务可用，用户的业务操作就是可用的。RocketMQ 服务是通过多对主备组成的 broker 集群提供的，只要有一对主备可用，整体服务就是可用的。作为基础软件可用性远大于普通的业务应用。下游应用的业务推进都可以通过 MQ 的可靠消息的投递来达成。

最后一个是流量的解耦，也是我们常说的削峰填谷。采用同步调用的方式，上下游的容量必须对齐，否则会出现级联的不可用。容量完全对齐需要投入大量精力进行全链路压测和更多的机器成本。通过引入 RocketMQ，基于 RocketMQ 亿级消息的堆积能力，对于实时性要求不高的下游业务，可以尽最大努力消费，既保证了系统稳定性，又降低了机器成本和研发运维成本。

4. 基础特性

接下来我们以阿里电商业务为例，对于了解 RocketMQ 的应用解耦优势会更有体感。

这是经过简化后的阿里交易架构图，左边是交易应用，当用户在淘宝上下单，会调用交易应用创建订单，交易应用把订单落到数据库，然后生产一条订单创建的消息到 RocketMQ，就返回给终端用户订单创建成功的接口。完成的交易流程推进，则是依赖 RocketMQ 将订单创建消息投递给下游应用。会员应用收到订单消息，需要给买家送积分、淘金币，触发用户激励相关的业务。购物车应用则是要删除在购物车里面的商品，避免用户重复购买。同时支付系统和物流系统，也都会基于订单状态的变更，推进支付环节和履约环节。

过去十年多年，阿里电商业务持续蓬勃发展，交易的下游应用已经达到数百个，还在不断增加。基于 RocketMQ 的电商架构，极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全不用关心哪些应用在订阅交易消息，交易应用的延迟和可用性也一直保持在很高的水准，他只依赖少量的核心系统和 RocketMQ ，整个比较收敛，不会受数百下游应用的影响。交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如说物流场景就能容忍一定的延迟。通过 RocketMQ 的亿级堆积能力，极大降低了机器成本。RocketMQ 的 ShareNothing 的架构，具备了无限横向扩展的能力，已经连续 10 年支撑了高速增长的双十一消息峰值，在几年前就达到亿级 TPS。

5. 增强能力

接下来我们再来看看，经典场景里面，RocketMQ 相对于其他消息队列，有哪些差异化优势和增强。

5.1. 稳定性增强

第一个增强主要还是体现在稳定性方面的。稳定性交易、金融场景最重要的需求。RocketMQ 的稳定性不仅仅是高可用架构，它是通过全方位的产品能力来构建稳定性竞争力的。比如重试队列，当下游消费者因为业务数据不 ready 或其他原因导致某条消息消费失败，RocketMQ 不会因此阻塞消费，能将此消息加入到重试队列，然后会按时间衰减重试。如果某条消息因为某些因素经过十几次重试，始终无法消费成功。RocketMQ 会把它转到死信队列，用户就可以通过其他手段来处理这些失败的消息，这个是金融行业的刚需。甚至还能做到即便消费者消费成功，但是因为代码 bug，导致业务不符合预期。在应用业务 bug 修复完成后，RocketMQ 可以支持按照时间回放消息，类似月光宝盒，让业务按照正确逻辑重新处理。RocketMQ 的消费实现机制是采用自适应拉模式的消费在极端的场景下面，也能够避免消费者被大流量打垮。同时它在消费者的 SDK 里面，缓存本地的消息数量和消息内存占用进行阈值保护，防止消费应用的内存风险。

5.2. 可观测增强

Tracing：RocketMQ 具备优秀的可观测能力，这个是稳定性的重要辅助手段，RocketMQ 是业界第一个提供消息消息级别的可观测能力的消息队列。每条消息都可以带上业务主键，比如说在交易的场景，用户可以把订单的 ID 作为它的消息的业务主键。当某个订单的业务需要排查，用户可以基于订单 ID 去查询这条消息，能够看到消息什么时候生成的，以及消息内容。消息的可观测数据还能继续下钻，通过消息轨迹查看这条消息是哪台生产者机器发送，哪些消费者机器在什么时间消费，消费状态是成功或者失败等等。

Metrics：除此之外，它也支持了几十种核心的度量数据，包括集群生产者流量分布，慢消费者排行，消费的平均延迟、消费堆积数量、消费成功率等等。

监控：基于这些丰富的指标，用户可以搭建更加完善的监控、报警体系来进一步加固稳定性。

5.3. 接口增强 - 生产者

为了支撑更加灵活的应用架构，RocketMQ 在生产和消费等关键接口提供了多种模式。我们先来看生产者接口，RocketMQ 同时提供了同步发送接口和异步发送接口。同步发送是最常用的模式，业务流程的编排是串行的，在应用发完消息、Broker 完成存储后返回成功后，应用再执行下一步逻辑。然而在某些场景下，完成一个业务涉及多个远程调用，应用为了进一步降低延迟、提高性能，会采用全异步化的方式，并发发出远程调用（这里可以是多次发消息或者 RPC 的组合），异步收集 future 结果推进业务逻辑。

5.4. 接口增强 - 消费者

在消费者的接口方面也提供了两种，一种是监听器模式被动消费。这是目前使用最广泛的方式，用户不需要关心客户端何时去 Broker 拉取消息，何时向Broker发出消费成功的确认，也不需要维护消费线程池、本地消息缓存等细节。只需要写一段消息监听器的业务逻辑，根据业务执行结果返回 Success 或者 Failure。它属于全托管的模式，让用户专注于业务逻辑的编写，实现细节完全委托给 RocketMQ 客户端。

除了监听器模式之外，RocketMQ 还提供了主动消费模式，把更多的自主权交给用户，这种模式我们叫做 SimpleConsumer。在这种模式下，用户可以自己决定何时去 Broker 读取消息，何时发起消费确认消息。对业务逻辑的执行线程也有自主可控性，读取完消息后，可以把消费逻辑放到自定义的线程池执行。在某些场景下，不同消息的处理时长和优先级会有所不同，采用 SimpleConsumer 的模式，用户能根据消息的属性、大小做二次分发，隔离到不同的业务线程池执行处理。这种模式还提供了消息粒度消费超时时间的设定能力，针对某些消费耗时长的消息，用户能够调用 ChangeInvisibleDuration 接口，延长消费时间，避免超时重试。