简单一篇文章，讲一下消息队列（Message Queue）是干什么的？

时间：2026-1-16 22:23 作者：独元殇 分类： 开发相关

[toc]

一句话说完就是，消息队列就是解决微服务架构的应用程序，各模块传递数据的杂七杂八的问题的！

（PS: 现在有了 AI 作图，做一些内容技术插图真好用)

今天用一个单线的讲述，把前 100 年讲一下：

首先，先说一下数据库。

就像 Postgres MongoDB MySQL 这种数据库，是用于持久储存数据的。

这个【消息队列】也差不多，也是存数据的。

其实可以这样来理解。

数据库和消息队列的区别？

对于第一个，数据库。它生来设计，就是容纳很多不同种类的物品的，比如数字、字母编号、秘钥、文章.... 而且一般是为了存放很久的。跟仓库一样。

对于第二个，消息队列。内容会短暂进行存储，但不会留很久，而是发放到它要去的地方。但也要保留足够长的时间，以便能稳定发送到下一个地点。就跟一个顺丰快递一样。

【消息队列】的核心本质就是这样：生产者和顾客之间的一个传输媒介，一个中介。生产者生产 messages 消息，顾客接收。

生产者和顾客之间，会通过消息队列协议，也就是 STOMP、AMQP、MQTT 这类这样工作。

一般我们很喜欢在微服务架构（microservices）里各个系统间的通信里使用这个消息队列协议。

先说一下最原始的 monolith application ，我们国内常翻译其为单体架构。

单体架构是指整个代码库都包含在一个应用程序里。小项目一般都这样，本身也没多少代码嘛.....

都放到一个程序里，那必然开发、测试、部署都容易。

但程序一直开发迭代，架构会出现很多问题。即便采用了模块、结构，将其拆分的很细..... 依然止不住代码变得混乱。尤其是 bug，出现一点 bug ，就可能牵一发动全身！

于是就引入了微服务，将单一的多功能大应用，拆分成几个小应用。每个小应用，只干它自己的事！

其中最显著的优点，就是 bug 隔离，书面化语言就是故障隔离机制。不会一个小 bug 把整个系统弄宕机了。

第二个优点，就是你各管各的，跟电路板电子一样，使用不同的技术栈、做各种乱七八糟的优化。尤其也提现在扩容上，应用跑通了，发小财了，扩容就容易了，只需要根据需要扩充某部分就行。

我们的主题，消息队列，就天然适合微服务之间的数据通信！

说一下微服务之间原来最常用的通信方式：

同步通信：也就是最常用的 REST API 接口风格，用 xml json 调来调去。但你要注意，是同步的。如果中间出现 bug，程序会翻车。

而今天这个消息队列是异步的，A 给 B 送了一个「顺丰快递包裹」，无需等待回应，直接会从顺丰那里得到一个简单的回执，然后就该干啥就干啥，默认 B 已经收到了，不管了。

消息队列的另一个好处是，即便任务激增，消息队列内部也会有缓存机制，是一个专业的消息传递服务，能防止你的服务器过载，会慢慢根据性能，将消息一一传递出去。

总之，消息队列就是一个专业的干传递信息、内容的程序。

毕竟，之前那种什么 json 那种，太简陋了。一出 bug 就宕了。