[toc]
| 单词 | 词性 | 音标 | 含义 |
|---|---|---|---|
| message queue | n. | /ˈmesɪdʒ kjuː/ | 消息队列（应用之间异步通信的中间件） |
| producer | n. | /prəˈdjuːsə(r)/ | 生产者（发送消息的一方） |
| consumer | n. | /kənˈsjuːmə(r)/ | 消费者（接收并处理消息的一方） |
| broker | n. | /ˈbrəʊkə(r)/ | 消息服务器主体（负责接收和分发消息） |
| exchange | n. | /ɪksˈtʃeɪndʒ/ | 交换机（消息到达 Broker 的第一站，按规则分发） |
| queue | n. | /kjuː/ | 队列（消息的容器，等待被消费） |
| binding | n. | /ˈbaɪndɪŋ/ | 绑定（交换机和队列之间的对应关系） |
| channel | n. | /ˈtʃænl/ | 通道（Connection 内的逻辑连接，复用 TCP） |
Lecture01-RabbitMQ-概念与体系结构
1、本节讲什么
先用一张图建立对 RabbitMQ 的整体认知：它是什么、解决什么问题、由哪些部件组成。这一节不敲命令，只建立概念，为后面的安装和 SpringBoot 整合打基础。
2、为什么需要消息队列（同步 vs 异步）
先看一个场景：下单功能。同步方式里，下单请求要依次调"保存订单 → 更新库存 → 更新购物车 → 更新积分"，一个做完才做下一个；异步方式里，只做核心的"保存订单"，其余交给消息队列异步处理。
同步 vs 异步对比：
| 维度 | 同步（OpenFeign 直调） | 异步（消息队列） |
|---|---|---|
| 功能耦合 | 各模块串在一起，耦合度高 | 各模块相对独立，解耦 |
| 响应时间 | 等所有步骤做完才返回（慢） | 只做核心步骤，快速返回 |
| 并发压力 | 压力沿调用链一路传导 | 借助队列削峰限流 |
| 扩展新功能 | 要改下单代码 | 新增模块对接队列即可，代码不动 |
类比（丰巢柜）：寄快递不用等收件人当场来取——把快递放进丰巢柜（消息队列），收件人方便时再来取。这就是"异步、解耦"。
正确 vs 误区：
- 并不是所有交互都改成异步；强关联（必须立刻拿到结果）仍用 OpenFeign 同步调用，弱关联、可独立拆分的功能才用消息队列异步。
- 消息队列不是"让系统变快"，而是"解耦 + 快速响应 + 削峰限流 + 便于扩展"。
3、什么是消息队列
消息队列是实现应用程序之间通信的中间件产品：发送方把消息放进队列，接收方从队列取走处理。它让两个应用不必同时在线、不必彼此直连。
一句话：消息队列 = 一个"邮局/中转站"，生产者和消费者通过它异步收发消息。
4、RabbitMQ 简介
- RabbitMQ 是一款基于 AMQP 协议、由 Erlang 语言开发的消息队列产品，2007 年发布 1.0 版本。
- 官网：
https://www.rabbitmq.com/ - 我们用的是 RabbitMQ 4.x（本教程以 4.3 为例）。
5、核心概念与体系结构
对体系结构的理解直接关系到后续的操作和使用。先看图，再看表：
核心部件一览：
| 部件 | 作用 | 通俗理解 |
|---|---|---|
| Producer | 消息的发送端 | "发信的人" |
| Consumer | 消息的接收端 | "收信的人" |
| Connection | 客户端到 Broker 的 TCP 连接 | 一条网络通道 |
| Channel | Connection 内的逻辑连接，复用 TCP | 通道里开的"子通道" |
| Broker | RabbitMQ 服务器主体，接收和分发消息 | 邮局总站 |
| Virtual Host | 虚拟分组，隔离不同项目/功能 | 邮局里的不同"分柜" |
| Exchange | 交换机，消息到达的第一站 | 分拣中心 |
| Queue | 队列，消息的容器 | 信箱 |
| Binding | 交换机与队列的对应关系 | "哪些信投哪个信箱" |
| Routing Key | 路由键，交换机按它把消息送进队列 | 信箱上的地址标签 |
关于 Connection / Channel 的关键点：
- 建立 TCP 连接要三次握手，反复建连接开销极大、效率低。
- 所以在一个 Connection 内开多个 Channel，每个线程用独立 Channel 通信，实现 Connection 复用。
- 每个 Channel 有自己的 id，Channel 之间完全隔离。
消息流转：Producer 发消息到 Exchange → Exchange 按 Binding + Routing Key 把消息路由进 Queue → Consumer 从 Queue 取走消息。
6、RabbitMQ 4 相对 3 的关键变化（重点）
| 变化 | 说明 |
|---|---|
| 推荐 Quorum 队列 | 生产高可用建议用 Quorum（仲裁）队列，天然防数据丢失；经典队列（Classic）仍是默认，但生产不推荐单靠手动持久化 |
delayed_message 插件不维护 | RabbitMQ 3 里做延迟队列的 rabbitmq_delayed_message_exchange 插件，4 里官方已标记不再维护，不推荐新项目依赖 |
| TTL + 死信仍有效 | 延迟队列仍可用 消息 TTL + 死信队列（DLX） 实现，经典队列和 Quorum 队列都支持 |
| 延迟重试（4.3 新增） | Quorum 队列新增原生延迟重试（消费失败后按退避间隔延迟重投） |
这些变化会在后面的章节里逐一落到操作上：Quorum 队列（Lecture05）、TTL+死信延迟队列（Lecture06）、Quorum 延迟重试（Lecture05）。
7、常见疑问
- Q：为什么消息队列能解耦？ A：因为各模块不直接调用，只和队列打交道。加一个新模块（如数据统计），只需让它监听队列，下单代码一行不用改。
- Q：Connection 和 Channel 啥关系？ A：Connection 是一条 TCP 连接，Channel 是这条连接里的逻辑子通道。一条 Connection 开多个 Channel，避免频繁建 TCP 连接。
- Q：Exchange 和 Queue 是什么关系？ A：消息先到 Exchange（交换机），Exchange 按 Binding（绑定）和 Routing Key（路由键）决定把消息放进哪个 Queue。消费者从 Queue 取消息。
- Q：本教程用哪个版本？
A：RabbitMQ 4.3，用 Docker 安装（
rabbitmq:4.3-management），自带 Management UI，方便可视化操作。
8、本节验证
- 说出消息队列解决的四个问题（解耦 / 快速响应 / 削峰限流 / 便于扩展）✅
- 分清 Producer / Consumer / Broker / Exchange / Queue / Binding ✅
- 说明 Connection 与 Channel 的关系（Connection 复用）✅
- 说出 RabbitMQ 4 的关键变化（Quorum 队列、插件不维护、TTL+死信仍有效）✅