RocketMQ在业务消息场景的优势有哪些呢？-电子发烧友网

消息场景

Cloud Native

RocketMQ 5.0 是消息事件流一体的实时数据处理平台，是业务消息领域的事实标准，很多互联网公司在业务消息场景会使用 RocketMQ。

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

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

分布式应用（微服务）采用同步 RPC 与异步消息的对比。比如在业务系统中，有三个上游应用与 4 个下游应用，采用同步 RPC 的方式，会有 3*4 的依赖复杂度；而采用异步消息的方式则可以化繁为简，简化为 3+4 的依赖复杂度，从乘法简化为加法。

通过引入消息队列实现应用的异步集成可以获得四大解耦优势。

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

延迟解耦 如果使用同步调用的方式，随着业务逻辑的增加，用户操作的远程调用次数会越来越多，业务响应越来越慢，性能衰减，业务发展不可持续。而使用消息队列，无论增加多少业务，上游应用只需调用一次消息队列的发送接口即可响应线上用户，延迟为常量，基本在 5ms 以内。

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

流量解耦

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

基础特性

Cloud Native

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

过去十年多年，阿里电商业务持续蓬勃发展，交易的下游应用已达数百个，并且还在不断增加。基于 RocketMQ 的电商架构极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全无需关心哪些应用在订阅交易消息，交易应用的延迟与可用性也一直保持在很高水准，只依赖少量的核心系统与 RocketMQ，不会受数百个下游应用的影响。

交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如物流场景能容忍一定的延迟。通过 RocketMQ 的亿级堆积能力，极大降低了机器成本。RocketMQ 的 shared-nothing 架构具备无限横向扩展的能力，已经连续 10 年支撑了高速增长的双十一消息峰值，在几年前达到亿级 TPS。

增强能力

Cloud Native

经典场景下，RocketMQ 相对于其他消息队列，拥有诸多差异化优势与增强。

首先，稳定性方面，稳定性交易是金融场景最重要的需求。RocketMQ 的稳定性不仅限于高可用架构，而是通过全方位的产品能力来构建稳定性竞争力。比如重试队列，当下游消费者因为业务数据不 ready 或其他原因导致某条消息消费失败，RocketMQ 不会因此阻塞消费，而是能将此消息加入到重试队列，然后按时间衰减重试。如果某条消息因为某些因素经过十几次重试始终无法消费成功，则 RocketMQ 会将它转到死信队列，用户可以通过其他手段来处理失败的消息，是金融行业的刚需。

同时，消费成功后如果因为代码 bug 导致业务不符合预期，应用可以对业务 bug 进行修复并重新发布，然后应用消息回溯的功能将消息拉回到之前的时间点，让业务按照正确逻辑重新处理。

RocketMQ 的消费实现机制采用自适应拉模式的消费，在极端的场景下能够避免消费者被大流量打垮。同时，在消费者的 SDK 里，做了缓存本地的消息数量与消息内存占用的阈值保护，防止消费应用的内存风险。

其次，RocketMQ 还具备优秀的可观测能力，是稳定性的重要辅助手段。

RocketMQ 是业界第一个提供消息消息级别可观测能力的消息队列，每条消息都可以带上业务主键，比如在交易场景，用户可以将订单 ID 作为消息的业务主键。当某个订单的业务需要排查，用户可以基于订单 ID 查询该条消息的生成时间以及消息内容。消息的可观测数据还能继续下钻，通过消息轨迹查看消息由哪台生产者机器发送、由哪些消费者机器在什么时间消费、消费状态是成功或失败等。

除此之外，它支持了几十种核心的度量数据，包括集群生产者流量分布、慢消费者排行、消费的平均延迟、消费堆积数量、消费成功率等。基于丰富的指标，用户可以搭建更加完善的监控报警体系来进一步加固稳定性。

为了支撑更灵活的应用架构，RocketMQ 在生产与消费等关键接口提供了多种模式。

生产者接口：RocketMQ 同时提供了同步发送接口与异步发送接口。同步发送是最常用的模式，业务流程的编排是串行的，在应用发完消息、Broker 完成存储后返回成功后，应用再执行下一步逻辑。然而在某些场景下，完成业务涉及多个远程调用，应用为了进一步降低延迟、提高性能，会采用全异步化的方式，并发发出远程调用（可以是多次发消息或 RPC 的组合），异步收集结果推，进业务逻辑。

在消费者的接口方面也提供了两种方式：

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

主动消费模式

将更多的自主权交给用户，也称为 Simple Consumer。在该种模式下，用户可以自己决定何时去 Broker 读取消息、何时发起消费确认消息。对业务逻辑的执行线程也有自主可控性，读取完消息后，可以将消费逻辑放在自定义的线程池执行。在某些场景下，不同消息的处理时长与优先级会有所不同，采用 Simple Consumer 的模式，用户可根据消息的属性、大小做二次分发，隔离到不同的业务线程池执行处理。该模式还提供了消息粒度消费超时时间的设定能力，针对某些消费耗时长的消息，用户能够调用 change Invisible Duration 接口，延长消费时间，避免超时重试。

总结

Cloud Native

消息经典场景：应用解耦；