vault backup: 2026-06-08 23:08:57

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

@@ -35,7 +35,8 @@ create time: 2026-05-24 19:52
 | **Queue** | 消息的物理存储单元 | 实际的格口 |
 | **Message** | 传输的数据单元 | 包裹 |
 | **Offset** | 消息在队列中的位置标识，用于消费进度追踪 | 快递单号 |
-| **Partition** | Topic 的物理分片，实现并行消费 | 同一排快递柜的不同列 |
+| **Partition** | Topic 的物理分片，同一 Partition 内消息有序 | 同一排快递柜的不同列 |
+| **Consumer Group** | 一组协作消费同一 Topic 的消费者实例，组内成员分摊 Partition，实现并行消费 | 多个收件人各自认领不同列的快递柜 |
 
 ### 基本工作流程
 
@@ -70,7 +71,39 @@ sequenceDiagram
 **简单理解**：Pull 是"我去超市买东西"（我决定什么时候买、买多少），Push 是"外卖送到家门口"（商家决定什么时候送）。
 
 > [!tip]
-> 大多数现代 MQ 默认采用 Pull 模式，因为 Consumer 更清楚自己的处理能力，天然具备背压（Backpressure）能力。详细的流控与背压机制见 [[31-MQ-背压与流控]]。
+> 大多数现代 MQ 默认采用 Pull 模式，因为 Consumer 更清楚自己的处理能力，天然具备**背压（Backpressure）**能力——忙时少拉、闲时多拉，消费速率由消费者自己掌控，Broker 不会把消费者"喂撑"。但纯 Pull 也有缺点：如果消费者一直不拉，消息就会延迟堆积。所以 Kafka 和 RocketMQ 实际采用的是**长轮询（Long Polling）**：消费者发起拉取请求，如果没有新消息，Broker 会 hold 住连接直到有消息到达或超时，兼顾了 Pull 的自主性和 Push 的实时性。详细的流控与背压机制见 [[31-MQ-背压与流控]]。
+
+### Consumer Group：并行消费的核心机制
+
+为什么需要 Consumer Group？想象一个电商大促场景：一个 Topic 每秒涌入 10 万条订单消息，单个消费者根本处理不过来。Consumer Group 就是解决这个问题的——**同一个 Group 内的多个消费者实例协作分担消费任务，每个 Partition 同时只能被组内的一个消费者持有。**
+
+```mermaid
+graph LR
+    subgraph Topic
+        P0["Partition 0"]
+        P1["Partition 1"]
+        P2["Partition 2"]
+    end
+    subgraph "Consumer Group A"
+        C0["Consumer 0"]
+        C1["Consumer 1"]
+    end
+
+    P0 --> C0
+    P1 --> C0
+    P2 --> C1
+```
+
+> [!question]
+> 如果 Consumer Group 内有 5 个消费者，但 Topic 只有 3 个 Partition，会发生什么？反过来呢？
+
+核心规则很简单：
+- **消费者数 ≤ Partition 数**：每个消费者至少分到一个 Partition，正常工作
+- **消费者数 > Partition 数**：多余的消费者会空闲（被"闲置"），浪费资源
+- **Rebalance（重平衡）**：当有消费者加入或离开 Group 时，Partition 归属会重新分配，详见 [[3-MQ-消息模型]]
+
+> [!tip]
+> 一个 Topic 可以被多个不同的 Consumer Group 独立消费，每个 Group 维护自己的消费进度（Offset）。这就是 MQ 实现"一对多"广播的关键机制。
 
 ### MQ 的三大核心价值