MQ应用场景分析
消息队列中间件是分布式系统中的重要组件,主要解决异步消息,应用解耦,流量削峰等问题,从而实现高性能,高可用,可伸缩和最终一致性的架构
使用较多的消息队列有ActiveMQ,RabbitMQ,Kafka,MetaMQ等
异步处理
场景说明:用户注册后,需要发送注册邮件和注册短信
传统模式:
缺点:
- 一些非必要的业务逻辑以同步的方式运行,太耗费时间
中间件模式:
注册信息写入数据库,向消息队列写入消息,注册邮箱和注册短信会同时向消息队列异步读取数据,然后在发邮件发短信
优点:
- 将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度
应用解耦
场景说明:用户下单后,订单系统需要通知库存系统
传统模式:订单系统直接调用库存系统
缺点:
- 假如库存系统无法访问,订单减库存将失败,导致下单失败
- 耦合度太高了
- 系统间耦合性太强,如上图所示,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦!
中间件模式:
优点:
- 将消息写入消息队列,需要消息的系统自己从消息队列中订阅,从而系统A不需要做任何修改
- 实现应用解耦
流量削峰
一般在秒杀或者团抢活动中广泛使用
应用场景:秒杀活动,一般会流量过大,导致流量暴增,应用挂掉
传统模式:
用户抢购产品发送请求,处理这个请求进行抢购
缺点:
- 并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常
中间件模式:
优点:
- 系统A慢慢的按照数据库能处理的并发量,从消息队列中慢慢拉取消息。在生产中,这个短暂的高峰期积压是允许的
- 可以控制活动的人数
- 可以缓解短时间内高流量压垮应用
用户请求,会将请求写在消息队列里,假如消息队列长度超过最大数量,就会直接抛弃用户请求跳转到错误页面,秒杀业务根据消息队列中的请求信息,在做后续处理
似乎有点不够呢