RocketMQ在业务消息场景的优势有哪些呢？
01
消息场景
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 亿级消息的堆积能力，对于实时性要求不高的下游业务，可以尽最大努力消费，既保证了系统稳定性，又降低了机器成本与研发运维成本。
02
基础特性
cloud native
阿里的交易应用流程为：用户在淘宝上下单时会调用交易应用创建订单，交易应用将订单落到数据库，然后生产一条订单创建的消息到 rocketmq，返回给终端用户订单创建成功的接口。完成的交易流程推进则是依赖 rocketmq 将订单创建消息投递给下游应用，会员应用收到订单消息，需要给买家赠送积分、淘金币，触发用户激励相关的业务。购物车应用则是负责删除在购物车里面的商品，避免用户重复购买。同时，支付系统与物流系统也都会基于订单状态的变更，推进支付环节与履约环节。
过去十年多年，阿里电商业务持续蓬勃发展，交易的下游应用已达数百个，并且还在不断增加。基于 rocketmq 的电商架构极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全无需关心哪些应用在订阅交易消息，交易应用的延迟与可用性也一直保持在很高水准，只依赖少量的核心系统与 rocketmq，不会受数百个下游应用的影响。
交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如物流场景能容忍一定的延迟。通过 rocketmq 的亿级堆积能力，极大降低了机器成本。rocketmq 的 shared-nothing 架构具备无限横向扩展的能力，已经连续 10 年支撑了高速增长的双十一消息峰值，在几年前达到亿级 tps。
03
增强能力
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 接口，延长消费时间，避免超时重试。
04
总结
cloud native
消息经典场景：应用解耦；
rocketmq 基础特性：发布订阅、可靠消息、亿级堆积、无限扩展；
业务消息场景的增强能力：稳定性、可观测、多样化接口。
如何运用工业物联网来解决工业设备的痛点
荣耀V9、华为Mate9对比评测：华为荣耀V9和华为Mate9不知道买谁？内存、屏幕、摄像、功能、配置对比
笔记本每日一贴——RAID
新款AirPods Pro售价1899元
理想汽车公布11月交付数据，实现25.8%巨大涨幅
RocketMQ在业务消息场景的优势有哪些呢？
RFID智能仓储管理解决方案
microchip宣布推出全新零漂移器件 进一步扩展其仪表放大器产品组合
条：马斯克15年内将培育恐龙，公牛集团遭反垄断调查
警惕这些“挂羊头卖狗肉”的高科技培训
当今的射频半导体格局正在发生变化
优博讯出席OpenHarmony技术日，探讨下一代安全支付终端
经营问题不断浮现 陆台联合重新审核JDI业务
通用电阻的一般用途
弹片微针模组针对测试中小pitch的难题提供了解决方案
关于国内芯片行业的一些认知
有哪些可以用于避障感应的红外发射接收管？
TVS二极管IV曲线的特征以及钳位电气模型
爱立信和香港SMARTONE合作推出 WI-FI 通话服务
TMR磁阻传感器的优势特点
消息场景
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 亿级消息的堆积能力，对于实时性要求不高的下游业务，可以尽最大努力消费，既保证了系统稳定性，又降低了机器成本与研发运维成本。
02
基础特性
cloud native
阿里的交易应用流程为：用户在淘宝上下单时会调用交易应用创建订单，交易应用将订单落到数据库，然后生产一条订单创建的消息到 rocketmq，返回给终端用户订单创建成功的接口。完成的交易流程推进则是依赖 rocketmq 将订单创建消息投递给下游应用，会员应用收到订单消息，需要给买家赠送积分、淘金币，触发用户激励相关的业务。购物车应用则是负责删除在购物车里面的商品，避免用户重复购买。同时，支付系统与物流系统也都会基于订单状态的变更，推进支付环节与履约环节。
过去十年多年，阿里电商业务持续蓬勃发展，交易的下游应用已达数百个，并且还在不断增加。基于 rocketmq 的电商架构极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全无需关心哪些应用在订阅交易消息，交易应用的延迟与可用性也一直保持在很高水准，只依赖少量的核心系统与 rocketmq，不会受数百个下游应用的影响。
交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如物流场景能容忍一定的延迟。通过 rocketmq 的亿级堆积能力，极大降低了机器成本。rocketmq 的 shared-nothing 架构具备无限横向扩展的能力，已经连续 10 年支撑了高速增长的双十一消息峰值，在几年前达到亿级 tps。
03
增强能力
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 接口，延长消费时间，避免超时重试。
04
总结
cloud native
消息经典场景：应用解耦；
rocketmq 基础特性：发布订阅、可靠消息、亿级堆积、无限扩展；
业务消息场景的增强能力：稳定性、可观测、多样化接口。
如何运用工业物联网来解决工业设备的痛点
荣耀V9、华为Mate9对比评测：华为荣耀V9和华为Mate9不知道买谁？内存、屏幕、摄像、功能、配置对比
笔记本每日一贴——RAID
新款AirPods Pro售价1899元
理想汽车公布11月交付数据，实现25.8%巨大涨幅
RocketMQ在业务消息场景的优势有哪些呢？
RFID智能仓储管理解决方案
microchip宣布推出全新零漂移器件 进一步扩展其仪表放大器产品组合
条：马斯克15年内将培育恐龙，公牛集团遭反垄断调查
警惕这些“挂羊头卖狗肉”的高科技培训
当今的射频半导体格局正在发生变化
优博讯出席OpenHarmony技术日，探讨下一代安全支付终端
经营问题不断浮现 陆台联合重新审核JDI业务
通用电阻的一般用途
弹片微针模组针对测试中小pitch的难题提供了解决方案
关于国内芯片行业的一些认知
有哪些可以用于避障感应的红外发射接收管？
TVS二极管IV曲线的特征以及钳位电气模型
爱立信和香港SMARTONE合作推出 WI-FI 通话服务
TMR磁阻传感器的优势特点