前言

从今天起，席卷北国的雪，持续了一整天，北京也不例外。这场意外的寒潮，把整个冬天渲染的格外cool。当然你可以在外面打雪仗、堆雪人、拉雪橇，也可以静坐屋内，来一场围炉煮茶的party。此刻，冬天带来的温暖与喜乐不言而喻。
当然烦恼也充斥其中：稍不留神，容易翻跟头。所以，博主先给各位盆友送一句话：雪天路滑，小心脚下。

好了，我们言归正传。上一篇，博主给大家介绍了两个人如何建立通信、如何保障通信的成功以及完成通信所需的工具。当然系统本身是对物理世界的模拟实现，所以系统与系统之间、服务与服务之间，也遵循此逻辑。

各位盆友，此刻可以回想一下，我们正在开发的不管什么系统、模块、服务，本质都是建立在通信的基础上而完成的。那么如何通信是我们绕不开的话题，微服务尤甚。

今天博主为大家介绍一个新“朋友”：MQ，因为它在“通信界”真的太重要了。

---

• 微服务实战系列之通信
• 微服务实战系列之J2Cache
• 微服务实战系列之Cache（技巧篇）
• 微服务实战系列之MemCache
• 微服务实战系列之EhCache
• 微服务实战系列之Redis
• 微服务实战系列之Cache
• 微服务实战系列之Nginx（技巧篇）
• 微服务实战系列之Nginx
• 微服务实战系列之Feign
• 微服务实战系列之Sentinel
• 微服务实战系列之Token
• 微服务实战系列之Nacos
• 微服务实战系列之Gateway
• 微服务实战系列之加密RSA
• 微服务实战系列之签名Sign

---

MQ_31">一、 MQ简介

“消息队列”是 Microsoft 的消息处理技术，它在任何安装 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。——来自百度百科

怎么理解上面这段话？博主总结为3个关键词：“跨网络、跨平台、跨服务”。
这么优质的消息处理技术，用它做数据传递，再好不过了。我们不需要关心对方是否联机在线、是否Java或.NET，是否Window或Linux，只需两端都接入同一个MQ，剩下的由它完成就好了。

通过上图经典的MQ模型，我们可以观察到MQ的两端，一个是生产者（简称P），一个是消费者（简称C）。就好比一个卖家，一个买家，那么MQ就是销售渠道。

二、应用场景

那它有哪些主要的应用场景呢？

1. 异步

什么是异步？
博主的上一篇文章 微服务实战系列之通信 已进行说明，如需回看请速戳。

比如经典的订单系统，有库存、有物流、有产品、有订单等模块，那么如何做到功能的“快、好、省”呢？ 有同学说了，并发呗。

并发是解决性能的必备手段，但是如何使用并发以及并发能够为我们带来什么，是必须思考的问题。此刻，MQ可以胜任，选择它，我们可以同时具备接入多个“消费者”。一个一个消费总比不过同时消费吧？

2. 解耦

软件架构中，有一句至理名言：“高内聚、低耦合”。我想各位盆友都比较熟悉了吧？MQ为什么可以做到解耦，因为它具备 “3跨”的特点。

举个栗子，我们在做单体服务开发时，模块太多耦合太紧，极容易造成系统间“一损俱损”的局面。

此刻，我们让MQ作为中介，驾起这座桥梁，烦恼就少多了。即使其中一个系统（比如物流系统）宕机了，也就随它去吧，不至于胆战心惊一整天，两手空空手足无措。

3. 防并发

为什么需要防并发？当然是基于成本和资源的可用性考虑。一块内存、一个服务器、甚至一个数据库，不管配置多高，总有个上限。

在某些高并发场景，我们既要满足用户的大量参与，又需要保障服务的安全和可靠，怎么办？如果此时不考虑并发，最大的可能性就是TPS下降了、RS上升了，直觉就是系统宕机了。

所以，在有限资源的情况下，避免并发（或有限并发）是永恒的话题。MQ迎难而上，也顺势成为最佳工具之一。

三、工具选择

目前主流的MQ，既有开源产品，又有商业产品，大致比较如下：

这是前辈们总结的各家MQ的优势和胜任的场景，各位盆友可以借鉴。

---

结语

MQ（消息队列）是一个消息传递的工具，而消息本身可以是日志、数据、文件等等形式。当我们开发中，如果遇到上述场景时，可以适当选择MQ作为解耦或者消息的中介。当然只要是工具，必然存在天然的劣势。比如多了一个Node，微服务链自然又延长了，如此容易让服务变得更复杂，运维代价随之上升。

所以，凡事总有好坏之分，我们只好扬长避短，才能化工具为己用，真正能够为自己带来新的技术突破。

好了，今日文章至此，该说byebye了，我们下次接着聊~