✅PmHub整合Rocketmq实现审批流消息推送（👍必看）

你好呀，我是苍何！

欢迎来到面试系列！这篇文章主要讲 PmHub 中如何用 Rocketmq 进行异步解耦，实现任务审批、任务逾期等提醒的消息推送。

消息队列 mq，历年来都是面试的重灾区，面试问题更是层出不穷，你可以选择直接背网络上人家整理好的八股，但，作为 PmHub 的付费用户，我们当然希望你能通过 PmHub，一次性掌握消息队列以及 Rocketmq 的精髓。

本文干货颇多，我们会结合 PmHub 的具体业务场景结合理论，让你深入理解，满满的代入感，作为 PmHub 的付费用户，学完本教程，出去，我敢自信的说，吊打一堆竞争者。如果学有所成，还望给我们多宣传宣传，毕竟好的产品需要遇上好的人，如屏幕前的你一样优秀，我们也希望更多优秀的小伙伴能看到我们的成果。

本章可谓是干货满满，面试中也是重中之重，以下描述你可以直接写进简历，也可以根据你的理解进行优化。

将项目和任务审批流消息放入 Rocketmq，实现消息的异步解耦，提升系统效率和服务稳定性。

下面就进入正题学习吧！

什么是消息队列？

不知道你是否好奇，明明系统他老人家一个人活得好好的，非得整那么多稀奇古怪的东西加上去，比如消息队列这家伙，加在系统之上，犹如给系统配备了一把剑，你说系统是觉得爽还是不爽呢？

系统觉得爽不爽，我不知道，但至少我是很爽的，因为消息队列这家伙，谁用谁爽！😂

言归正传，何为消息队列，他可以看做是存放消息的容器，需要用的时候取出来即可。举个生活中的例子：

想象一下你在一家快餐店点餐，店员会把你的订单写在一张纸上，然后放到厨房的一个篮子里。厨师会按顺序从篮子里取出订单，制作食物。这张订单纸就是“消息”，而那个篮子就是“消息队列”。消息队列的作用就是把你的订单（消息）从前台传递到后台（系统或应用程序）。

整个消息队列组件其实就三部分：

生产者：生产消息的一方，例子中的顾客就是生产者
消息队列：就是消息的「篮子」，用来存放消息
消费者：专门负责消息的一方，比如例子中的厨师

在分布式微服务系统中，消息队列在系统中扮演者很重要的角色，如果说整个系统是皇帝，消息队列至少是三品以上的大臣了。主要有解耦、异步处理、削峰等作用。

为什么使用消息队列？

先从面试的角度分析，一般面试官这么问就是想知道你项目中消息队列的具体使用场景，期望你的回答是在项目中如何使用的？具体业务场景是什么？遇到什么挑战？

消息队列核心的三大使用场景是必须要知道的：解耦、异步、削峰

解耦

解耦说点人话就是强制系统之间分离，不要所有代码藕和在一起，就拿微服务来说，解耦也是最重要的一个目的。

举个场景，假设没使用消息队列，A 系统需要将消息通过接口发送给 B、C、D 三个系统，正常来说，没太大问题，现在又有 E 系统需要，D 系统说我不需要了，A 系统的负责人觉得需要针对下游系统做各种改动，简直崩溃~~

在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！

如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

面试技巧：

PmHub 中消息队列有多重使用场景，比如任务审批、结果回执、任务指派、任务预期等，你可以结合一个场景来描述解耦这个作用。比如任务审批，如果不用消息队列，项目系统产生任务完成的数据需要给到审批系统，以及用户系统，而且是同步调用的，会增加系统耦合性，所以用 MQ 来做解耦。

异步

异步也是很好理解，反面就是同步吧，同步的代码我们没少写🐶，比如 A 系统接收到一个任务，在本地写库的同时，还需要在 BCD 其他三个系统也写库，A 自己写库逻辑花费 2ms，BCD 写库分别花费 200ms、300ms、450ms，最终请求响应时间大于 2+200+300+450=952ms，接近 1s 了，相信我，你会被用户无情「痛骂」，神马系统，慢死了。。。。

对于正常系统来说，200ms 以内返回响应结果是可以接受的，且是无感知的，也就是丝滑。

如果使用 MQ 的话，BCD 系统的逻辑完全可以放在 MQ 异步执行，A 系统发 3 条消息到 MQ，假设耗时 5ms（不能再多了！），那么 A 系统最终返回给用户的请求时间就是 2+5=7ms，好家伙，真男人，这么快，用户不得好好夸夸你。

对于 BCD 三个系统写库操作，A 系统不关心 BCD 返回结果已经返回给用户了，对用户是无感知的。

这就是 MQ 异步的强大之处。

削峰

消息队列（MQ）的削峰场景就像一个水库的作用。在高峰时期，消息队列就像水库一样，把突如其来的大量请求暂时存储起来，等到流量下降的时候再慢慢处理。这就避免了系统在高峰时期被压垮。

将短时间高并发产生的事务消息存储在消息队列中，然后后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉。

很好解释的几个例子，比如 12306 春节抢票，合理使用 MQ，就能大大减轻系统的压力，还有双十一，电商系统通过 MQ 也能减轻压力。下面是一张图：

Kafka、ActiveMQ、RabbitMQ、RocketMQ 区别


特性	Kafka	ActiveMQ	RabbitMQ	RocketMQ
功能支持	分布式、分区、高吞吐量、流处理、持久化	JMS 支持、持久化、事务、消息过滤	消息路由、插件机制、持久化、多种协议支持	分布式、高吞吐量、事务、定时和延时消息、持久化
可用性	高（多副本机制、自动恢复）	高（支持主从架构和多种持久化机制）	高（镜像队列、集群模式）	高（多副本机制、集群模式）
消息可靠性	高（数据复制、多副本）	高（持久化存储、事务支持）	高（确认机制、持久化存储）	高（数据复制、多副本、持久化存储）
时效性	毫秒级（取决于配置和网络条件）	毫秒级（取决于配置和网络条件）	微秒级到毫秒级（取决于配置和网络条件）	毫秒级（取决于配置和网络条件）
topic 数量对吞吐量的影响	影响较大（分区机制带来管理和资源消耗）	影响中等（队列管理开销）	影响较小（高效的路由机制）	影响中等（分区机制和管理开销）
单机吞吐量	高（百万级消息每秒）	中等（十万级消息每秒）	中等（十万级消息每秒）	高（百万级消息每秒）
Client SDK	多语言（Java、Scala、Python等）	多语言（Java、C、C++等）	多语言（Java、Erlang、.NET等）	多语言（Java、C++、Go等）

如果是大数据领域的实时计算、日志采集等场景，就用 kafka

对时效性有要求，且不关心底层情况，用 RabbitMQ 就可以

国内的大部分项目，特别是微服务项目，就用阿里的 RocketMQ 就好了，有丰富的教程且是阿里出品，经历过双十一这种大促，肯定是没问题的。所以 PmHub 也选择了 RocketMQ。

RocketMQ 介绍

有了上述基础知识的铺垫，相信对消息队列应该有些理解了，PmHub 中最终选择了 RocketMQ，那么什么是 RocketMQ 呢？

RocketMQ 是阿里开源的消息中间件，具有高性能、高可靠、高实时、分布式 的特点，底层是用 Java 语言开发的分布式组件。2016 年成为 Apache 的顶级项目，在阿里内部经历了多年的双十一的拷打，主打一个能抗能打。

官网地址：https://rocketmq.apache.org/
开源地址：https://github.com/apache/rocketmq

官网做的还是很炫酷的！下面是一张底层架构图：

RocketMQ 主要有以下 4 个部分：

部署架构部分	功能描述
生产者 Producer	发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。
消费者 Consumer	消息消费的角色。 - 支持推（push）和拉（pull）两种模式对消息进行消费。 - 支持集群方式和广播方式的消费。 - 提供实时消息订阅机制，可以满足大多数用户的需求。
名字服务器 NameServer	名字服务器是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。主要包括两个功能： - Broker管理： NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据，并提供心跳检测机制，检查Broker是否存活。 - 路由信息管理：每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。 NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker向每一台NameServer注册自己的路由信息，每个NameServer实例上都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
代理服务器 Broker	Broker主要负责消息的存储、投递和查询以及服务高可用保证。 - NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。 - Broker部署相对复杂。在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

总结：

每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。

PmHub 为什么要用 RocketMQ？

妈呀，恭喜你看到这部分了，先给你点个赞。

PmHub 中的消息队列使用了 RocketMQ，主要基于以下几点原因：

本人早年在阿里，故而用老东家产品也在情理之中
PmHub 中业务场景对延迟性要求不高，故而不用 RabbitMQ
RocketMQ 是天然的分布式组件，PmHub 刚好又是个分布式微服务项目，对学习来说再好不过。
RocketMQ 是 Java 编写的，对我们技术成本比较低
接入友好，有 Java 的 SDK，且稳定可扩展

Docker 部署 RocketMQ

这部分主要是本地部署单机版的 RocketMQ 教程，建议大家动手操作下，遇到问题，可以 PmHub 群里交流。

通过 Docker 的方式简单高效，可以快速部署一个单节点单副本的 RocketMQ 服务。

拉取 RocketMQ 镜像

我拉取的是 dockerhub 上 RocketMQ 的镜像版本 5.1.0，请尽量保持版本和我的一致，否则会有意想不到的事情发生。

docker pull apache/rocketmq:5.1.0

拉取成功后，可以看下本地镜像列表是否已有啦：

创建容器共享网络

为什么要创建 docker 共享网络？

容器间通信：创建一个 Docker 网络可以确保同一个网络中的容器可以通过容器名称进行通信，而不需要知道对方的 IP 地址。这对于需要相互通信的服务非常重要，比如 RocketMQ 的多个组件（如 NameServer 和 Broker）。

隔离性和安全性：Docker 网络提供了一个隔离的网络环境，不同网络中的容器彼此隔离。这增加了安全性，防止外部或其他不相关的容器访问敏感服务。

简化配置：使用 Docker 网络，配置变得更加简单。容器可以通过名称互相访问，无需担心容器重启后 IP 地址发生变化。

对于像 RocketMQ 这样的分布式系统，它包含多个服务（NameServer、Broker、Producer、Consumer 等），这些服务需要互相通信。创建一个共享网络使得这些服务可以轻松发现和通信。

创建容器共享网络命令：

docker network create rocketmq

启动 NameServer

# 启动NameServer(windows)
docker run -d --name pmnamesrv -p 9876:9876 --net rocketmq apache/rocketmq:5.1.0 sh mqnamesrv
# MAC，需要指定平台
docker run --platform linux/amd64 -d --name pmnamesrv -p 9876:9876 --net rocketmq apa...