目录
[2、Work Queue（工作队列）](#2、Work Queue（工作队列）)
[3、Publish/Subscribe（发布 / 订阅）](#3、Publish/Subscribe（发布 / 订阅）)
[6、RPC（RPC 通信）](#6、RPC（RPC 通信）)
[7、Publisher Confirms（发布确认）](#7、Publisher Confirms（发布确认）)
[五、可靠性、顺序性、幂等性 、死信、延迟队列、消息积压](#五、可靠性、顺序性、幂等性 、死信、延迟队列、消息积压)
一、MQ的作用及应用场景
消息队列MQ是一种应用程序间的通信方法，允许系统组件以异步的方式进行交互，有以下应用场景：
1.1、异步解耦：提升系统响应速度
核心逻辑 ：将非核心、耗时操作异步化，避免主流程阻塞。
典型案例：用户注册流程中，主流程仅完成账号创建、数据入库，而短信验证、邮件通知、积分发放等操作通过 MQ 异步处理。用户无需等待这些附加操作完成，即可收到注册成功反馈，系统响应时间从数百毫秒缩短至数十毫秒。
优势：降低模块间依赖，某一异步操作故障不会影响主流程，提升系统可用性。
1.2、流量削峰：应对突发流量冲击
核心逻辑 ：通过 MQ 缓冲突发请求，避免后端服务因瞬时高负载崩溃。
典型案例：电商秒杀 / 促销活动中，瞬时请求量可能达到平时的 10-100 倍。MQ 将所有请求排队存储，后端服务根据自身处理能力（如每秒 1000 笔）逐步消费队列中的请求，避免数据库、接口因过载拒绝服务。
优势：无需按峰值流量配置硬件资源，降低系统运维成本。
1.3、异步通信：按需延迟处理
核心逻辑 ：应用无需立即处理消息，可在资源空闲时批量处理。
典型案例：日志收集系统中，业务服务器将日志写入 MQ，日志分析服务在夜间低峰期批量拉取日志进行分析计算，既不影响白天业务运行，又能充分利用闲置资源。
1.4、消息分发：多系统协同响应
核心逻辑 ：同一消息需被多个系统处理时，通过 MQ 广播分发，替代多系统轮询数据库。
典型案例：支付成功后，支付系统向 MQ 发送 "支付完成" 消息，订单系统（更新订单状态）、库存系统（扣减库存）、财务系统（记账）、积分系统（增加积分）订阅该消息，同步完成各自业务逻辑，避免多系统频繁查询支付结果。
1.5、延迟通知：定时触发业务逻辑
核心逻辑 ：利用延迟队列功能，在指定时间后触发通知或业务处理。
典型案例：电商订单超时未支付自动取消、外卖订单超时未接单提醒、会员到期续费通知等，通过 MQ 延迟消息精准控制触发时间，无需开发复杂的定时任务系统。
二、主流MQ产品对比
Kafka、RabbitMQ、RocketMQ 的区别是什么？
不同 MQ 分别适用于什么场景？
|------------|----------------------------|--------------------------|----------------------|
| 特性 | RabbitMQ | Kafka | RocketMQ |
| 开发语言 | Erlang | Scala | Java |
| 核心优势 | 功能完备、生态成熟、支持多语言 | 高吞吐量、高可靠性、适合大数据 | 分布式支持好、稳定性强 |
| 单机吞吐量 | 万级 / 秒 | 十万级 / 秒 | 十万级 / 秒 |
| 支持语言 | 几乎所有主流语言（Java、Python、Go 等） | 支持主流语言，但客户端生态不如 RabbitMQ | 主要支持 Java，其他语言客户端较少 |
| 社区活跃度 | 高（文档更新频繁） | 高（大数据领域热门） | 一般 |
| 核心适用场景 | 中小型系统、并发适中、对功能完整性要求高 | 日志聚合、大数据处理、实时分析 | 大规模分布式系统、互联网金融、高并发场景 |
| 功能特性 | 支持死信队列、延迟队列、发布确认、重试机制等完备特性 | 功能简单，主要聚焦高吞吐消息传输 | 支持分布式事务、定时消息等企业级特性 |
三、RabbitMQ核心流程
3.1、核心组件详解
（1）Producer（生产者）
定义：消息的发送者，负责创建消息并发送到 RabbitMQ 服务器。
关键操作：建立连接、声明交换机 / 队列、绑定关系、发送消息。
（2）Consumer（消费者）
定义：消息的接收者，监听队列并处理收到的消息。
关键操作：建立连接、订阅队列、消费消息、发送确认（ACK）。
（3）Broker（消息代理）
定义：RabbitMQ 服务器实例，本质是一个中间件节点，负责接收、存储、转发消息。
核心职责：维护连接、管理交换机和队列、执行路由规则、处理消息持久化。
（4）Connection（网络连接）
定义：生产者 / 消费者与 Broker 之间的 TCP 连接。
注意事项：TCP 连接创建和销毁开销较大，通常不会频繁创建，而是通过 Channel 复用。
（5）Channel（信道）
定义：Connection 内部的虚拟通道，是消息传输的实际载体。
核心价值：复用单个 TCP 连接，减少连接开销，同时实现隔离（一个 Connection 可创建多个 Channel，各自独立传输消息）。
（6）Exchange（交换机）
定义：接收生产者发送的消息，根据路由键（Routing Key）和绑定规则（Binding）将消息路由到对应的队列。
核心特性：本身不存储消息，若未找到匹配的队列，消息会被丢弃或退回（取决于生产者配置）。
（7）Queue（队列）
定义：存储消息的容器，直到消息被消费者消费。
核心特性：队列是持久化的（可配置），消息按 FIFO（先进先出）顺序存储和消费。
（8）Binding（绑定）
定义：交换机与队列之间的关联关系，包含路由键（Routing Key）和绑定类型。
作用：告诉交换机如何将消息路由到具体队列。
3.2、工作流程
- 连接建立 ：生产者 / 消费者通过 TCP 连接到 Broker，再创建 Channel（避免频繁创建 TCP 连接）。
- 资源声明 ：生产者需声明交换机和队列，并通过 Binding 将两者关联（指定路由规则），若资源已存在则直接复用。
- 消息发布 ：生产者通过 Channel 发送消息，消息包含内容和路由键（Routing Key）。
- 路由转发：交换机根据路由键和绑定规则，将消息路由到一个或多个队列。
- 消息存储：队列接收消息后，按配置进行持久化（若开启），并存储直到被消费。
- 消息消费：消费者监听队列，收到消息后进行业务处理。
- 消息确认 ：消费者处理完成后，向 Broker 发送 ACK 确认，Broker 收到后删除队列中的该消息。
四、RabbitMQ工作模式
1、Simple（简单模式）
核心特点 ：一对一通信：一个生产者→一个队列→一个消费者
适用场景：单一生产者、单一消费者的简单场景（如日志写入）
实现要点 ：无需交换机，生产者直接发送消息到队列，消费者监听该队列
2、Work Queue（工作队列）
核心特点 ：一对多通信：一个生产者→一个队列→多个消费者
适用场景：任务分发（如订单处理、数据计算），需负载均衡
实现要点 ：多个消费者监听同一队列，RabbitMQ 默认采用 "轮询" 分发消息；通过
basicQos设置预取数，实现 "能者多劳"
3、Publish/Subscribe（发布 / 订阅）
核心特点 ：广播通信：一个生产者→交换机→多个队列→多个消费者
适用场景：消息广播（如系统通知、状态同步）
实现要点 ：交换机类型为 Fanout，生产者发送消息到交换机，交换机将消息路由到所有绑定的队列，每个队列的消费者都能收到消息
4、Routing（路由模式）
核心特点 ：定向通信：基于路由键精准匹配
适用场景：消息需要按类别分发（如错误日志仅发送给运维系统，访问日志发送给统计系统）
实现要点 ：交换机类型为 Direct，队列绑定交换机时指定路由键，生产者发送消息时指定路由键，交换机仅将消息路由到路由键匹配的队列
5、Topics（通配符模式）
核心特点 ：模糊匹配通信：基于通配符路由键匹配
适用场景：更灵活的路由场景（如按用户地区、业务类型分发消息）
实现要点 ：交换机类型为 Topic，路由键支持通配符（
*匹配一个单词，#匹配多个单词），如order.#可匹配order.create、order.pay.success
6、RPC（RPC 通信）
核心特点 ：远程调用：消费者作为服务提供者，生产者作为调用者
适用场景：需同步获取调用结果的场景（如查询用户信息）
实现要点 ：生产者发送 RPC 请求消息（含回调队列），消费者处理后将结果发送到回调队列，生产者监听回调队列获取结果
7、Publisher Confirms（发布确认）
核心特点 ：确保消息可靠投递
适用场景：所有需要保证消息不丢失的场景
实现要点 ：开启发布确认模式，生产者监听 Broker 的确认响应，处理成功 / 失败情况
五、可靠性、顺序性、幂等性 、死信、延迟队列、消息积压
以上几个问题可见另一篇笔记：