其实字面意思很清楚了，存放消息的队列。
由于它的应用场景在服务器方面被重新定义而名声大噪，它的价值也被由原先的通信而重新定义，成为高并发场景下，分布式系统解耦合，任务异步，流量削峰的利器。

其实消息队列属于一种中间件。

MQ（message queue）：面向消息的中间件（message-oriented middleware）是指利用高效可靠的消息传递机制与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。

通过提供消息传递和消息排队模型在分布式环境下提供应用解耦，弹性伸缩，冗余存储、流量削峰，异步通信，数据同步等功能。

发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题topic中，在合适的时候，消息服务器回将消息转发给接受者。在这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接受者的生命周期也没有必然的关系；尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者。

解耦合

• 传统做法

  - 传统的做法是，订单系统调用库存系统的接口。如下图：

 - 传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合

如何解决以上问题呢？

• 使用消息队列

  - 引入应用消息队列后的方案，如下图：

• 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
• 库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
• 在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦.

举个新例子：

比如说某一个系统A要与其他系统打交道（即调用其中的方法），如果其它系统改变或者新增系统，那么A系统都会改变，这样的话耦合度比较高，比较麻烦。

使用消息队列来解决这个问题。

我们A系统将产生的数据发入消息队列中，其它的系统再去消息队列来进行消费，那么其他系统的减少或者新增系统即与A系统关系不大了，这样来实现解耦的功能。

异步

场景说明：用户注册后，需要发注册邮件和注册短信

• 传统做法

  - 串行：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信

- 并行：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信

其实让我想我也就只能想到并行。

• 使用消息队列

  • 将不是必须的业务逻辑，异步处理。改造后的架构如下：

举个新例子

某一个用户使用系统A，但是A要调用系统B,C,D,但是每一个系统返回的时间是不一样的，你必须要等待全部返回后才可以响应用户。

如果我们这里采用消息队列，当用户发送请求后，我们把数据传给消息队列，然后再直接响应给用户我已经发送了信息。

流量削峰

场景说明：商品秒杀业务，一般会因为流量过大，导致流量暴增，应用挂掉

• 传统做法

  - 限制用户数量
  

• 使用消息队列

  - 用户的请求，服务器接收后，首先写入消息队列，秒杀业务

---

举个新例子