MENU

中间件

• 2020 年 09 月 09 日 • 默认分类,微服务

MQ应用场景分析

消息队列中间件是分布式系统中的重要组件,主要解决异步消息应用解耦流量削峰等问题,从而实现高性能,高可用,可伸缩和最终一致性的架构

使用较多的消息队列有ActiveMQ,RabbitMQ,Kafka,MetaMQ

异步处理

场景说明:用户注册后,需要发送注册邮件和注册短信

传统模式:

img

缺点:

  • 一些非必要的业务逻辑以同步的方式运行,太耗费时间

中间件模式:

img

注册信息写入数据库,向消息队列写入消息,注册邮箱和注册短信会同时向消息队列异步读取数据,然后在发邮件发短信

优点:

  • 将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度

应用解耦

场景说明:用户下单后,订单系统需要通知库存系统

传统模式:订单系统直接调用库存系统

img

缺点:

  • 假如库存系统无法访问,订单减库存将失败,导致下单失败
  • 耦合度太高了
  • 系统间耦合性太强,如上图所示,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦!

中间件模式:

img

优点:

  • 将消息写入消息队列,需要消息的系统自己从消息队列中订阅,从而系统A不需要做任何修改
  • 实现应用解耦

流量削峰

一般在秒杀或者团抢活动中广泛使用

应用场景:秒杀活动,一般会流量过大,导致流量暴增,应用挂掉

传统模式:

img

用户抢购产品发送请求,处理这个请求进行抢购

缺点:

  • 并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常

中间件模式:

img

优点:

  • 系统A慢慢的按照数据库能处理的并发量,从消息队列中慢慢拉取消息。在生产中,这个短暂的高峰期积压是允许的
  • 可以控制活动的人数
  • 可以缓解短时间内高流量压垮应用

用户请求,会将请求写在消息队列里,假如消息队列长度超过最大数量,就会直接抛弃用户请求跳转到错误页面,秒杀业务根据消息队列中的请求信息,在做后续处理

添加新评论

已有 1 条评论
  1. aa aa

    似乎有点不够呢