一、什么是MQ(Message Queue 消息队列)
1.1 定义
MQ(Message Queue,消息队列)是一种用于在应用程序之间传递消息的通信模式。它通过将消息发送到一个中间件(消息队列)中,然后由接收方从队列中获取并处理消息。消息队列可以实现异步通信,解耦,削峰。填谷等功能,提高系统的可伸缩性和可靠性。
1.2 MQ的基本工作原理
- 消息生产者将消息发送到消息队列,通常使用一定的协议或API进行通信。
- 消息队列接收并存储消息,并确保消息的可靠性和持久性。
- 消息消费者从消息队列中获取并处理消息,通常使用轮询或订阅的方式进行获取。
1.3 MQ的特点及注意事项
- 先进先出:消息队列的顺序一般在入列时就基本确定了,最先到达消息队列的信息,一般情况下也会先转发给订阅的消费者,我们把这种实现了先进先出的数据结构称之为队列。
- 发布、订阅工作模式:生产者也就是消息的创建者,负责创建和推送数据到消息服务器;消费者也就是消息的接收方,用于处理数据和确认消息的消费;消息队列也是MQ服务器中最重要的组成元素之一,它负责消息的存储,这三者是MQ中的三个重要角色。而它们之间的消息传递与转发都是通过发布以及订阅的工作模式来进行的,即生产者把消息推送到消息队列,消费者订阅到相关的消息后进行消费,在消息非阻塞的情况下,此模式基本可以实现同步操作的效果。并且此种工作模式会把请求的压力转移给MQ服务器,以减少了应用服务器本身的并发压力。
- 持久化:持久化是把消息从内存存储到磁盘的过程,并且在服务器重启或者发生宕机的情况下,重新启动服务器之后是保证数据不会丢失的一种手段,也是目前主流MQ中间件都会提供的重要功能。
- 分布式:MQ的一个主要特性就是要应对大流量、大数据的高并发环境,一个单体的MQ服务器是很难应对这种高并发的压力的,所以MQ服务器都会支持分布式应用的部署,以分摊和降低高并发对MQ系统的冲击。
- 消息确认:消息消费确认是程序稳定性和安全性的一个重要考核指标,假如消费者在拿到消息之后突然宕机了,那么MQ服务器会误认为此消息已经被消费者消费了,从而造成消息丢失的问题,而目前市面上的主流MQ都实现了消息确认的功能,保证了消息不会丢失,从而保证了系统的稳定性。
常用的 MQ中间件有 RabbitMQ、RocketMQ、Kafka和 Redis等,其中 Redis属于轻量级的消息队列,而 RabbitMQ、RocketMQ、Kafka属于比较成熟且比较稳定和高效的MQ中间件。
二、三大作用
2.1 解耦
2.1.1 定义
解耦是指通过消息队列将系统的不同组件或服务分离,使它们之间不直接依赖,从而降低系统的耦合性。
2.1.2 作用
- 提高系统灵活性:服务之间通过消息队列传递信息,不再需要直接调用对方接口,可以独立开发、部署和扩展。
- 增强系统稳定性:即使某个服务宕机,其他服务仍可通过消息队列继续工作,不会直接受到影响。
- 简化系统设计:服务只需关注自身的业务逻辑,无需关心其他服务的状态或接口变化。
2.1.3 应用场景
- 电商场景:用户下单后,订单系统将订单信息发送到消息队列,库存系统从队列中获取消息并处理库存更新。这样,订单系统和库存系统无需直接交互,实现了解耦。
2.2 异步处理(Asynchronous Processing)
2.2.1 定义
异步处理是指将耗时的操作放入消息队列中,由后台服务异步执行,从而不阻塞主线程或用户操作。
2.2.2 作用
- 提升用户体验:用户请求可以快速返回,耗时的任务在后台处理,减少等待时间。
- 提高系统吞吐量:系统可以同时处理多个任务,充分利用资源。
- 简化并发控制:将复杂的并发逻辑交给消息队列管理,降低开发难度。
2.2.3 应用场景
- 用户注册:用户注册后,系统将发送注册邮件和短信的任务放入消息队列,主线程立即返回注册成功信息,邮件和短信的发送由后台异步完成。
- 日志记录:
同步操作: 用户请求 -> 日志记录 -> 响应用户。用户需要等待日志记录完成才能获得响应,耗时较长。
异步操作: 用户请求 -> 响应用户 -> 日志记录。用户请求和日志记录分离,用户快速获得响应,日志记录在后台进行。
由于运营人员和经营人员需要拿到用户操作的日志信息,进行用户行为分析或者行为监控。如果不使用消息队列,前台用户需要等待日志添加完成后才能拿到相应信息。使用消息队列,响应完用户请求之后,只需要把这个操作信息放入消息队列,前台用户可以直接拿到响应,无需等待日志处理和日志添加完成,从而缩短前台用户等待时间。
2.3 削峰(Peak Shaving)
2.3.1 定义
削峰是指通过消息队列缓冲瞬时高流量,避免系统因短时请求激增而崩溃。
2.3.2 作用
- 保护系统稳定性:在高并发场景下,消息队列可以暂存请求,平滑流量,防止系统过载。
- 提升资源利用率:系统可以按照实际处理能力逐步处理请求,避免资源浪费。
- 应对突发流量:在促销活动等流量高峰期,削峰机制尤为重要。
2.3.3 应用场景
- 电商秒杀活动:活动开始时,大量用户同时下单,系统将订单请求暂存到消息队列中,然后逐步处理,避免数据库或服务器因瞬时高流量而崩溃。
2.4 综合场景
2.4.1聊天室
1. 异步处理(主要作用)
原理:
在聊天室场景中,用户的消息发送和接收是异步进行的。用户发送消息后,消息不会直接推送给所有接收者,而是先进入消息队列。服务器从队列中取出消息,再转发给目标用户或聊天室成员。
优势:
- 实时性保障:用户发送消息后无需等待服务器处理,可以立即返回继续操作,提升用户体验。
- 高并发支持:聊天室可能同时有大量用户发送消息,消息队列可以缓冲这些请求,服务器逐个处理,避免系统过载。
- 灵活性:支持离线消息处理。用户离线时,消息存储在队列中,用户上线后再进行转发。
示例:
- 用户A发送消息到聊天室,消息进入队列 → 服务器从队列中获取消息 → 服务器将消息转发给在线的聊天室成员(用户B、C等)。
2. 解耦(次要作用)
原理:
聊天室通过消息队列将消息发送者与接收者解耦。发送者只需将消息发送到队列,无需关心接收者的状态或处理逻辑。
优势:
- 系统稳定性:即使部分接收者离线或处理缓慢,不会影响发送者的操作。
- 可扩展性:聊天室可以独立扩展消息发送服务和消息处理服务,互不干扰。
示例:
- 用户A发送消息时,只与消息队列交互 → 服务器负责将队列中的消息分发给用户B、C等,用户A与B、C之间无直接依赖。
3. 削峰(潜在作用)
虽然聊天室的日常使用中削峰需求不明显,但在特定场景下仍可能发挥作用,例如:
- 突发高流量:在特定事件(如明星直播、重大新闻发布)时,聊天室用户量激增,消息队列可以缓冲瞬时高流量,避免服务器崩溃。
- 活动营销:聊天室举办活动时,用户互动频繁,削峰机制可以保护系统稳定运行。
2297

被折叠的 条评论
为什么被折叠?



