消息队列常见的 5 个应用场景

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题,实现高性能、高可用、可伸缩和最终一致性架构,使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。

消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景:异步处理,应用解耦,流量削锋和消息通讯四个场景。

1、异步处理

场景说明:用户注册后,需要发注册邮件和注册短信,传统的做法有两种:串行的方式和并行方式。

串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信,以上三个任务全部完成后,返回给客户。
在这里插入图片描述
并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信,以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。
在这里插入图片描述
假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒,并行的时间可能是100毫秒。

因为CPU在单位时间内处理的请求数是一定的,假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)。

小结:如以上案例描述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈,如何解决这个问题呢?

引入消息队列,将不是必须的业务逻辑,异步处理,改造后的架构如下:
在这里插入图片描述
按照以上约定,用户的响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。因此架构改变后,系统的吞吐量提高到每秒20QPS。比串行提高了3倍,比并行提高了两倍!

2、应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图:
在这里插入图片描述
传统模式的缺点

假如库存系统无法访问,则订单减库存将失败,从而导致订单失败,订单系统与库存系统耦合。

如何解决以上问题呢?引入应用消息队列后的方案,如下图:
在这里插入图片描述
订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功

库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作

假如:在下单时库存系统不能正常使用。也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

3、流量削锋

流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛!

应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。

可以控制活动的人数,可以缓解短时间内高流量压垮应用。
在这里插入图片描述
用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。

秒杀业务根据消息队列中的请求信息,再做后续处理。

4、日志处理

日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。架构简化如下:
在这里插入图片描述
日志采集客户端,负责日志数据采集,定时写受写入Kafka队列;Kafka消息队列,负责日志数据的接收,存储和转发;日志处理应用:订阅并消费kafka队列中的日志数据。

以下是新浪kafka日志处理应用案例:
在这里插入图片描述
Kafka:接收用户日志的消息队列;

Logstash:做日志解析,统一成JSON输出给Elasticsearch;

Elasticsearch:实时日志分析服务的核心技术,一个schemaless,实时的数据存储服务,通过index组织数据,兼具强大的搜索和统计功能;

Kibana:基于Elasticsearch的数据可视化组件,超强的数据可视化能力是众多公司选择ELK stack的重要原因。

5、消息通讯

消息通讯是指,消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯,比如实现点对点消息队列,或者聊天室等。

点对点通讯
在这里插入图片描述
客户端A和客户端B使用同一队列,进行消息通讯。

聊天室通讯
在这里插入图片描述
客户端A,客户端B,客户端N订阅同一主题,进行消息发布和接收。实现类似聊天室效果。

以上实际是消息队列的两种消息模式,点对点或发布订阅模式。模型为示意图,供参考。

除了这些,针对当前互联网公司的技术需求以及结合主流技术,我自己整理了一套系统的架构技术体系,当你技术过硬的时候,能够解决技术问题才会服众。不少公司都很重视高并发高可用的技术,特别是一线互联网公司,分布式、JVM、spring源码分析、微服务等知识点已是面试的必考题,这些东西可能你们平时在工作中接触过,但是缺少的全面系统的学习,加入后端开发群:943918498,或是关注微信公众号:Java资讯库,回复“架构”,免费领取架构资料。

消息中间件示例

1、电商系统
在这里插入图片描述
消息队列采用高可用,可持久化的消息中间件,比如Active MQ,Rabbit MQ,Rocket Mq。

应用将主干逻辑处理完成后,写入消息队列,消息发送是否成功可以开启消息的确认模式。(消息队列返回消息接收成功状态后,应用再返回,这样保障消息的完整性);

扩展流程(发短信,配送处理)订阅队列消息。采用推或拉的方式获取消息并处理;

消息将应用解耦的同时,带来了数据一致性问题,可以采用最终一致性方式解决。比如主数据写入数据库,扩展应用根据消息队列,并结合数据库方式实现基于消息队列的后续处理;

2、日志收集系统
在这里插入图片描述
分为Zookeeper注册中心,日志收集客户端,Kafka集群和Storm集群(OtherApp)四部分组成。

1.Zookeeper注册中心,提出负载均衡和地址查找服务;

2.日志收集客户端,用于采集应用系统的日志,并将数据推送到kafka队列;

3.Kafka集群:接收,路由,存储,转发等消息处理;

4.Storm集群:与OtherApp处于同一级别,采用拉的方式消费队列中的数据;

<think>首先,用户的问题是:“我想了解消息队列的适用场景和应用情况 请问消息队列的使用场景和适用情况”。这基于之前的引用内容,我需要参考这些引用来回答。 引用内容总结: - [^1]: 介绍了消息队列的基本使用场景,核心是异步处理和解耦能力。对比了RabbitMQ和Kafka。 - [^2]: 描述了消息队列的高可用性和持久化,如Active MQ、Rabbit MQ、Rocket MQ。提到应用将逻辑处理后写入队列,确保消息完整性。 - [^3]: 解释了P2P模式,包括队列、发送者、接收者角色。 - [^4]: 举例说明使用MQ减少响应时间,A系统发送消息到MQ,用户感知响应快。 - [^5]: 详细列出了消息队列的四大好处:解耦、提速、广播、削峰,以及使用条件和成本。 系统级指令: - 所有行内数学表达式必须使用$...$格式。 - 独立公式使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 - 回答结构清晰,帮助用户逐步解决问题。 - 引用站内引用,并在末尾添加引用标识。 用户问题不涉及数学表达式,所以可能不需要LaTeX数学格式。但为了遵守指令,如果有相关数学,我会处理。这里主要是概念性的,所以可能不需要数学公式。 回答结构: 1. **理解问题**:用户想知道消息队列的使用场景和适用情况。 2. **逐步解答**:基于引用,分步解释。 - 先概述消息队列是什么。 - 然后列出主要使用场景。 - 解释适用情况,包括好处和成本。 3. **引用内容**:在回答中自然地引用相关段落。 4. **生成相关问题**:在回答末尾添加相关问题。 关键点从引用: - 使用场景: - 异步处理:引用[1]和[4]提到异步处理,减少响应时间。 - 解耦:引用[1]和[5]强调解耦系统组件。 - 广播:引用[5]提到一次发送,多个消费者。 - 削峰:引用[5]处理流量高峰。 - 适用情况: - 生产者不需要消费者反馈:引用[5]。 - 容许短暂不一致性:引用[5]。 - 收益超过成本:引用[5]。 回答大纲: 1. **引言**:简要介绍消息队列。 2. **核心使用场景**: - 解耦系统 - 异步处理 - 广播消息 - 流量削峰 3. **适用情况**: - 当需要解耦组件时 - 当响应时间需要优化时 - 当处理高并发或峰值负载时 - 考虑成本和一致性要求 4. **总结**:强调关键点。 5. **相关问题**:生成3-5个相关问题。 生成相关问题: - 基于主题,如: 1. 消息队列在分布式系统中的作用? 2. 如何选择RabbitMQ vs Kafka? 3. 消息队列常见问题如消息丢失如何解决? 4. 消息队列在微服务架构中的应用? 5. 消息队列的性能优化策略? 确保回答真实可靠,基于提供的引用。</think>### 消息队列的使用场景和适用情况 消息队列(Message Queue, MQ)是一种中间件技术,用于在分布式系统中异步传递消息,实现系统间的解耦、可靠性传输和流量控制。它通过将消息存储在队列中,允许生产者和消费者独立处理任务,从而提高系统的可扩展性和容错性。以下我将基于核心概念,逐步解释消息队列的使用场景和适用情况,内容参考了站内权威引用,确保真实可靠。 #### 1. **核心使用场景** 消息队列主要适用于以下四种场景,这些场景能显著提升系统性能和灵活性: - **解耦系统组件**:当系统由多个模块组成时,直接调用可能导致紧耦合(一个模块故障影响整体)。消息队列充当“中间人”,生产者发送消息到队列,消费者独立消费,无需知道对方细节。例如,在电商系统中,订单服务(生产者)生成订单后写入队列,库存服务(消费者)异步处理库存扣减,避免订单服务阻塞等待[^1][^5]。引用[^5]强调:“每个成员不必受其他成员影响,可以更独立自主,只通过一个简单的容器来联系。” - **异步处理任务**:对于耗时操作(如数据处理或通知),消息队列允许主流程快速返回响应,提升用户体验。例如,用户注册时,A系统将验证邮件任务发送到队列(耗时5ms),然后立即返回响应(总耗时8ms),用户感知响应迅速;后台服务异步处理邮件发送[^4]。引用[^4]说明:“A系统连续发送3条消息到MQ队列中,假如耗时5ms,A系统从接受一个请求到返回响应给用户,总时长是3 + 5 = 8ms。” - **广播消息(发布/订阅模式)**:当一条消息需要被多个消费者处理时,消息队列支持广播机制。例如,新闻推送系统中,发布者将新闻发送到队列,多个订阅者(如APP、短信服务)同时消费,避免重复发送[^3][^5]。引用[^5]指出:“小红只需要劳动一次,就可以让多个小伙伴有书可读,这大大地节省了她的时间。” - **流量削峰**:在高并发场景(如秒杀活动),消息队列作为缓冲区,平滑处理请求峰值。生产者快速写入消息,消费者按能力处理,防止系统过载。例如,电商促销时,订单请求先入队列,库存服务逐步消费,避免数据库崩溃[^2][^5]。引用[^5]解释:“小明只要在三个月内从书架上陆续取走五本书读完就行了,压力就不那么大了。” #### 2. **适用情况** 消息队列并非万能,适用性取决于系统需求和权衡成本。以下是关键适用条件: - **生产者不需要即时反馈**:生产者发送消息后无需等待消费者响应,适合异步任务(如日志记录或通知)。如果生产者需要实时结果(如支付确认),则不适合MQ,因为消息队列强调“最终一致性”(消息可能延迟处理)[^5]。引用[^5]强调:“生产者不需要从消费者处获得反馈,引入消息队列之前的直接调用,其接口的返回值应该为空。” - **容许短暂不一致性**:消息队列可能导致数据延迟(如订单状态更新稍后生效),系统需容忍这种“最终一致性”。例如,在库存管理中,扣减操作可能滞后,但最终数据会一致[^5]。引用[^5]说明:“妈妈可能会发现‘有时候据说小明看了某书,而小明其实还没看’,只要妈妈满意于‘反正他最后看了就行’,异步处理就没问题。” - **收益大于成本**:引入MQ需评估收益(解耦、提速等)是否超过成本(如复杂度增加、监控需求)。适用场景包括: - 高并发系统:如在线游戏或社交APP,处理百万级请求。 - 微服务架构:服务间通信,避免直接依赖。 - 需要可靠性的场景:如金融交易日志,MQ的持久化机制(如RabbitMQ)确保消息不丢失[^1][^2]。 引用[^5]总结:“解耦、提速、广播、削峰这些方面的收益,超过放置书架、监控书架这些成本。” - **不适用情况**: - 实时性要求高的系统(如股票交易),MQ延迟不可接受。 - 简单系统:如果组件少,直接调用更高效(避免额外中间件开销)。 - 资源受限环境:MQ需要额外服务器和维护成本[^5]。 #### 3. **总结** 消息队列的核心价值在于通过异步和解耦,提升系统弹性、性能和可维护性。典型应用包括电商订单处理、日志收集和微服务集成。选择MQ时,优先考虑RabbitMQ(强调可靠性和易用性)或Kafka(高吞吐量,适合大数据场景)[^1][^2]。实际部署时,需启用消息确认和持久化机制,确保消息完整性[^2]。最终,是否使用MQ取决于是否满足“解耦、提速、广播、削峰”的需求,且成本可控[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值