RocketMQ在业务消息场景的优势详解

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

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

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

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

• 代码解耦
  极大提升业务敏捷度。如果用同步调用的方式，每次扩展业务逻辑都需要上游应用显式调用下游应用接口，代码直接耦合，上游应用要做变更发布，业务迭代互相掣肘。而通过使用消息队列扩展新的业务逻辑，只需要增加下游应用订阅某个 Topic，上下游应用互相透明，业务可以保持灵活独立快速迭代。
• 延迟解耦
  如果使用同步调用的方式，随着业务逻辑的增加，用户操作的远程调用次数会越来越多，业务响应越来越慢，性能衰减，业务发展不可持续。而使用消息队列，无论增加多少业务，上游应用只需调用一次消息队列的发送接口即可响应线上用户，延迟为常量，基本在 5ms 以内。
• 可用性解耦
  如果使用同步调用的方式，任何下游业务不可用都会导致整个链路失败。该种结构下类似于串联电路，甚至在部分调用失败的情况下，还会出现状态不一致。而采用 RocketMQ 进行异步集成，只要 RocketMQ 服务可用，用户的业务操作便可用。RocketMQ 服务通过多对主备组成的 broker 集群提供，只要有一对主备可用，则整体服务可用，作为基础软件，可用性远大于普通的业务应用，下游应用的业务推进都可以通过 MQ 的可靠消息投递来达成。
• 流量解耦

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

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

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

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

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

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

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

• 主动消费模式

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

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

• RocketMQ 基础特性：发布订阅、可靠消息、亿级堆积、无限扩展；

• 业务消息场景的增强能力：稳定性、可观测、多样化接口。