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 亿级消息的堆积能力，对于实时性要求不高的下游业务，可以尽最大努力消费，既保证了系统稳定性，又降低了机器成本与研发运维成本。
阿里的交易应用流程为：用户在淘宝上下单时会调用交易应用创建订单，交易应用将订单落到数据库，然后生产一条订单创建的消息到 RocketMQ，返回给最终用户订单创建成功的接口。完成的交易流程推进则是依赖 RocketMQ 将订单创建消息投递给下游应用，会员应用收到订单消息，需要给买家赠送积分、淘金币，触发用户激励相关的业务。购物车应用则是负责删除在购物车里面的商品，避免用户重复购买。同时，支付系统与物流系统也都会基于订单状态的变更，推进支付环节与履约环节。
过去十年多年，阿里电商业务持续蒸蒸日上，交易的下游应用已达数百个，并且还在持续不断的增加。基于 RocketMQ 的电商架构极大提高了阿里电商业务的敏捷度，上游核心的交易系统完全无需关心哪些应用在订阅交易消息，交易应用的延迟与可用性也从始至终保持在很高水准，只依赖少量的核心系统与 RocketMQ，不会受数百个下游应用的影响。
交易的下游业务类型不一，有大量的业务场景不需要实时消费交易数据，比如物流场景能容忍一定的延迟。通过 RocketMQ 的亿级堆积能力，极大降低了机器成本。RocketMQ 的 shared-nothing 架构具备无限横向扩展的能力，已经连续 10 年支撑了快速地增长的双十一消息峰值，在几年前达到亿级 TPS。
经典场景下，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 接口，延长消费时间，避免超时重试。
审核编辑：刘清声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容图片侵权或者别的问题，请联系本站作侵删。侵权投诉存储器存储器+关注
(阿里云消息队列(MQ)的内核) 也顺利开源，得到大家的关注。那么，消息中间件性能
：消息的发送和订阅一定是共存的要支持多个订阅端订阅自己感兴趣的消息本期我们将针对
MQTT协议架构模型 /
的扩展项目 /
的标准模型，慢慢地发展成与厂商无关、平台无关的分布式消息及流处理领域的应用开发
上。无时无刻都要运输、而普通的人力运输存在人力的投入大，效率不尽如人意等问题。由此agv应运而生。那么它有什么
? /
消息中间件通过容器化的方式部署在 openEuler 操作系统上运行，借助 openEuler 系统对于 OS 缓存回收
on openEuler提供高性能消息队列的稳定性解决方案 /
的主从复制 /
主要使用Java开发，而RabbitMQ则使用Erlang语言开发。 性能：
开关电源首次上电“炸机”？一招教你搞定#开关电源 #电源 #电源工程师 #硬件电路 #电路设计
2020年1月2日直播-RTTstudio专题-4 #RTTstudio
内含墨水,禁止强拆？拆解优衣库和普通超市的防盗扣，看工作原理 #硬核拆解