[MQ] 消息队列
消息队列是大型分布式系统不可缺少的中间件,也是高并发系统的基石中间件 一、消息队列MQ概述 消息队列(Message Queue),指保存消息的一个容器,本质是个队列,传送的消息可以是文本字符串,也可以是复杂的嵌入对象 基本模型 应用场景 1.异步处理 消息队列的主要特点是异步处理,主要目的是减少请求响应的时间,实现非核心流程异步化,提高系统响应性能 了解同步与异步同步与异步的区别(一看则懂)_同步和异步的区别-CSDN博客 异步的经典场景就是将比较耗时而且不需要即时(同步)返回结果的操作,通过消息队列来实现****异步化 2.应用解耦 解耦:保证消息格式不变,消息的发送方和接收方之间并不需要彼此联系,也不受对方的影响 只通过消息队列MQ来联系(?) 3.流量削锋 一般在秒杀或团抢活动中使用广泛 这种场景中系统的峰值流量往往集中于一小段时间内,所以为了防止系统在短时间内的峰值流量冲垮,往往采用消息队列来削弱峰值流量,相当于消息队列做了一次缓冲 4.日志处理 日志处理是指将消息队列用在日志处理中,以解决大量日志传输的问题(比如Kafka) 暂时无法在飞书文档外展示此内容 二、消息队列MQ设计 1.整体框架 暂时无法在飞书文档外展示此内容 Producer 消息生产者:负责产生和发生消息到Broker; Broker 消息处理中心:负责消息存储、确认、重试等,一般会有多个queue; Consumer 消息消费者:负责从Broker中获取消息,并进行相应处理; 2.详细设计 Producer生产者 产生消息 –> Broker消息处理中心 存储消息 –> Consumer 消费者对消费消息,返回 消息确认 –> Broker 进行消息备份/删除 RPC通信 Producer产生消息,Consumer消费消息都会涉及到通信的问题,消息队列使用了RPC将数据流串起来 Broker存储 消息到达服务端后需要存储到Broker 流量削峰、最终一致性等需求都是需要Broker先存储下来,等待合适的时机投递 存储可以有很多方式,存储在内存,分布式KV,磁盘,数据库等,存储的选项需要考虑综合性能/高可用和开发维护成本 消费模型 消息到达Broker后,最终需要Consumer去消费消息,这里涉及到消费模型 目前主要有两种:单播和广播 单播:点到点 广播:一点对多点 高级特性 Consumer端把消息消费了,除了需要消息确认,还会涉及到比如:重复消息、顺序消息、消息延迟、事务消息等需要考虑的高级特性 消息队列MQ模型 主要有两种模型:点对点 与 发布订阅 两种模型 消息队列是什么_mq是什么_MQ消息队列服务-AWS云服务 深入消息队列MQ,看这篇就够了!