springCloud-Alibaba——常用MQ消息中间件简介

最新推荐文章于 2025-03-03 12:18:34 发布

LSY_csdn_

最新推荐文章于 2025-03-03 12:18:34 发布

阅读量2.1k

点赞数 1

分类专栏： springCloud-Alibaba 文章标签： MQ

本文链接：https://blog.csdn.net/LSY_CSDN_/article/details/105177431

版权

springCloud-Alibaba 专栏收录该内容

31 篇文章

订阅专栏

一、简述：

消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。

消息队列主要解决了应用耦合、异步处理、流量削锋等问题。

二、应用场景：

1、应用耦合：

多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；

2、应用耦合实例：

具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。

串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信；

并行处理：新注册信息写入后，由发短信和发邮件并行处理；

若使用消息队列：并在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍；

3、异步处理：

多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；

4、异步处理实例：

具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功：

若使用消息队列：客户端上传图片后，图片上传系统将图片信息如uin、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。

5、限流削峰：

广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；

6、限流削峰实例：

具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。而加入消息队列后，系统可以从消息队列中取数据，相当于消息队列做了一次缓冲。

7、消息驱动的系统：

系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；

8、消息驱动系统实例：

具体场景：用户新上传了一批照片，人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。

三、两种模式：

1、点对点模式：

（1）角色：

消息队列、发送者 (生产者)、接收者（消费者）

消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

（2）特点：

每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；

发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；

接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；

2、发布/订阅模式：

（1）角色：

角色主题（Topic）、发布者(Publisher)、订阅者(Subscriber)

发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

（2）特点：

每个消息可以有多个订阅者；

发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。

为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

四、常用消息队列：

1、RabbitMQ：

（1）简介：

RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

（2）特性：

可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；

灵活的路由：消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；

消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；

队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；

多种协议的支持：支持多种消息队列协议；

服务器端用Erlang语言编写，支持只要是你能想到的所有编程语言；

管理界面: RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；

跟踪机制：如果消息异常，RabbitMQ提供消息跟踪机制，使用者可以找出发生了什么；

插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；

（3）使用需要：

使用RabbitMQ需要ErLang语言包、RabbitMQ安装包。

（4）运行平台：

RabbitMQ可以运行在Erlang语言所支持的平台之上：Solaris、BSD、Linux、MacOSX、TRU64、Windows NT/2000/XP/Vista/Windows 7/Windows 8、Windows Server 2003/2008/2012、Windows 95, 98、VxWorks

（5）优点：

由于erlang语言的特性，mq 性能较好，高并发；

健壮、稳定、易用、跨平台、支持多种语言、文档齐全；

有消息确认机制和持久化机制，可靠性高；

高度可定制的路由；

管理界面较丰富，在互联网公司也有较大规模的应用；

社区活跃度高；

（6）缺点：

尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；

实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；

需要学习比较复杂的接口和协议，学习和维护成本较高；

2、RocketMQ：

（1）简介：

RocketMQ出自阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

（2）特性：

是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；

Producer、Consumer、队列都可以分布式；

Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合；

能够保证严格的消息顺序；

提供丰富的消息拉取模式；

高效的订阅者水平扩展能力；

实时的消息订阅机制；

亿级消息堆积能力；

较少的依赖；

（3）使用需要：

使用RocketMQ需要：Java JDK、安装git或Maven、RocketMQ安装包

（4）运行平台：

RocketMQ可以运行在Java语言所支持的平台之上。

（5）优点：

单机支持 1 万以上持久化队列

RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，

访问时，直接从内存读取。

模型简单，接口易用（JMS 的接口很多场合并不太实用）；

性能非常好，可以大量堆积消息在broker中；

支持多种消费，包括集群消费、广播消费等。

各个环节分布式扩展设计，主从HA；

开发度较活跃，版本更新很快。

（6）缺点：

支持的客户端语言不多，目前是java及c++，其中c++不成熟；

RocketMQ社区关注度及成熟度也不及前两者；

没有web管理界面，提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题；

没有在 mq 核心中去实现JMS等接口；

3、Kafka：

（1）简介：

Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。