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

目录

• 数据库 和 消息队列 的区别？
• 那 消息队列 怎么工作呢？
• 微服务架构是什么？
• 同步通信的弊端？

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

本文完整版原文地址： https://www.ccgxk.com/emlog_dev/621.html

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

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

首先，先说一下数据库。

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

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

其实可以这样来理解。

1. 数据库 是 一个仓库。
2. 消息队列 是 一个顺丰快递公司。专业用于传递数据！

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

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

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

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

那 消息队列 怎么工作呢？

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

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

微服务架构是什么？

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

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

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

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

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

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

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

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

同步通信的弊端？

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

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

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

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

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

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