183 lines
7.5 KiB
Markdown
183 lines
7.5 KiB
Markdown
---
|
||
tags:
|
||
- MQ
|
||
- 基础概念
|
||
- 异步
|
||
- 架构
|
||
create time: 2026-05-24 19:52
|
||
---
|
||
|
||
# MQ 基础概念
|
||
|
||
## 概述
|
||
|
||
消息队列（Message Queue，简称 MQ）是一种异步通信机制，允许应用程序通过消息的生产和消费来实现解耦与协作。本文从生活类比出发，梳理核心术语、Pull/Push 两种消费模型、基本工作流程、MQ 的三大核心价值，以及引入 MQ 需要付出的代价。
|
||
|
||
## 正文
|
||
|
||
### 什么是消息队列
|
||
|
||
想象一下你去寄快递：你把包裹交给快递柜，快递柜暂存包裹，收件人有空时再来取件。你不需要知道收件人什么时候在家，快递柜也不关心包裹里装的是什么——三方各司其职。
|
||
|
||
消息队列做的事情完全一样：**Producer（生产者）把消息投递到 Broker（消息服务器），Broker 暂存消息，Consumer（消费者）按自己的节奏拉取并处理。** 生产和消费在时间上解耦，双方不需要同时在线。
|
||
|
||
> [!question]
|
||
> 生活中还有哪些场景天然就是"消息队列"的模式？食堂排队打饭算不算？
|
||
|
||
### 核心术语图解
|
||
|
||
| 术语 | 说明 | 类比 |
|
||
|------|------|------|
|
||
| **Producer** | 消息的发送方 | 寄件人 |
|
||
| **Broker** | 消息服务器，负责存储和转发 | 快递柜 / 邮局 |
|
||
| **Consumer** | 消息的接收方和处理方 | 收件人 |
|
||
| **Topic** | 消息的逻辑分类，Producer 按 Topic 发送 | 快递柜的格口编号 |
|
||
| **Queue** | 消息的物理存储单元 | 实际的格口 |
|
||
| **Message** | 传输的数据单元 | 包裹 |
|
||
| **Offset** | 消息在队列中的位置标识，用于消费进度追踪 | 快递单号 |
|
||
| **Partition** | Topic 的物理分片，实现并行消费 | 同一排快递柜的不同列 |
|
||
|
||
### 基本工作流程
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant P as "Producer"
|
||
participant B as "Broker"
|
||
participant C as "Consumer"
|
||
|
||
P->>B: 1. 发送消息到 Topic
|
||
B->>B: 2. 持久化消息,分配 Offset
|
||
C->>B: 3. 拉取消息(Pull)或接收推送(Push)
|
||
B-->>C: 4. 返回消息
|
||
C->>C: 5. 处理业务逻辑
|
||
C->>B: 6. 提交消费确认(Ack)
|
||
```
|
||
|
||
> [!question]
|
||
> 第 6 步的 Ack 确认机制为什么重要？如果没有 Ack 会怎样？
|
||
|
||
### Pull vs Push：两种消费模型
|
||
|
||
流程图第 3 步提到了"拉取"和"推送"两种方式，这其实是消息消费的两种根本模型：
|
||
|
||
| 维度 | **Pull（拉取）** | **Push（推送）** |
|
||
|------|-----------------|-----------------|
|
||
| 主动方 | Consumer 主动拉取 | Broker 主动推送 |
|
||
| 消费节奏 | Consumer 自己控制，想拉多少拉多少 | Broker 控制推送速率，Consumer 被动接收 |
|
||
| 适用场景 | 消费能力不均匀、需要精确控速 | 低延迟要求、实时性敏感 |
|
||
| 典型代表 | Kafka、RocketMQ（默认） | RabbitMQ、MQTT |
|
||
|
||
**简单理解**：Pull 是"我去超市买东西"（我决定什么时候买、买多少），Push 是"外卖送到家门口"（商家决定什么时候送）。
|
||
|
||
> [!tip]
|
||
> 大多数现代 MQ 默认采用 Pull 模式，因为 Consumer 更清楚自己的处理能力，天然具备背压（Backpressure）能力。详细的流控与背压机制见 [[31-MQ-背压与流控]]。
|
||
|
||
### MQ 的三大核心价值
|
||
|
||
#### 1. 解耦
|
||
|
||
没有 MQ 时，下单服务需要直接调用库存、积分、物流等多个下游服务，形成蜘蛛网般的依赖。引入 MQ 后，下单服务只需发一条消息，各下游自行订阅。
|
||
|
||
```go
|
||
// 解耦前: 下单服务直接依赖所有下游
|
||
func CreateOrder(order Order) {
|
||
db.Save(order)
|
||
inventorySvc.Deduct(order.ItemID, order.Qty) // 强依赖
|
||
pointsSvc.Add(order.UserID, order.Points) // 强依赖
|
||
logisticsSvc.Create(order) // 强依赖
|
||
// 新增通知服务？改代码、重新部署...
|
||
}
|
||
|
||
// 解耦后: 只管发消息,下游自己订阅
|
||
func CreateOrder(order Order) {
|
||
db.Save(order)
|
||
mq.Publish("order_created", order) // 一条消息,谁关心谁订阅
|
||
}
|
||
```
|
||
|
||
解耦的本质是把**"我知道谁需要"变成"谁需要谁知道"**，新增下游服务时生产者代码零改动。
|
||
|
||
#### 2. 异步
|
||
|
||
有些操作不需要用户等待结果。比如注册后发欢迎邮件、生成报表等，可以把这些耗时操作异步化。
|
||
|
||
```go
|
||
// 同步: 用户等所有操作完成,响应慢
|
||
func Register(user User) {
|
||
db.Save(user) // 50ms
|
||
emailSvc.SendWelcome(user) // 200ms
|
||
analyticsSvc.Track(user) // 100ms
|
||
// 总耗时 350ms,用户等到怀疑人生
|
||
}
|
||
|
||
// 异步: 用户只等核心操作,其余扔给 MQ
|
||
func Register(user User) {
|
||
db.Save(user) // 50ms
|
||
mq.Publish("user_registered", user) // 5ms
|
||
// 总耗时 55ms,邮件和埋点慢慢处理
|
||
}
|
||
```
|
||
|
||
#### 3. 削峰
|
||
|
||
秒杀场景下，瞬间流量可能打垮数据库。MQ 充当缓冲区，让下游按自己的处理能力消费消息。
|
||
|
||
```go
|
||
// 削峰前: 瞬时 1 万 QPS 直接打到数据库,DB 直接跪
|
||
func Seckill(userID, itemID string) {
|
||
if stock > 0 {
|
||
db.UpdateStock(itemID, -1) // DB 瞬间被打爆
|
||
}
|
||
}
|
||
|
||
// 削峰后: 先接住流量,慢慢消费
|
||
func Seckill(userID, itemID string) {
|
||
mq.Publish("seckill_request", SeckillReq{userID, itemID}) // 瞬时接住
|
||
}
|
||
|
||
// 消费者按 DB 承受能力匀速消费
|
||
func ConsumeSeckill() {
|
||
for msg := range mq.Subscribe("seckill_request") {
|
||
if stock > 0 {
|
||
db.UpdateStock(msg.ItemID, -1) // 匀速处理,DB 稳如老狗
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
### MQ vs 直接调用
|
||
|
||
| 维度 | 直接调用 | 消息队列 |
|
||
|------|---------|---------|
|
||
| 耦合度 | 强耦合，调用方需感知下游 | 松耦合，生产者不关心消费者 |
|
||
| 响应时间 | 等待所有下游完成 | 只等核心链路，非核心异步处理 |
|
||
| 可靠性 | 下游挂了直接失败 | Broker 持久化，支持重试 |
|
||
| 吞吐能力 | 受限于最慢的下游 | 通过缓冲削峰，提升整体吞吐 |
|
||
| 复杂度 | 简单直观 | 引入额外组件，运维成本上升 |
|
||
| 一致性 | 容易保证强一致性 | 最终一致性，需要额外设计 |
|
||
|
||
> [!question]
|
||
> 如果不需要解耦和削峰，还有必要引入 MQ 吗？
|
||
|
||
### MQ 引入的代价
|
||
|
||
MQ 不是银弹，引入它就意味着接受以下挑战：
|
||
|
||
1. **运维复杂度上升**：多了一个需要监控、扩容、容灾的中间件。Broker 挂了怎么办？消息积压怎么告警？这些都是新增的运维命题。
|
||
2. **消息丢失与重复**：网络不可靠，消息可能丢、可能重复投递。你需要设计 ACK 机制、幂等消费、甚至 Exactly-Once 语义——这些都不简单。
|
||
3. **系统可用性转移**：原本你的可用性取决于自己，现在还取决于 Broker。Broker 成了新的单点风险。
|
||
4. **调试链路变长**：同步调用出了问题，顺着调用栈就能排查。引入 MQ 后，消息可能在队列里"躺"了很久才被消费，排查问题的难度显著增加。
|
||
|
||
> [!warning]
|
||
> 在决定引入 MQ 之前，先问自己：**我真正需要的是解耦、异步还是削峰？** 如果答案都是"不太需要"，直接调用可能是更简单可靠的选择。何时该用 MQ 见 [[2-MQ-适用场景与选型原则]]。
|
||
|
||
> [!tip]
|
||
> **一句话总结**：MQ 通过引入"中间人"角色，实现了生产者与消费者之间的解耦、异步和削峰，但代价是更高的系统复杂度和最终一致性。理解这个 trade-off，是用好 MQ 的第一步。
|
||
|
||
## 关联笔记
|
||
|
||
- [[2-MQ-适用场景与选型原则]]
|
||
- [[3-MQ-消息模型]]
|
||
- [[12-MQ-消息确认与持久化]] — Ack 机制的详细设计
|
||
- [[28-MQ-Competing-Consumers-模式]] — Partition 并行消费的实战模式
|