Java架构之消息队列 (一):消息队列的概述

本文深入探讨消息队列的概述、使用场景和两种消息模式,重点介绍了异步处理、应用耦合、限流削峰等场景。通过实例分析了RabbitMQ、Kafka在实际应用中的作用,同时比较了各消息中间件的特点,为读者提供MQ选型参考。
摘要由CSDN通过智能技术生成

消息队列系列分享大纲:

 一、消息队列的概述

二、消息队列之RabbitMQ的使用

三、消息队列之Kafka的使用

四、消息队列之RabbitMQ的原理详解

五、消息队列之Kafka的原理详解

六、消息队列之面试集锦


1.消息队列的概述

消息队列(Message Queue)中间件是分布式系统中重要的组件;

主要解决应用耦合,异步消息,流量削锋等问题;

实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件;

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等;

部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能;

具有 低耦合、可靠投递、广播、流量控制、最终一致性 等一系列功能。


2.消息队列使用场景

消息队列在实际应用中有四个场景:

  • 应用耦合:多应用间通过消息队列对同一消息进行处理,避免调用接口失败导致整个过程失败;
  • 异步处理:多应用对消息队列中同一消息进行处理,应用间并发处理消息,相比串行处理,减少处理时间;
  • 限流削峰:广泛应用于秒杀或抢购活动中,避免流量过大导致应用系统挂掉的情况;
  • 消息驱动的系统:系统分为消息队列、消息生产者、消息消费者,生产者负责产生消息,消费者(可能有多个)负责对消息进行处理;

2.1异步处理

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

(1)串行方式:新注册信息生成后,先发送注册邮件,再发送验证短信;

在这种方式下,需要最终发送验证短信后再返回给客户端。

(2)并行处理:新注册信息写入后,由发短信和发邮件并行处理;

在这种方式下,发短信和发邮件 需处理完成后再返回给客户端。

假设以上三个子系统处理的时间均为50ms,且不考虑网络延迟,则总的处理时间:

串行:50+50+50=150ms 并行:50+50 = 100ms

若使用消息队列:

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

2.2 应用耦合

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

该方法有如下缺点:

  • 人脸识别系统被调失败,导致图片上传失败;
  • 延迟高,需要人脸识别系统处理完成后,再返回给客户端,即使用户并不需要立即知道结果;
  • 图片上传系统与人脸识别系统之间互相调用,需要做耦合;

若使用消息队列:

客户端上传图片后,图片上传系统将图片信息写入消息队列,直接返回成功;而人脸识别系统则定时从消息队列中取数据,完成对新增图片的识别。

人脸识别系统可以选择不同的调度策略,按照闲时、忙时、正常时间,对队列中的图片信息进行处理。

2.3 限流削峰

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

该方法有如下优点:

  • 请求先入消息队列,而不是由业务处理系统直接处理,做了一次缓冲,极大地减少了业务处理系统的压力;
  • 队列长度可以做限制,事实上,秒杀时,后入队列的用户无法秒杀到商品,这些请求可以直接被抛弃,返回活动已结束或商品已售完信息;

2.4 日志处理

<
  • 26
    点赞
  • 191
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值