RocketMq-入门篇_rocketmq入门-CSDN博客

本文链接：https://blog.csdn.net/WKX18330698534/article/details/125352353

前言

你在工作中是否遇到过这些问题？系统平时访问流量平平，在某个时间段好像决堤似的突增？上下游执行链路长，重要和不重要的执行内容混在一起，层层嵌套？面对高并发时，下游系统无法承载海量的调用量，影响上游响应……如果你也有，那就和我一起来学习rocketMq吧，据说rocketMq能帮我们很好的解决这些问题。

一、rocketMq是什么？

Apache rocketMq是阿里开发的一款具有低延迟，高可靠的，万亿级容量，可灵活扩展的分布式消息队列。由4部分组成：nameSrv，broker，producer，consumer，每部分都支持水平扩展。

nameSrv：提供轻量级的服务发现与路由，每个nameSrv都记录完整的路由信息，起到注册中心的作用。与ZooKeeper不同的是，nameSrv的每个节点彼此不通信，无状态，无主从。

broker：提供轻量级的topic和queue机制来存储消息。

producer：消息生产者。

consumer：消息消费者。

从官方文档了解到，因为早期的ActiveMq5.X无法支持业务吞吐量的增大，而Kafka在低延迟和高可靠方面无法满足要求，于是技术团队发明一个新的消息传递引擎来处理更广泛的用例集，从传统的发布/订阅场景到大容量实时零丢失容忍交易系统，就是rocketMq。官方文档给出了activeMq，kafka，rocketMq的对比，从一个CSDN博主的文章中还读到了与RabbitMq 对比，一起看下

二、rocketMq的应用

异步解耦

1、异步解耦，“缩短”执行链路

举个例子，在商城系统中用户取消订单时，至少需要做这几步：

①调用订单系统更新订单状态为取消；

②调用计费系统费用计算和退款；

③调用优惠券系统退还用户优惠券（②和③也可能在一个流程里；有些公司优惠券系统和计费系统是两个系统）；

④通知商家；

⑤多平台合作的情况下，通知到其他平台订单已取消；

在大型的商城项目中需要执行节点可能更多，比如淘宝系统，可能还会累积用户取消次数，取消次数达到阈值后，将用户列入风控名单，限制用户购买运费险等。如果这些操作我们放到一个线程里执行，执行的步骤越多，给用户响应会越慢；上一步执行失败可能会影响后面的操作无法执行；有些步骤执行失败后可能需要重试……所有执行节点耦合在一起，一笔订单取消用3s以上都有可能，而我们正常的APP响应，超过500ms，都会感觉到卡顿，这样肯定不行。

所以，我们必须把执行步骤解耦。用户最关注步骤①和②的执行结果，所以①和②的优先级最高，执行完成后需要立刻返回；③④⑤可以晚点告知用户，优先级相对降低，且③④⑤不依赖彼此的执行结果，所以我们可以新建一个线程池专门执行③④⑤，并分别添加异常处理。这时候，我们使用新建线程池的方式完成了解耦操作。

随着使用系统的人数增多，订单量越来越多，系统的QPS持续升高，机器的负载也越来越高，系统响应时长又变慢了，怎么办呢？你可能会说，都这时候了，那肯定是扩容啊。是的，那怎么个扩法呢？

方法一：横向扩展，把项目往服务器上多部署几个；

方法二：使用rocketMq；我们之前是新建了一个线程池，专门执行③④⑤。方法二简单来说就是换一种异步执行的方式，把③④⑤迁到新的系统ConsumerProject，原系统简称OrderProject。当①②执行完成，发送消息到消息队列，ConsumerProject建立监听，监听到消息后执行③④⑤。

方法二的好处是我们可以根据系统负载情况对OrderProject 和ConsumerProject 分别扩容，比如在机器有限的情况下，OrderProject 可以优先部署在性能相对比较好的机器上，可能部署2个实例就够了；ConsumerProject 执行的步骤比较多，可以根据情况多部署几个实例。这样通过rocketMq可以很好的将执行链路“缩短”，对操作步骤解耦。

2、减少下游对上游的影响

还用1的例子，当优惠券系统响应慢或者宕机了，因为③在ConsumerProject中执行，所以此时最多也只影响到ConsumerProject工程，不会影响到OrderProject工程。用户收到优惠券退还的通知会晚一点，但订单取消和退款都能正常进行。

削峰平谷

以秒杀系统为例，用户的请求量在短时间内暴增，消费者消费消息时，很可能出现因消息发送量突增而来不及处理的情况，导致消费方负载过高，进而导致影响系统稳定性。在实际场景中，消息的到来具有瞬时性、不规律性，导致系统可能出现空闲资源。rocketMq削峰平谷就是把超过消费端处理能力的消息（图中黄色部分）均摊到后面系统空闲时去处理，让系统负载处在一个稳定的水位，同时尽可能地处理更多消息。