【MQ核心概念理解】

一、MQ介绍

ChatGPT中对于消息队列的介绍是这样的：

MQ：MessageQueue，消息队列。这东西分两个部分来理解：队列，是一种FIFO 先进先出的数据结构。

消息：在不同应用程序之间传递的数据。将消息以队列的形式存储起来，并且在不同的应用程序之间进行传

递，这就成了MessageQueue。而MQ的作用，从刚才ChatGPT的介绍中就能够抽象出三个关键字：异步、

解耦、削峰。但是这什么意思呢？跟开发有什么关系？我们从一个简单的SpringBoot应用开始说起。

首先搭建一个普通的Maven项目，在pom.xml中引入SpringBoot的依赖：

1、SpringBoot应用和监控服务应该是解耦的。不管有没有监控服务，SpringBoot应用都要是可以正常运行

的。同时，不管监控服务是用什么语言开发的，同样不应该影响SpringBoot应用的正常运行。更进一步，不

管监控服务要部署多少个，同样也不应该影响SpringBoot应用的正常运行。反过来，从监控服务看

SpringBoot应用也应该是一样的。这就需要这个中间服务可以提供不同语言的客户端，通过不同客户端让消

息生产者和消息消费者之间彻底解耦。

2、SpringBoot应用和监控服务之间处理消息应该是异步的。基于解耦的关系，SpringBoot应用并不需要知

道监控服务有没有运行。所以他并不需要将消息直接发送到监控服务，也不需要保证消息一定会被监控服务

处理。他只要将消息发到中间服务就可以了。而监控服务可以在SpringBoot应用发布了时间之后，随时去接

收处理这些消息。

3、这个中间服务需要可以协调双方的事件处理速度，产生削峰填谷的效果。监控服务一般都是希望每五分

钟接收到SpringBoot发布过来的消息，然后进行一次统计，但是SpringBoot应用发布的事件频率却是不确定

的。如果SpringBoot应用在五分钟内产生了海量的消息，就有可能让监控服务内存撑爆，处理不过来。而监

控服务如果加大内存，SpringBoot应用又有可能在五分钟内根本没有消息，监控服务的内存就白加了。监控

服务的内存配大配小都不合适。这时候，就需要这个中间服务能够这些消息暂存起来，让监控服务可以按照

自己的能力慢慢处理问题。这就是中间服务的削峰填谷的作用。

这时候你可能在想，SpringBoot已经提供了本地的事件驱动支持。那么我是不是给SpringBoot应用加上

一些web接口，基于这些web接口不就可以将本地的这些系统事件以及自己产生的这些事件往外部应用推

送，那这不就成了一个MQ服务了吗？单其实上面列出了MQ的的很多优点。但是在具体使用MQ时，也会带

来很多的缺点：

系统可用性降低