消息队列(MQ)

Posted 2021-04-26 后端初学者

每天一篇好文章系列18年第235期

编者按

在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达mysql，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。

1

一、MQ相关概念

1.消息(Message)

消息是MQ中最小的概念，本质上就是一段数据，它能被一个或者多个应用程序所理解，是应用程序之间传递的信息载体。

2.队列(Queue）

2.1本地队列

本地队列按照功能可划分为初始化队列，传输队列，目标队列和死信队列。

初始化队列用作消息触发功能。

传输队列只是暂存待传的消息，条件许可的情况下，通过管道将消息传送到其他的队列管理器。

目标队列是消息的目的地，可以长期存放消息。

如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。

2.2别名队列&远程队列

只是一个队列定义，用来指定远端队列管理器的队列。使用了远程队列，程序就不需要知道目标队列的位置。

2.3模型队列

模型队列定义了一套本地队列的属性结合，一旦打开模型队列，队列管理器会按照这些属性动态地创建出一个本地队列。

3.队列管理器(Queue Manager)

队列管理器是一个负责向应用程序提供消息服务的机构，如果把队列管理器比作数据库，那么队列就是其中一张表。

4.通道(Channel)

通道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。

2

二、MQ产品特性

1.可靠性传输

这个特点可以说是消息中间件的立足之本，对于应用来说，只要成功把数据提交给消息中间件，那么关于数据可靠传输的问题就由消息中间件来负责。

2.不重复传输

不重复传播也就是断点续传的功能，特别适合网络不稳定的环境，节约网络资源。

3.异步性传输

异步性传输是指，接受信息双方不必同时在线，具有脱机能力和安全性。

4.消息驱动

接到消息后主动通知消息接收方。

5.支持事务

应用程序可以把一些数据更新组合成一个工作单元，这些更新通常是逻辑相关的，为了保障数据完整性，所有的更新必须同时成功或者同时失败）。

3

三、MQ应用场景(发布-订阅消息模式)

通过传统调用模式演化到发布-订阅消息模式来理解。

有些网站在注册用户成功后发一封激活邮件，用户收到邮件后点击激活链接后才能使用该网站。一般的做法是在注册用户业务逻辑中调用发送邮件的逻辑。这 样用户业务就依赖于邮件业务。如果以后改为短信激活，注册用户业务逻辑就必须修改为调用发送短信的逻辑。如果要注册后给用户加点积分，再加一段逻辑。经过 多次修改，我们发现很简单的注册用户业务已经越来越复杂，越来越难以维护。相信很多开发者都会有类似痛苦的经历。

即使用户业务实现中对其他业务是接口依赖，也避免不了业务变化带来的依赖影响。怎么办？解耦！将注册用户业务逻辑中注册成功后的处理剥离出来。
再回头看看"订阅杂志"，如果没有邮局，出版社就必须自己将杂志送达所有消费者。这种情形就和现在的注册用户业务一样。我们发现问题了，在用户业务和其他业务之间缺少了邮局所扮角色。
我们把邮局抽象成一个管理消息的地方，叫"消息管理器"。注册用户成功后发送一个消息给消息管理器，由消息管理器转发该消息给需要处理的业务。现在，用户业务只依赖于消息管理器了，它再也不会为了注册用户成功后的其他处理而烦恼。

注册用户的改造就是借鉴了"订阅杂志"这样原始的模式。我们再进一步抽象，用户业务就是消息的"生产者"，它将消息发布到消息管理器。邮件业务就是 消息的"消费者"，它将收到的消息进行处理。邮局可以订阅很多种杂志，杂志都是通过某种编号来区分；消息管理器也可以管理多种消息，每种消息都会有一个 "主题"来区分，消费者都是通过主题来订阅的。

发布-订阅消息模式已经呈现在我们面前，利用它可以产生更灵活、更松散耦合的系统。

点评：这篇文章主要介绍了消息队列的相关概念，以及MQ的特性和作用，具体的MQ的应用场景以及特性讲解还有很多，这里只是一个概括，大家可以再去多找些资料深入了解，这样的效果会更好。

本文转自

 城市里的最后一个农民---CSDN

《消息队列原理》

      想要了解更多信息可以持续关注本公众号，每天一篇好文章，助你早日变成一 名合格的程序猿~

相关阅读推荐

深入了解请点击下方阅读原文