消息队列(mq)是啥?

Posted 2023-03-22

是生产者先将消息投递一个叫队列的容器中，然后再从这个容器中取出消息，最后再转发给消费者。

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

消息队列网络是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。

消息队列的类型介绍：

消息队列目前主要有两种类型：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息。包括消息队列键值、用户ID、组ID、消息队列中消息数目等等。

消息队列就是一个消息的链表，可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。

参考技术A

消息队列就是基础数据结构中的“先进先出”的一种数据机构。想一下，生活中买东西，需要排队，先排的人先买消费，就是典型的“先进先出”。

MQ是一直存在，不过随着微服务架构的流行，成了解决微服务之间问题的常用工具。

主流的消息队列MQ比较，特征，以及典型使用场景。

1.ZeroMQ

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。

扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

2.RabbitMQ

结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。

性能较好，但是不利于做二次开发和维护。

3.ActiveMQ

历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。

4.Redis

做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。

参考技术B

MQ全称为Message Queue，即消息队列，是一种跨进程的通信机制，用于上下游传递消息。

使用mq的原因：

1. 实现分布式系统之间的解耦调用

在分布式系统中,经常会出现一个服务会有多个消费端调用,而且可能每个消费方需要接入的逻辑不一致,又或者随着项目的不断发展,我们需要接口的未来维护和发展确定一套可扩展的规范，引入消息系统,在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2. 实现异步调用

有时候我们会遇到这样的场景，用户在客户端提交了一个请求，后端处理这个请求的业务相对比较复杂，如果这个请求使用的是同步调用，客户端就会出现发送请求后过了很久才相应的情况，这对用户体验来说是十分致命的。如果说用户并不关心请求是否处理，对于一些耗时的非事务性的业务处理，我们可以使用mq异步请求的方式，将处理信息放入队列,由后端监听队列自行处理，在将消息存入队列后直接返回客户端相应，加快响应速度。

3. 削峰(队列),解决高并发问题

例如秒杀活动，可能在短时间内会有很大请求同时到后端，如果后端对每个请求都执行业务操作，例如查询数据库和写数据库，会造成服务器压力过大，同时，在同一时间进行大量数据库操作，可能会出现数据异常，我们可以使用mq实现缓冲，将所有请求先放入消息队列中，服务端每次处理业务先从消息队列获取。

消息队列MQ是啥玩意

消息队列MQ

推荐blog：

之前一直也没有学习过这方面的知识，直到项目中用到才决定学习一下 https://www.jianshu.com/p/36a7775b04ec https://www.cnblogs.com/rjzheng/

1. 为什么要使用消息队列?

MQ(Message Queue)顾名思义就是消息队列。打个比方去快餐店点餐，每个人点餐可能只要10s，但如果三个人同时向服务员点餐，服务员就可能会乱了，三个顾客还可能会吵起来，这件事就没法30s内解决，那么很简单，排队点餐就好办了。所以MQ最核心的功能就是削峰蓄洪。其他特征则是围绕这一功能衍生出来的。

1. 比如如何维持排队的人不乱套（持久化和重发和事务支持）

2. 如何容纳更多的人排队（堆积能力）

3. 如果实在接待不了这么多人怎样让后来的人去其他地方安置（限流机制）等等。

最主要的应用场景即以下六个字:解耦、异步、削峰。

---

①：解耦

传统模式:传统模式的缺点：系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

中间件模式:

中间件模式的的优点：将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

---

②：异步

传统模式:传统模式的缺点：一些非必要的业务逻辑以同步的方式运行，太耗费时间。

中间件模式:

中间件模式的的优点：将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度

---

③：削峰

传统模式：

传统模式的缺点：并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

中间件模式:

中间件模式的的优点：系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

---

消息队列缺点?

• 系统可用性降低：你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统也就完蛋了。因此，系统可用性降低

• 系统复杂性增加：要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

特性	开发语言	单机吞吐量	时效性	可用性	功能特性
ActiveMQ	java	万级	ms级	高(主从架构)	成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好
RabbitMQ	erlang	万级	us级	高(主从架构)	基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富
RocketMQ	java	十万级	ms级	非常高(分布式架构)	MQ功能比较完备，扩展性佳
kafka	scala	十万级	ms级以内	非常高(分布式架构)	只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。

综合上面的材料得出以下两点:

1. 中小型软件公司，建议选RabbitMQ。

• erlang语言天生具备高并发的特性，管理界面用起来十分方便。

• 但是缺少能定制化开发erlang的程序员。

不考虑rocketmq和kafka的原因：

• 中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除不考虑。

• rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司抽不出人来进行rocketmq的定制化开发，因此不推荐。

1. 大型软件公司，根据具体使用在rocketMq和kafka之间二选一。

• rocketMQ，大型软件公司可以抽出人手对rocketMQ进行定制化开发。

• kafka，根据业务场景选择，如果有日志采集功能，肯定首选kafka。

文：呼卓宇

排版：呼卓宇

更多精彩内容

请长按扫描二维码