消息队列——消息队列入门

矫情吗；* 2023-09-28 04:18 53阅读 0赞

本篇介绍消息队列相关的知识，包含：什么是消息队列、为什么要使用消息队列、使用消息队列需要注意的点、常见的消息中间件，对MQ做一个快速的熟悉和入门；

#### **1.** **什么是消息队列？** ####

一个生动的例子：

![d72edea5190340b4ae95c5867879abbc.png][]

如果把**队列**抽象成一个**集合体**，那么消息队列也就是一堆消息的集合；按照这个思路我想到了订阅「杂志」；这不就是一堆消息的集合吗，关心这些消息的人都能通过「订阅杂志」来获得这些消息；通过不同种类的「杂志」或许到不同的消息；并且如果我作为出版方，我可以提供所有出版过的「杂志」，也可以选择让读者只能购买近期的；

通过以上的例子，可以粗略的认为：

1）「杂志」的内容相当于消息；  
2）「出版方」是消息的提供者，他只管把内容写到不同的杂志（不关心谁看）；  
3）「消费者」就相当于消息的消费者，他只管订阅查看自己需要的消息（自己取，而不关心是谁发来的）；

**名词解释**：

**I. 消息（Message）**

是指在应用间传送的数据；消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象；

**II. 消息队列（Message Queue，简称MQ）**

从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已；

是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递；

消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的，这样发布者和使用者都不用知道对方的存在，从而可以做到生产者与消费者之间的解耦；

**主要用途**：不同应用之间通信；

#### **2. 为什么使用消息队列？（优点）** ####

再来个例子：

以常见的订单系统为例，用户点击【支付】按钮之后的业务逻辑可能包括：扣减库存、生成相应单据、扣优惠券、发积分、发红包、发短信通知等（我可以**斩钉截铁**的告诉你主流电商真正的下单流程涉及的系统绝对在10个以上）；

在业务发展初期这些逻辑可能放在一起同步执行，但是随着业务的发展订单量增长，业务流程中涉及的调用方太多，导致接口的**RT**（**ResponseTime响应时间**）增加，并且每一部都有可能需要去处理RPC失败的逻辑；

为了提升系统服务的性能，这时可以**将一些不需要立即获得返回结果的操作拆分出来异步执行**，比如发放红包、发积分、发短信通知等；例如短信你迟几秒发送，用户根本不在意；

这种场景下就可以用 MQ ，在下单的主流程（比如扣减库存、生成相应单据）完成之后发送一条支付完成的消息到 MQ 让主流程快速完结，而下游业务方如权益系统、积分系统、短信通知系统，自行监听 MQ 的消息执行相应的业务逻辑；

「**问题1**」**：**上面说了为了异步执行，那我用异步线程/线程池去做不是一样的吗？为什么要用MQ？

**解耦**；你一个订单流程，除了自己系统内部的订单落库，系统外部调用还有扣积分、扣优惠券、发短信等等，这么多业务要调用这么多的接口；若有新系统加入，需要嵌入支付流程中，难不成**每次加一个调用的接口还要重新发布系统（走一遍接口对接、联调、开发、测试、发布的流程）**？

合理的做法就是，你就把**支付成功的消息告诉别的系统**，他们收到了去处理就好了；你只用走完自己的流程，把自己的消息发出去；那后面要接入什么系统简单，直接订阅你发送的支付成功消息，**谁需要谁监听**就好了；

「**问题2**」**：**那你的流程走完了，你不用管别的系统是否操作成功吗？比如你下单了积分没加，优惠券没扣怎么办？

问题是个好问题，**但是没必要考虑**，业务系统本身就是自己的开发人员维护的，你积分扣失败关我下单的什么事情？那这里反问一个问题，"用户支付成功，订单落库，但因为外部系统内异常如权益发放系统发放红包失败或积分系统发放积分失败，你该怎么处理？"

**难道可以回滚支付成功的流程，给用户退款吗？显然不行！**明明就是你系统的问题，怎么能影响到用户？你可能收到了告警，然后从业务日志中找到当时调用积分系统接口的入参，然后去手动执行一下补偿；那这样的异常数巨大怎么办呢，当然你可以将记录存入重试表用定时任务驱动执行；亦或是代码中使用了重试模板（前提是接口幂等）；此外，如果外部系统的调用你都放在了一个异步线程里，为了他们互不影响你可能每块代码都**try catch**一下，但是这样的代码就像个**定时炸弹，**如果出现了不在预期内的异常，你可能会领个**P0故障**直接提桶**；**

**异常归因**；实际上，这种外部系统自己的问题说白了你也处理不了，那就**各自保证好各系统的可靠性**就好了；但是话虽这么说，这其实算是消息队列的一个缺点，涉及到**分布式事务**的知识点；对于有事务要求的多个系统调用组合，如果中间件有分布式事务平台，那打包丢给它即可，如果没有那就要自己去实现，订单场景最常见的就是最终一致性方案；

我在版本开发时，使用消息队列MQ方案时，也曾经有小白问这个问题，场景是"作为一个物料配置的平台，在物料审核通过后，需要将物料信息投放给多个外部系统"，当时其中的一个外部系统的开发就问，为何我使用MQ而不直接在审核通过的处理流程中调用它的同步接口呢？看完上面的描述相信你已经可以回答这个问题；这里贴一下我在技术方案里对这位同学的回复：

/**
     * 1. 对于总流程为"(1)本系统业务操作->(2)同步给下游系统"，使用消息可以解耦，本系统不用写调用下游dubbo的代码，这么做的优势在相同消息投递多个业务方时更加明显；
     * 2. 另外消息的一个天然的优势就是——不需要接口协议，这个优点在下游业务方多的情况下也非常突出；此外，如下游业务方dubbo升级时，本系统也完全不需要感知；
     * 3. 思考一个问题：如果使用dubbo同步调用方式，那么各个业务方都有失败的处理逻辑，如果在当前系统内各自去写一遍，是否令人头疼？
     * 4. 再考虑一个问题：同步下游是否成功与主流程无关，或者这么理解：下游业务方的系统异常不应该导致本系统"已经成功"的业务操作失败，所以要做成异步，但是这个消息要求最终一定要投递到业务方并且被正确处理并告知到本系统；
     * C端的较多场景都需要考虑这点，一个重要的原因就是"用户体验"和"用户口碑"，对于非转账类业务，一般都要设计的不能那么强一致性；
     * 5. 从鲁棒性/可靠性上考虑：本系统内成功调用下游接口失败又不能让主流程终止，但下游恢复后又希望这一整个流程可以自动恢复（至少不需要开发手动操作），怎么做？
     * 将消息持久化并且通过任务驱动，业务方通过ACK回执告知重要消息被正确的处理；
     * 下游的不可用，往往是短时间内发生的，如发布上线、流量切换、DB连接、redis抖动等问题导致的；通过上面的方式，在下游系统自恢复后，消息可被正常消费，不需要开发同学手动处理；
     * 6. 本次使用的模板设计模式可以将投递消息方式(包括消息体的通用处理逻辑)和处理回执的方式抽象出来，交由消息绑定的实现类去执行，具备一定的通用性；
     * <p>
     * 不过还是那句话——总没有完美的技术方案，现在看似合理的方案从某些角度或多或少也存在一些问题；
     * 希望开拓视野，技术进步时能选择当下较为合理的方案；
     * </>
     */

#### **3. 消息队列的优点？** ####

下面总结下使用消息队列的优点；

**好处一：解耦**

这个优点上面已经分析过了，这里再举一个例子，假设我们做了一个会议室预定系统，我们的一个设备坏了。我们需要通知预定这个会议室的所有人，于是我们需要发邮件，伪代码如下：

![9cbb640be0314d8eae2aafe57fbb5955.png][]

问题来了，如果我们后来发现设备坏了并且需要更改可用库存的数量，这时候我们是不是要在这里加入 InventoryService 库存服务的代码呢？后来如果经理说设备坏了应该通知他才对啊，所以我们要不要加入 emailService.sendEmailTo(Manager) 这样的代码呢？

随着我们业务模块接入越来越多，我们的代码与其他模块越来越耦合，修改代码的难度也指数级的增加，所以我们引入「消息队列」，把「设备坏了」这样的消息发送到队列中，其他关心这条消息的业务就会得到这样的「通知」，然后就会去做对应的事，这样各个模块之间就解耦了。伪代码看上去如下：

![24ad57ddb5ec48c38cda0dc0bda99f0d.png][]

消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息；

消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来；

对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计，达到解耦的目的；

**好处二：异步处理**

接着上面的例子，假设我们已经把「发送邮件」、「修改库存」以及「通知经理」的代码都写入了我们的 Service 代码中，它们分别耗时：30ms、50ms、80ms，

并且我们得知，原本最主要的功能其实是「发送邮件」，但我们完成主要的功能之后却等待了更多的额外时间，这显示是不合理的；

所以我们为了提高用户体验&提高吞吐量，我们其实可以引入「消息队列」来进行异步的操作。

即「发送邮件」后（成功发送）后立即返回，不需要等「修改库存」以及「通知经理」的结果，让它们异步去执行；

**好处三：削峰/限流**

假设我们的服务器最多能支持每秒 1000 个请求，而我们公司在节日要搞促销，为了避免服务器挂掉我们额外申请了两台服务器做了负载均衡，

![044aeca9c9c24c5587fe4feb25c76684.png][]

于是我们现在的机器最理想的情况能够支持每秒 3000 个请求，但奈何活动太火爆了，每秒来的请求有大概 4000 个，这些多出来的请求就可能导致服务器给直接挂掉了（可能是Tomcat线程、DUBBO线程、MYSQL连接、甚至是Redis）；

![6455667807534d72b1b77fbcbdfe394c.png][]

所以我们就引入了一个「消息队列」，让消息不直接到达服务器，而是先让「消息队列」保存这些数据，然后让下面的服务器每一次都取各自能处理的请求数再去处理，这样当请求数超过服务器最大负载时，就不至于把服务器搞挂了；

通过以上分析我们可以得出消**息队列具有很好的削峰作用**的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。

举例：在电子商务一些**秒杀、促销活动**中，**合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击**；

**异步入库需要注意的点？**

因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败；因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功；

常用的交互方案就是**请求提交后接口先返回，然后使用客户端轮询**，提示语"Xx正在处理中..."；使用轮询的时候也一定要做好服务端限流，不然服务端的tomcat线程会被打满；

在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功，以免交易纠纷，这就类似我们平时手机订火车票和电影票；

#### **4. 消息队列实际的应用场景** ####

**场景一：异步处理，但需要关注业务是否对消息的反馈敏感，如订单是否成功创建**

通过上述的问题你也看到了，「消息队列」适用于异步处理，并且是那些不期望立即从消费者得到反馈的处理；例如上面说到的设备坏了的问题，我只需要通知设备坏了，至于之后需要做什么事，关心的人自然会去做相应的处理；

消息队列本身是异步的，它允许接收者在消息发送一段时间后，再拉取消息做处理；

**场景二：日志收集，这个就不关系反馈结果了，直接异步发送日志信息就行（kafka）**

上面提到的异步处理，跟日志系统似乎搭配起来也很好；特别是当你需要把日志发往单独的数据平台的时候，「消息队列」尤为有用，我们不再需要在业务代码里面侵入我们的各种打点or日志，只需要简单的发布一条消息，再去关注做处理就好了；

**场景三：应用解耦，这个比较宏观**

基于上面的例子你应该也能感受一二了；消息队列减少了服务之间的耦合性，不同的服务可以通过消息队列进行通信，而不用关心彼此的实现细节；

**场景四：流量削峰，但是也要关注是仅仅延迟执行返回，还是异步执行，需要关注业务需求**

这也是「消息队列」常见的场景，通过引入「消息队列」，我们一来可以可以缓解短时间内高流量的压力；当上下游系统处理能力存在明显差距的时候，也利用消息队列做一个"暂存区"，在下游有能力处理的时候，再进消息拉取和处理；

**场景五：消息通讯，这个比较简单**

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯，比如实现点对点消息队列，或者聊天室等；

#### **5. 使用消息队列需要注意的点** ####

**最关心的点：消费者是否真正收到了消息，并且能得到消费者的反馈；**

另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上，等消息真正被消费者服务器处理后才删除消息；在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息；

**技术是把双刃剑**！使用他是因为他带给我们很多好处，但是使用之后问题也是接踵而至，总的来说，**使用消息队列可能带来的一些问题**：

**1**. **系统可用性降低**： 系统可用性在某种程度上降低，为什么这样说呢？在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！

**2**. **系统复杂性提高**： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！

**3**. **一致性问题**： 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!

#### **6. 常见的消息中间件？（暂时先了解一下即可）** ####

目前在市面上比较主流的消息队列中间件主要有，**Kafka、ActiveMQ、RabbitMQ、RocketMQ** 等这几种；

1. **ActiveMQ**

ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，**不推荐使用；**

2. **RabbitMQ**

RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以**并发能力很强**，**性能极其好，延时很低，达到微秒级**；

如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选；

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范；

3. **RocketMQ**

阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验；

还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ 挺好的；

4. **kafka**

kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展；

同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量；

kafka 唯一的一点**劣势**是有可能**消息重复消费**，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集；

这里放一张各个维度下每种消息中间件的比较图：

![f4a2a3e66d7e453b89cb03aa722c7b66.jpeg][]

从吞吐量来说，早期比较活跃的ActiveMQ和RabbitMQ基本上不是后两者的对手了，在现在这样大数据的年代吞吐量是真的很重要；

从部署方式上看，RocketMQ和Kafka都是高可用的分布式架构，而且数据多个副本的数据也能做到0丢失；

至于RabbitMQ这个中间件其实还行，我目前所在公司部分业务用的就是，不过目前已经在向RocketMQ迁移了；其中一个原因就是它的开发语言是erlang，开发维护成本很高；

而RocketMQ是阿里开源的，GIT活跃度还可以，纯Java开发，目前主流的消息中间件；而大数据业务，大部分都会使用Kafka，因为其高吞吐的特性；

参考：

[《面试官问我：什么是消息队列？什么场景需要他？用了会出现什么问题？》][Link 1]

[《字节跳动面试官这样问消息队列：分布式事务、重复消费、顺序消费，我整理了一下》][Link 2]

[d72edea5190340b4ae95c5867879abbc.png]: https://img-blog.csdnimg.cn/d72edea5190340b4ae95c5867879abbc.png
[9cbb640be0314d8eae2aafe57fbb5955.png]: https://img-blog.csdnimg.cn/9cbb640be0314d8eae2aafe57fbb5955.png
[24ad57ddb5ec48c38cda0dc0bda99f0d.png]: https://img-blog.csdnimg.cn/24ad57ddb5ec48c38cda0dc0bda99f0d.png
[044aeca9c9c24c5587fe4feb25c76684.png]: https://img-blog.csdnimg.cn/044aeca9c9c24c5587fe4feb25c76684.png
[6455667807534d72b1b77fbcbdfe394c.png]: https://img-blog.csdnimg.cn/6455667807534d72b1b77fbcbdfe394c.png
[f4a2a3e66d7e453b89cb03aa722c7b66.jpeg]: https://img-blog.csdnimg.cn/f4a2a3e66d7e453b89cb03aa722c7b66.jpeg
[Link 1]: https://blog.csdn.net/qq_35190492/article/details/103153444?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165814578716782395329934%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165814578716782395329934&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-103153444-null-null.185%5Ev2%5Econtrol&utm_term=%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97&spm=1018.2226.3001.4450
[Link 2]: https://blog.csdn.net/qq_35190492/article/details/103232854?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165814578716782395329934%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165814578716782395329934&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-2-103232854-null-null.185%5Ev2%5Econtrol&utm_term=%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97&spm=1018.2226.3001.4450