MQ应用场景,工作模式！！！！！！！！

本文主要介绍了对于MQ的应用场景和工作模式
更多请关注我的Blog，github有点慢，但是请多多关注，欢迎各位大佬踩！！！
—PopDemo

1. MQ（消息队列）

• 介绍

  • 消息队列中间件是分布式系统中的重要组件，主要解决以下应用背景中的三大模块，从而实现高性能，高可用，可伸缩和最终一致性的架构

• 应用背景

  • 异步消息，应用解耦，流量削峰

    • 异步消息

      • 当我们的用户注册后写入数据库后，需要去发送短信和邮件去通知用户

        • 传统处理
          • 
          • 解释
            • 我们需要一级一级来对其进行功能的实现非常耗时
        • 加入MQ后
          • 
          • 解释
            • 通过写入我们消息队列，让邮件和信息模块直接去异步读取消息队列中的祖册信息

    • 应用解耦

      • 用户下单后，订单系统需要通知库存系统
        • 传统处理
          • 
          • 解释
            • 它通过我们的订单系统直接去访问我们的库存系统，假如我们的库存系统宕机了，那会造成很大的影响
            • 缺点 ： 订单系统和库存系统紧密的耦合在一起
        • 加入MQ
          • 
          • 解释
            • 实现应用解耦，加入了中间人--------最大的引入了消息中间件
            • 订单系统可以通过写入消息队列，从而库存系统会去订阅也就是获取消息队列中的下单信息来对库存进行操作

    • 流量削峰

      • 例如秒杀，秒杀他会有大量的信息涌入进来，导致流量暴增，应用直接挂掉
        • 用前端去加入消息队列
          • 
          • 解释
            • 在通过秒杀的案例来说，我们例如去抢购10个N95口罩
            • 我们可以直接在消息队列中设置请求的队列的数量（=10），假如消息队列长度超过最大数量，则直接抛弃用户请求或直接跳到错误页面
            • 之后秒杀业务处理再去获取用户的下单信息来进行完成

  • 消息队列的两种模式

    • 点对点模式（一对一模式，消费者主动拉去数据，消息收到后消息清除）

    

    • 发布-订阅模式（一对多，消费者消费数据之后不会清楚消息）

      • 消息生产者（发布）消息发布到topic主题中，同时有多个消息消费者（订阅）消费该消息，和点对点的方式不同，发布到topic的消息会被所有的订阅者消费
        • 

  • 谈谈对于两种模式的优缺点

    • 点对点
      • 缺点
        • 我们需要消费者 主动的去 队列中去找到消息，so 我们的消费者需要 不停的去 队列中去查看消息
    • 发布-订阅模式
      • 缺点
        • 我们的主题队列会主动的去把消息推到消费者里，但是我们的消费者可能会 被动接收到 更大的流量，造成宕机，或者 消费者的处理量很大，又会造成资源浪费
      • 优点
        • 消息队列可以传给多个消费者来进行使用
        • 消费者的消费速度，可以自己去设置使用