vault backup: 2026-05-24 20:58:10

hhs/MQ/01-基础概念/1-MQ-基础概念.md

@@ -1,6 +1,9 @@
 ---
 tags:
   - MQ
+  - 基础概念
+  - 异步
+  - 架构
 create time: 2026-05-24 19:52
 ---
 
@@ -8,7 +11,7 @@ create time: 2026-05-24 19:52
 
 ## 概述
 
-消息队列（Message Queue，简称 MQ）是一种异步通信机制，允许应用程序通过消息的生产和消费来实现解耦与协作。本文从生活类比出发，梳理核心术语、基本工作流程以及 MQ 的三大核心价值。
+消息队列（Message Queue，简称 MQ）是一种异步通信机制，允许应用程序通过消息的生产和消费来实现解耦与协作。本文从生活类比出发，梳理核心术语、Pull/Push 两种消费模型、基本工作流程、MQ 的三大核心价值，以及引入 MQ 需要付出的代价。
 
 ## 正文
 
@@ -53,6 +56,22 @@ sequenceDiagram
 > [!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. 解耦
@@ -140,7 +159,24 @@ func ConsumeSeckill() {
 > [!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 并行消费的实战模式