消息队列 on 纪伟的个人博客

消息队列（四）：RabbitMQ vs Kafka 深度对比

Mon, 25 May 2026 10:00:00 +0800

写在前面

本文是消息队列系列的最后一篇，深度对比 RabbitMQ 和 Kafka 的架构、性能、可靠性、适用场景，帮你做出正确的选型决策。前置知识：RabbitMQ 深入（第二篇）、Kafka 深入（第三篇）。

一、设计哲学对比

1.1 RabbitMQ：消息代理

定位：通用的消息代理（Message Broker）

设计理念：
  - 以 Queue 为核心
  - 消息消费后删除
  - 丰富的路由规则（Exchange）
  - Push 模式（主动推给消费者）

起源：从企业消息系统演化而来
擅长：复杂的消息路由、企业集成、RPC

1.2 Kafka：分布式日志

定位：分布式事件流平台（Event Streaming Platform）

设计理念：
  - 以 Topic/Partition 为核心
  - 消息持久化，保留一段时间
  - 简单的路由（Producer 决定 Partition）
  - Pull 模式（消费者主动拉取）

起源：从 LinkedIn 的大数据管道演化而来
擅长：高吞吐日志/事件处理、流计算、消息回溯

1.3 根本差异

RabbitMQ：消息被消费就完成了使命（传递消息）
Kafka：  消息是持久化的日志（记录事实）

RabbitMQ 像邮递员：把信送到就完了
Kafka 像日记本：  记录下来，谁想看随时来看

二、架构对比

2.1 消息模型

RabbitMQ：
  Producer → Exchange → Binding → Queue → Consumer
  路由在 Broker 完成（Exchange 决定发到哪个 Queue）
  一个 Queue 的消息只能被一个 Consumer 消费（竞争消费）

Kafka：
  Producer → Topic → Partition → Consumer Group → Consumer
  路由在 Producer 完成（Producer 决定发到哪个 Partition）
  一个 Topic 可以被多个 Consumer Group 各自消费（发布订阅）

2.2 消息存储

RabbitMQ：
  - 内存为主，持久化到磁盘（Mnesia）
  - 消息消费后删除
  - 队列深度有限（内存限制）
  - 不支持消息回溯（消费了就没了）

Kafka：
  - 追加写入磁盘日志
  - 消息保留一段时间（如 7 天）后删除
  - 支持无限堆积（磁盘有多大就能存多少）
  - 支持消息回溯（修改 Offset 重新消费）

2.3 消费模型

RabbitMQ：Push 模型
  - Broker 主动推送消息给 Consumer
  - 通过 Prefetch Count 控制推送速率
  - Consumer 处理慢时 Broker 会积压
  - 消费确认后消息删除

Kafka：Pull 模型
  - Consumer 主动从 Broker 拉取
  - Consumer 控制自己的消费速率
  - 处理慢了只是 LAG 增大，不影响 Broker
  - 通过 Offset 管理消费进度

三、性能对比

3.1 吞吐量

RabbitMQ：
  单机吞吐量：万级 ~ 十万级/秒
  百万级消息需要集群 + 优化

Kafka：
  单机吞吐量：百万级/秒
  三个 Broker 的集群可达千万级/秒

差距原因：
  Kafka：顺序写磁盘 + 零拷贝 + 页缓存 + 批量发送
  RabbitMQ：随机写 + 内存管理开销 + 单条处理

3.2 延迟

RabbitMQ：
  微秒级延迟（μs）
  消息量小时延迟极低
  消息堆积时延迟增加

Kafka：
  毫秒级延迟（ms）
  受 LingerMs 和批量大小影响
  追求吞吐量时延迟偏高

结论：
  延迟敏感 → RabbitMQ
  吞吐量优先 → Kafka

3.3 消息堆积能力

RabbitMQ：
  - 消息堆积在内存中，受内存限制
  - 百万级堆积后性能明显下降
  - 可以用惰性队列（Lazy Queue）写磁盘缓解
  - 堆积过多会触发流控（阻塞生产者）

Kafka：
  - 天然持久化到磁盘，堆积是常态
  - 千万级甚至亿级消息没有压力
  - 堆积不影响生产者性能
  - 只要磁盘够，可以一直堆积

四、可靠性对比

4.1 消息不丢

RabbitMQ：
  生产端：Publisher Confirm（确认写入 Broker）
  Broker：持久化（Exchange + Queue + Message）
  消费端：手动 ACK（处理完再确认）
  高可用：镜像队列 / Quorum Queue

Kafka：
  生产端：acks=all（确认写入所有 ISR）
  Broker：副本机制（Replica + ISR）
  消费端：手动提交 Offset（处理完再提交）
  高可用：多副本 + Leader 选举

两者都能做到消息不丢，机制不同但效果相同

4.2 消息不重复

RabbitMQ：
  - 没有内置的 Exactly-Once 支持
  - 需要业务层实现幂等（去重表、唯一约束、状态机）
  - Consumer 去重需要自己维护已处理消息 ID

Kafka：
  - 幂等生产者（enable.idempotence=true）
  - Kafka 事务（跨 Partition 的原子写入）
  - 事务性消费-处理-生产（Consume-Transform-Produce）
  - 框架层面的 Exactly-Once 支持

结论：
  Kafka 在消息不重复方面更成熟

4.3 消息顺序

RabbitMQ：
  - 单 Queue 单 Consumer → 顺序保证
  - 多 Consumer → 无法保证顺序
  - 需要顺序的场景只能单消费者，牺牲并发

Kafka：
  - 同一 Partition 内消息严格有序
  - 相同 Key 路由到同一 Partition
  - 可以多个 Partition 并行，同一 Key 内有序
  - 在顺序和并发之间取得平衡

结论：
  Kafka 的 Partition 模型更适合顺序消费场景

4.4 消息回溯

RabbitMQ：
  ✗ 消息消费后删除，无法回溯
  ✗ 如果需要重新消费，需要重新发送

Kafka：
  ✓ 消息持久化，保留一段时间
  ✓ 可以修改 Offset 重新消费
  ✓ 可以按时间戳查找消息
  ✓ 可以创建新的 Consumer Group 从头消费

结论：
  Kafka 天然支持消息回溯，RabbitMQ 不支持

五、功能对比

5.1 路由能力

RabbitMQ：
  Direct   — 精确匹配 ✓
  Fanout   — 广播 ✓
  Topic    — 通配符匹配 ✓
  Headers  — 头部匹配 ✓
  路由灵活度：★★★★★

Kafka：
  Producer 指定 Partition（通过 Key Hash 或自定义）
  没有服务端路由
  路由灵活度：★★☆☆☆

结论：
  复杂路由场景 → RabbitMQ
  简单的 Topic 分区 → Kafka

5.2 延迟消息

RabbitMQ：
  ✓ TTL + DLX 方案（原生支持）
  ✓ 延迟消息插件（rabbitmq_delayed_message_exchange）
  支持程度：★★★★☆

Kafka：
  ✗ 不原生支持延迟消息
  需要自己实现（定时任务 + 外部存储）
  支持程度：★☆☆☆☆

结论：
  延迟消息场景 → RabbitMQ

5.3 协议支持

RabbitMQ：
  AMQP 0-9-1（核心协议）
  AMQP 1.0（插件）
  MQTT（插件）
  STOMP（插件）
  多协议支持好，适合异构系统集成

Kafka：
  自定义二进制协议
  通过 Kafka Connect 支持外部系统集成
  REST Proxy 提供 HTTP 接口

5.4 管理和监控

RabbitMQ：
  ✓ Web 管理界面（rabbitmq_management 插件）
  ✓ 可视化 Queue、Exchange、Consumer
  ✓ 实时消息速率和堆积监控
  管理便利度：★★★★★

Kafka：
  命令行工具为主
  需要第三方监控（Kafka Manager、CMAK、Confluent Control Center）
  社区有开源方案但需要额外部署
  管理便利度：★★★☆☆

六、运维对比

6.1 部署复杂度

RabbitMQ：
  单机：docker run -d rabbitmq  — 一步搞定
  集群：3 节点 + HA Policy
  依赖：无（Erlang 自包含）
  复杂度：★★☆☆☆

Kafka：
  单机：Broker + ZooKeeper（或 KRaft 模式）
  集群：3+ Broker + 3 ZooKeeper + 监控
  依赖：ZooKeeper（KRaft 模式可去掉）
  复杂度：★★★★☆

6.2 扩容

RabbitMQ：
  加节点 → 加入集群 → 设置 Policy
  Queue 数量不变，只是分布到更多节点
  不需要改应用配置

Kafka：
  加 Broker → 创建新 Topic 或迁移 Partition
  增加 Partition 需要考虑 Key 分布
  Consumer 可能需要调整

6.3 运维痛点

RabbitMQ：
  - 内存管理需要调优
  - 大量 Queue 时性能下降
  - 镜像队列同步慢
  - 惰性队列性能权衡

Kafka：
  - Partition 数量管理（只能增不能减）
  - Rebalance 导致消费暂停
  - ZooKeeper 运维（KRaft 模式可解决）
  - 磁盘空间管理

七、.NET 生态对比

7.1 客户端库

RabbitMQ：
  RabbitMQ.Client   — 官方库，底层 API
  MassTransit       — 高级抽象，支持 Saga、请求/响应
  EasyNetQ          — 简化 API，自动重连
  CAP               — 分布式事务（和数据库绑定）

Kafka：
  Confluent.Kafka   — 官方推荐，基于 librdkafka
  KafkaFlow         — 高级抽象
  CAP               — 同样支持 Kafka

7.2 代码复杂度

RabbitMQ（RabbitMQ.Client）：
  - Exchange/Queue 声明和绑定
  - 手动管理 Channel
  - Confirm 和 ACK 处理
  - 死信配置
  代码量较多，但控制精细

Kafka（Confluent.Kafka）：
  - Producer/Consumer 配置
  - Topic 和 Partition 管理
  - Offset 提交
  - Rebalance 处理
  配置项多但代码结构简单

八、适用场景对比

8.1 选 RabbitMQ 的场景

✓ 消息路由复杂（多种 Exchange、灵活绑定）
✓ 需要延迟消息（TTL + DLX、定时任务）
✓ 企业系统集成（支持 AMQP、MQTT、STOMP）
✓ 中小规模消息量（万级/秒以内）
✓ 需要低延迟（微秒级）
✓ 需要请求/响应模式（RPC over MQ）
✓ 快速原型和小型项目
✓ 团队已有 RabbitMQ 经验

8.2 选 Kafka 的场景

✓ 高吞吐量（百万级/秒以上）
✓ 大数据量消息堆积（千万、亿级）
✓ 事件驱动架构（Event Sourcing、CQRS）
✓ 多个消费者独立消费同一数据（Consumer Group）
✓ 需要消息回溯（重新消费历史数据）
✓ 流计算（Kafka Streams、Flink、Spark）
✓ 日志收集和监控数据管道
✓ 需要 Exactly-Once 语义
✓ 大数据平台（和 Hadoop、Spark 生态集成）

8.3 都能用的场景

✗ 异步任务处理（发短信、发邮件）
✗ 系统解耦（上下游解耦）
✗ 流量削峰（秒杀、抢购）

这些场景两者都能胜任，看团队技术栈和消息规模

九、选型决策树

消息量级？
├── 万级/秒以内
│   ├── 需要复杂路由？ → RabbitMQ
│   ├── 需要延迟消息？ → RabbitMQ
│   └── 简单的发布订阅 → RabbitMQ 或 Kafka
│
├── 万级 ~ 十万级/秒
│   ├── 路由复杂 + 延迟消息 → RabbitMQ（需要调优）
│   ├── 需要消息回溯 → Kafka
│   └── 都可以，看团队偏好
│
└── 十万级/秒以上
    └── Kafka（RabbitMQ 吞吐量不够）

特殊需求：
├── 需要 Exactly-Once → Kafka
├── 需要消息回溯     → Kafka
├── 需要流计算       → Kafka
├── 需要多协议支持   → RabbitMQ
└── 需要快速上手     → RabbitMQ

十、常见误解

10.1 “Kafka 比 RabbitMQ 好”

错。它们解决不同的问题：
  Kafka 擅长高吞吐的事件流处理
  RabbitMQ 擅长灵活的消息路由

很多场景 RabbitMQ 更合适：
  - 订单系统异步通知（发短信、邮件）
  - 企业内部系统解耦
  - 需要延迟消息的业务

10.2 “RabbitMQ 性能不够”

1
2
3

大多数业务场景远远到不了 RabbitMQ 的性能瓶颈。
万级/秒的吞吐量对绝大多数系统够用了。
只有在日志收集、大数据管道等场景才需要 Kafka 的百万级吞吐。

10.3 “选 MQ 就选 Kafka，它是趋势”

技术选型不是选最流行的，而是选最适合的：
  - 消息量不大、路由复杂 → RabbitMQ 更简单高效
  - 消息量巨大、需要回溯 → Kafka 更合适
  - 运维能力有限 → RabbitMQ 部署更简单
  - 团队已有经验 → 沿用最省力

十一、系列总结

11.1 知识体系回顾

第一篇：消息队列核心概念
  - 消息模型、路由模式、确认机制
  - 持久化、重试、死信、幂等性、投递语义

第二篇：RabbitMQ 深入
  - 架构、Exchange、可靠性、死信、延迟消息
  - .NET 实战、集群、性能调优

第三篇：Kafka 深入
  - 架构、存储机制、生产者、消费者
  - 副本、事务、Exactly-Once、.NET 实战

第四篇：RabbitMQ vs Kafka 深度对比
  - 设计哲学、架构、性能、可靠性、功能
  - 运维、.NET 生态、选型决策

11.2 核心结论

1. RabbitMQ 和 Kafka 不是替代关系，而是互补
2. 根据消息量级、路由需求、运维能力做选择
3. 大多数业务系统 RabbitMQ 足够
4. 大数据和高吞吐场景选 Kafka
5. 不确定时先用 RabbitMQ（更简单），规模上来再考虑 Kafka

消息队列（三）：Kafka 深入

Sun, 24 May 2026 10:00:00 +0800

写在前面

本文是消息队列系列的第三篇，深入 Kafka 的架构设计、存储机制、生产者/消费者模型和 .NET 实战。前置知识：消息队列核心概念（第一篇）。

一、Kafka 架构

1.1 整体架构

Producer → Broker Cluster → Consumer Group
              ↑
         ZooKeeper / KRaft（元数据管理）

核心组件：
- Broker       — Kafka 服务器节点
- Topic        — 消息分类（逻辑概念）
- Partition    — Topic 的物理分片
- Replica      — Partition 的副本
- Producer     — 消息生产者
- Consumer     — 消息消费者
- Consumer Group — 消费者组
- ZooKeeper/KRaft — 集群元数据和协调

1.2 和 RabbitMQ 的本质区别

RabbitMQ：
  - 以 Queue 为中心
  - 消息消费后删除
  - 路由逻辑在 Exchange
  - Push 模式

Kafka：
  - 以 Topic/Partition 为中心
  - 消息持久化，保留一段时间
  - 路由逻辑在 Producer（决定发到哪个 Partition）
  - Pull 模式
  - 设计目标是高吞吐的分布式日志系统

1.3 消息流转过程

1. Producer 决定消息发到哪个 Topic 的哪个 Partition
2. Partition Leader 接收并写入本地日志
3. Follower 从 Leader 拉取并复制
4. Consumer Group 中的 Consumer 各自消费分配到的 Partition
5. Consumer 定期提交 Offset 记录消费进度

二、Topic 和 Partition

2.1 Partition 的作用

1. 并行处理    — 不同 Partition 可以被不同 Consumer 并行消费
2. 水平扩展    — 增加 Partition 提高吞吐量
3. 顺序保证    — 同一 Partition 内消息有序
4. 容错        — 每个 Partition 有多个副本

2.2 Partition 数量选择

考虑因素：
- 吞吐量需求    — Partition 越多，并行度越高
- Consumer 数量 — 一个 Partition 只能被 Consumer Group 中一个 Consumer 消费
- Broker 数量   — Partition 尽量均匀分布在各 Broker

经验值：
- 小规模：每个 Topic 3-6 个 Partition
- 中规模：每个 Topic 12-24 个 Partition
- 大规模：可以到几百个

注意：Partition 数量只能增不能减

2.3 Key 和 Partition 路由

Producer 发送消息时可以指定 Key：
- Key 为 null   — 轮询分配到不同 Partition（Round Robin）
- Key 不为 null  — 对 Key 做 Hash，相同 Key 到同一个 Partition

这保证了相同业务 ID 的消息（如同一订单）都在同一个 Partition，保持顺序

// 指定 Key 发送
var message = new Message<string, string>
{
    Key = $"order-{orderId}",    // 相同订单 ID → 同一 Partition
    Value = JsonSerializer.Serialize(orderEvent)
};

await producer.ProduceAsync("orders", message);

三、存储机制

3.1 日志追加（Append-Only Log）

Kafka 的核心存储设计：

每个 Partition 是一个追加写入的日志文件：
Offset  Message
0       {"orderId":1,"action":"created"}
1       {"orderId":1,"action":"paid"}
2       {"orderId":2,"action":"created"}
3       {"orderId":1,"action":"shipped"}
...

特点：
- 顺序写磁盘 → 极快（600MB/s 顺序写 vs 100KB/s 随机写）
- 不可修改 → 只能追加
- 通过 Offset 随机读取

3.2 Segment 分段

一个 Partition 由多个 Segment 组成：

Partition (topic-order-0/)
├── 00000000000000000000.log     ← Segment 1（Offset 0 开始）
├── 00000000000000000000.index   ← 偏移量索引
├── 00000000000000000000.timeindex ← 时间索引
├── 00000000000000000036.log     ← Segment 2（Offset 36 开始）
├── 00000000000000000036.index
└── 00000000000000000036.timeindex

Segment 滚动条件：
- 达到 1GB（log.segment.bytes）
- 达到 7 天（log.segment.ms）

好处：
- 快速定位消息（二分查找 Segment + 索引）
- 方便清理过期数据（删除整个 Segment）

3.3 零拷贝（Zero-Copy）

传统数据传输（4 次拷贝）：
  磁盘 → 内核缓冲区 → 用户空间 → Socket 缓冲区 → 网卡

Kafka 零拷贝（2 次拷贝）：
  磁盘 → 内核缓冲区 → 网卡

通过 Java 的 FileChannel.transferTo()（Linux 的 sendfile 系统调用）
配合页缓存（Page Cache），Kafka 极少做用户空间的数据拷贝

3.4 页缓存（Page Cache）

Kafka 不自己管理缓存，而是利用操作系统的页缓存：
- 写入时先写页缓存，由 OS 异步刷盘
- 读取时先从页缓存读，命中就不用访问磁盘
- 生产者和消费者访问的是同一块页缓存（热数据在内存中）

这就是 Kafka 高吞吐的关键：顺序写 + 页缓存 + 零拷贝

3.5 数据保留和清理

保留策略（二选一）：
- 按时间：log.retention.hours=168（默认 7 天）
- 按大小：log.retention.bytes=1073741824（1GB）

清理策略：
- delete    — 删除整个 Segment（默认）
- compact   — 保留每个 Key 的最新值（适合 changelog）

Compact 示例：
  写入：key=user1, value=张三
  写入：key=user2, value=李四
  写入：key=user1, value=王五（更新）
  Compact 后只保留：
    key=user1, value=王五
    key=user2, value=李四

四、生产者

4.1 发送模式

// 1. 发后即忘（Fire and Forget）— 最快，可能丢
producer.Produce("orders", message);

// 2. 同步发送 — 等待 ACK，最慢但最安全
var result = await producer.ProduceAsync("orders", message);
Console.WriteLine($"Offset: {result.Offset}");

// 3. 异步发送 + 回调 — 推荐，兼顾性能和可靠性
producer.Produce("orders", message, report =>
{
    if (report.Error.Code != ErrorCode.NoError)
        logger.LogError("发送失败：{Error}", report.Error.Reason);
    else
        logger.LogInformation("发送成功：Partition={Partition}, Offset={Offset}",
            report.Partition, report.Offset);
});

4.2 ACK 配置

var config = new ProducerConfig
{
    BootstrapServers = "localhost:9092",
    Acks = Acks.All,  // 等同于 acks=all
    // Acks.None     — 不等 ACK（最快，可能丢）
    // Acks.Leader   — Leader 写入就返回（默认）
    // Acks.All      — 所有 ISR 副本都写入（最安全）
};

4.3 批量发送和缓冲

var config = new ProducerConfig
{
    BootstrapServers = "localhost:9092",

    // 批量大小（字节）
    BatchSize = 16384,          // 16KB

    // 等待时间（毫秒）— 攒够一批或超时就发
    LingerMs = 5,               // 5ms

    // 缓冲区大小
    BufferMemory = 33554432,    // 32MB

    // 压缩
    CompressionType = CompressionType.Lz4,

    // 重试
    MessageSendMaxRetries = 3,
    RetryBackoffMs = 100,
};

批量发送原理：
  Producer 内部有一个缓冲区：
  - 消息先写入缓冲区
  - 攒够一个 Batch（BatchSize）或等待超时（LingerMs）就发送
  - 大幅减少网络请求次数

LingerMs 和 BatchSize 的权衡：
  LingerMs 大 → 批更大但延迟高
  LingerMs 小 → 批更小但延迟低
  建议：LingerMs=5-20ms，BatchSize=16-64KB

4.4 幂等生产者

var config = new ProducerConfig
{
    BootstrapServers = "localhost:9092",
    Acks = Acks.All,
    EnableIdempotence = true,   // 开启幂等（自动设置 acks=all）

    // 幂等生产者保证：
    // 即使网络重试，同一条消息也只写入一次
    // 通过 Producer ID + Sequence Number 去重
    // 注意：只保证单分区的单会话幂等
};

五、消费者

5.1 Consumer Group

核心概念：
- 一个 Consumer Group 中的 Consumer 共同消费一个 Topic
- 每个 Partition 只被 Group 中的一个 Consumer 消费
- 不同 Group 各自独立消费（发布订阅）

示例：
  Topic "orders" 有 3 个 Partition

  Group "sms-group"：
    Consumer-1 → Partition-0
    Consumer-2 → Partition-1
    Consumer-3 → Partition-2

  Group "points-group"：
    Consumer-A → Partition-0, 1, 2（只有一个 Consumer，消费所有）

注意：
- Consumer 数量 > Partition 数量 → 多余的 Consumer 空闲
- Consumer 数量 < Partition 数量 → 有的 Consumer 消费多个 Partition

5.2 Offset 管理

Offset：消息在 Partition 中的位置（从 0 递增）

消费进度管理：
- Consumer 定期提交已消费的 Offset
- 重启后从上次提交的 Offset 继续消费

提交方式：
1. 自动提交（enable.auto.commit=true）
   - 定期自动提交（默认 5 秒）
   - 可能重复消费（处理完但没提交就挂了）
   - 简单但不可靠

2. 手动提交（enable.auto.commit=false）
   - 处理完业务后手动调用 Commit
   - 更可靠但代码更复杂

// 手动提交
var config = new ConsumerConfig
{
    BootstrapServers = "localhost:9092",
    GroupId = "order-sms-group",
    EnableAutoCommit = false,           // 关闭自动提交
    AutoOffsetReset = AutoOffsetReset.Earliest  // 无 Offset 时从头开始
};

using var consumer = new ConsumerBuilder<string, string>(config).Build();
consumer.Subscribe("orders");

while (!cancellationToken.IsCancellationRequested)
{
    var result = consumer.Consume(CancellationToken.None);

    try
    {
        // 处理业务
        await ProcessOrder(result.Message.Value);

        // 处理成功，提交 Offset
        consumer.Commit(result);
    }
    catch (Exception ex)
    {
        logger.LogError(ex, "处理失败，不提交 Offset");
        // 不提交，下次重启会重新消费
    }
}

5.3 Rebalance

Consumer Group 中 Consumer 变化时触发 Rebalance：
- 新 Consumer 加入
- Consumer 离开（崩溃、关闭）
- 订阅的 Topic Partition 数量变化

Rebalance 过程：
1. 所有 Consumer 撤回分配的 Partition
2. 重新分配 Partition 给各 Consumer
3. 各 Consumer 从新分配的 Partition 继续

Rebalance 的问题：
- 短暂的消费暂停（Stop The World）
- 可能重复消费（Rebalance 前 Commit 了吗？）
- 频繁 Rebalance 影响性能

减少 Rebalance：
- 合理设置 session.timeout.ms（默认 45s）
- 合理设置 heartbeat.interval.ms（默认 3s）
- 避免消费者处理太慢（超过 session.timeout 会被踢出）
- 使用 CooperativeStickyAssignor（增量 Rebalance）

5.4 消费者配置

var config = new ConsumerConfig
{
    BootstrapServers = "localhost:9092",
    GroupId = "order-sms-group",

    // Offset 提交
    EnableAutoCommit = false,

    // 无 Offset 时从哪里开始
    AutoOffsetReset = AutoOffsetReset.Earliest,  // 最早
    // AutoOffsetReset.Latest   — 最新的
    // AutoOffsetReset.Error    — 报错

    // 心跳和超时
    SessionTimeoutMs = 30000,       // 30 秒无心跳认为挂了
    HeartbeatIntervalMs = 3000,     // 3 秒发一次心跳
    MaxPollIntervalMs = 300000,     // 两次 poll 最大间隔（5 分钟）

    // 拉取配置
    FetchMinBytes = 1,              // 最少拉取 1 字节
    FetchMaxWaitMs = 500,           // 最多等 500ms
    MaxPartitionFetchBytes = 1048576, // 每个 Partition 最多拉 1MB
};

六、副本和高可用

6.1 副本机制

每个 Partition 有多个 Replica：
- Leader Replica    — 处理读写请求
- Follower Replica  — 从 Leader 复制数据，不处理客户端请求

副本因子（replication.factor）：
- 通常设为 3（1 Leader + 2 Follower）
- 不同 Broker 上各放一个副本

ISR（In-Sync Replicas）：
- 和 Leader 保持同步的副本集合
- Follower 落后太多会被移出 ISR
- Leader 挂了，从 ISR 中选新 Leader

6.2 Leader 选举

Leader 挂了时：
1. Controller（集群中的一个 Broker）检测到
2. 从 ISR 中选一个 Follower 作为新 Leader
3. 通知所有 Broker 和 Consumer

配置：
  unclean.leader.election.enable=false（默认）
  → 只允许 ISR 中的副本成为 Leader（安全）
  → 如果 ISR 为空，Partition 不可用

  unclean.leader.election.enable=true（不推荐）
  → 允许非 ISR 副本成为 Leader
  → 可用性更高但可能丢数据

6.3 副本配置

# Topic 级别配置
kafka-topics.sh --create \
  --topic orders \
  --partitions 6 \
  --replication-factor 3 \
  --config min.insync.replicas=2

# min.insync.replicas=2 配合 acks=all
# → 至少 2 个副本（含 Leader）写入成功才返回
# → 3 个副本容忍 1 个宕机

七、Kafka 事务

7.1 Exactly-Once 语义

Kafka 事务保证：
- 原子性：一批消息要么全部成功要么全部失败
- 跨 Partition：可以同时写入多个 Partition
- 消费-处理-生产：从 Topic A 消费，处理完写入 Topic B，整个流程 Exactly-Once

7.2 事务生产者

var config = new ProducerConfig
{
    BootstrapServers = "localhost:9092",
    TransactionalId = "order-tx-producer-1",  // 事务 ID（必须唯一）
    EnableIdempotence = true,
    Acks = Acks.All
};

using var producer = new ProducerBuilder<string, string>(config).Build();
producer.InitTransactions(TimeSpan.FromSeconds(10));

try
{
    producer.BeginTransaction();

    // 发送多条消息到不同 Partition/Topic
    await producer.ProduceAsync("orders", new Message<string, string> { Key = "order-1", Value = "..." });
    await producer.ProduceAsync("payments", new Message<string, string> { Key = "pay-1", Value = "..." });

    // 提交事务
    producer.CommitTransaction(TimeSpan.FromSeconds(10));
}
catch
{
    // 回滚事务
    producer.AbortTransaction(TimeSpan.FromSeconds(10));
}

7.3 事务消费者

var config = new ConsumerConfig
{
    BootstrapServers = "localhost:9092",
    GroupId = "order-processor",
    IsolationLevel = IsolationLevel.ReadCommitted,
    // ReadCommitted  — 只读已提交的事务消息（推荐）
    // ReadUncommitted — 读所有消息包括未提交的
};

八、.NET 实战

8.1 使用 Confluent.Kafka

`1`	`dotnet add package Confluent.Kafka`

8.2 完整 Producer 封装

public class KafkaProducerService : IDisposable
{
    private readonly IProducer<string, string> _producer;
    private readonly ILogger<KafkaProducerService> _logger;

    public KafkaProducerService(IConfiguration config, ILogger<KafkaProducerService> logger)
    {
        _logger = logger;
        var producerConfig = new ProducerConfig
        {
            BootstrapServers = config["Kafka:BootstrapServers"],
            Acks = Acks.All,
            EnableIdempotence = true,
            LingerMs = 10,
            BatchSize = 32768,
            CompressionType = CompressionType.Lz4,
            MessageSendMaxRetries = 3,
            RetryBackoffMs = 100
        };

        _producer = new ProducerBuilder<string, string>(producerConfig).Build();
    }

    public async Task ProduceAsync<T>(string topic, string key, T value)
    {
        var message = new Message<string, string>
        {
            Key = key,
            Value = JsonSerializer.Serialize(value)
        };

        var result = await _producer.ProduceAsync(topic, message);

        _logger.LogDebug("发送到 {Topic} Partition:{Partition} Offset:{Offset}",
            topic, result.Partition, result.Offset);
    }

    public void Dispose() => _producer?.Dispose();
}

8.3 完整 Consumer 封装

public class KafkaConsumerService<T> : BackgroundService
{
    private readonly IConsumer<string, string> _consumer;
    private readonly ILogger<KafkaConsumerService<T>> _logger;
    private readonly Func<string, Task> _handler;
    private readonly string _topic;

    public KafkaConsumerService(
        IConfiguration config,
        ILogger<KafkaConsumerService<T>> logger,
        string topic,
        string groupId,
        Func<string, Task> handler)
    {
        _logger = logger;
        _handler = handler;
        _topic = topic;

        var consumerConfig = new ConsumerConfig
        {
            BootstrapServers = config["Kafka:BootstrapServers"],
            GroupId = groupId,
            EnableAutoCommit = false,
            AutoOffsetReset = AutoOffsetReset.Earliest,
            SessionTimeoutMs = 30000,
            MaxPollIntervalMs = 300000
        };

        _consumer = new ConsumerBuilder<string, string>(consumerConfig)
            .SetErrorHandler((_, e) => _logger.LogError("Kafka 错误：{Error}", e.Reason))
            .Build();
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _consumer.Subscribe(_topic);

        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                var result = _consumer.Consume(stoppingToken);

                await _handler(result.Message.Value);

                _consumer.Commit(result);
            }
            catch (ConsumeException ex)
            {
                _logger.LogError(ex, "消费异常");
            }
            catch (OperationCanceledException)
            {
                break;
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "处理消息异常");
                // 不提交，下次重新消费
            }
        }

        _consumer.Close();
    }

    public override void Dispose()
    {
        _consumer?.Dispose();
        base.Dispose();
    }
}

8.4 注册和使用

// 注册 Producer
builder.Services.AddSingleton<KafkaProducerService>();

// 注册 Consumer（BackgroundService）
builder.Services.AddHostedService(sp =>
    new KafkaConsumerService<OrderEvent>(
        sp.GetRequiredService<IConfiguration>(),
        sp.GetRequiredService<ILogger<KafkaConsumerService<OrderEvent>>>(),
        topic: "orders",
        groupId: "order-sms-group",
        handler: async (json) =>
        {
            var order = JsonSerializer.Deserialize<OrderEvent>(json);
            await SendSmsAsync(order!.CustomerEmail, "您的订单已创建");
        }));

九、常用运维命令

# Topic 管理
kafka-topics.sh --create --topic orders --partitions 6 --replication-factor 3 --bootstrap-server localhost:9092
kafka-topics.sh --list --bootstrap-server localhost:9092
kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092
kafka-topics.sh --alter --topic orders --partitions 12 --bootstrap-server localhost:9092  # 只能增

# 消费者组
kafka-consumer-groups.sh --list --bootstrap-server localhost:9092
kafka-consumer-groups.sh --describe --group order-sms-group --bootstrap-server localhost:9092

# 查看消费进度（LAG）
kafka-consumer-groups.sh --describe --group order-sms-group --bootstrap-server localhost:9092
# 输出：CURRENT-OFFSET  LOG-END-OFFSET  LAG
# LAG > 0 说明消费有积压

# 重置 Offset
kafka-consumer-groups.sh --reset-offsets --group order-sms-group --topic orders --to-earliest --execute --bootstrap-server localhost:9092

# 配置修改
kafka-configs.sh --alter --entity-type topics --entity-name orders --add-config retention.ms=604800000 --bootstrap-server localhost:9092

# 查看配置
kafka-configs.sh --describe --entity-type topics --entity-name orders --bootstrap-server localhost:9092

十、小结

本文深入学习了 Kafka：

架构（Broker、Topic、Partition、Consumer Group）
和 RabbitMQ 的本质区别
存储机制（追加日志、Segment、零拷贝、页缓存）
生产者（发送模式、ACK、批量、幂等）
消费者（Consumer Group、Offset、Rebalance）
副本和高可用
Kafka 事务和 Exactly-Once
.NET 实战（Confluent.Kafka）
运维常用命令

下一篇将对比 RabbitMQ 和 Kafka，帮助你在实际项目中做出选型。

消息队列（二）：RabbitMQ 深入

Sat, 23 May 2026 10:00:00 +0800

写在前面

本文是消息队列系列的第二篇，深入 RabbitMQ 的架构、Exchange 路由、可靠性保证和 .NET 实战。前置知识：消息队列核心概念（第一篇）。

一、RabbitMQ 架构

1.1 整体架构

Producer → Exchange → Binding → Queue → Consumer
                        ↑
                     Routing Key

核心组件：
- Connection    — TCP 连接
- Channel       — 连接内的轻量级通道（一个连接多路复用）
- Virtual Host  — 逻辑隔离（类似数据库的 Schema）
- Exchange      — 消息路由器
- Queue         — 消息存储
- Binding       — Exchange 和 Queue 的绑定规则

1.2 消息流转过程

1. Producer 创建消息，指定 Exchange 和 Routing Key
2. Exchange 根据 Binding 规则路由到一个或多个 Queue
3. Queue 存储消息（如果持久化则写入磁盘）
4. Consumer 从 Queue 中消费消息
5. Consumer 处理完后发送 ACK
6. Queue 收到 ACK 后删除消息

1.3 Virtual Host

一个 RabbitMQ 实例可以有多个 VHost，互相隔离：
/         — 默认 VHost
/dev      — 开发环境
/staging  — 预发环境
/prod     — 生产环境

每个 VHost 有独立的：
- Exchange
- Queue
- Binding
- 用户权限

二、Exchange 详解

2.1 Direct Exchange

精确匹配 Routing Key。

Producer → [Exchange] → Queue "order-created"（key="order.created"）
                        → Queue "order-cancelled"（key="order.cancelled"）

只有 Routing Key 完全匹配才会路由到对应 Queue

// 声明 Exchange
channel.ExchangeDeclare("order.exchange", ExchangeType.Direct);

// 声明 Queue
channel.QueueDeclare("order-created", durable: true, exclusive: false, autoDelete: false, arguments: null);
channel.QueueDeclare("order-cancelled", durable: true, exclusive: false, autoDelete: false, arguments: null);

// 绑定
channel.QueueBind("order-created", "order.exchange", "order.created");
channel.QueueBind("order-cancelled", "order.exchange", "order.cancelled");

// 发送
channel.BasicPublish("order.exchange", "order.created", null, body);

2.2 Fanout Exchange

忽略 Routing Key，广播到所有绑定的 Queue。

Producer → [Exchange] → Queue A（短信）
                        → Queue B（积分）
                        → Queue C（通知）

所有 Queue 都会收到消息，不管 Routing Key 是什么

channel.ExchangeDeclare("order.fanout", ExchangeType.Fanout);

channel.QueueDeclare("sms-queue", durable: true, exclusive: false, autoDelete: false, null);
channel.QueueDeclare("points-queue", durable: true, exclusive: false, autoDelete: false, null);
channel.QueueDeclare("notify-queue", durable: true, exclusive: false, autoDelete: false, null);

// Fanout 绑定不需要 routing key
channel.QueueBind("sms-queue", "order.fanout", "");
channel.QueueBind("points-queue", "order.fanout", "");
channel.QueueBind("notify-queue", "order.fanout", "");

2.3 Topic Exchange

通配符匹配 Routing Key。

Routing Key 格式：用 . 分隔的单词，如 order.created.payment

通配符：
  * 匹配一个单词
  # 匹配零或多个单词

示例：
  order.*       → 匹配 order.created, order.cancelled
  order.#       → 匹配 order.created, order.created.payment, order.cancelled.refund
  *.created     → 匹配 order.created, user.created
  #             → 匹配所有（等同于 Fanout）

channel.ExchangeDeclare("order.topic", ExchangeType.Topic);

// 短信服务关心所有订单事件
channel.QueueBind("sms-queue", "order.topic", "order.*");

// 财务服务只关心支付相关
channel.QueueBind("finance-queue", "order.topic", "order.*.payment");

// 统计服务关心所有事件
channel.QueueBind("stats-queue", "order.topic", "#");

2.4 Headers Exchange

基于消息头匹配，忽略 Routing Key。

匹配模式：
- x-match=all    — 所有头部字段都匹配
- x-match=any    — 任一头部字段匹配

适用：复杂的多维度路由（实际使用较少，Topic 通常够用）

2.5 Exchange 类型选择

Direct   — 精确匹配，点对点或简单路由
Fanout   — 广播，所有消费者都要
Topic    — 模式匹配，灵活路由（最常用）
Headers  — 复杂条件匹配（性能差，少用）

三、消息可靠性保证

3.1 三个环节

1
2
3

生产端可靠性    — 确保消息成功到达 Broker
Broker 可靠性   — 确保消息在 Broker 中不丢
消费端可靠性    — 确保消息被正确处理

3.2 生产端：Publisher Confirm

// 开启 Confirm 模式
channel.ConfirmSelect();

// 发送消息
channel.BasicPublish("order.exchange", "order.created", null, body);

// 等待确认
channel.WaitForConfirmsOrDie(TimeSpan.FromSeconds(5));
// 成功 → 继续
// 超时 → 抛异常，可以重试

// 批量确认（性能更好）
for (int i = 0; i < 1000; i++)
{
    channel.BasicPublish("order.exchange", "order.created", null, bodies[i]);
}
channel.WaitForConfirms(); // 一次性确认所有

3.3 生产端：事务（不推荐）

// 事务模式（性能差，不推荐）
channel.TxSelect();
try
{
    channel.BasicPublish("order.exchange", "order.created", null, body);
    channel.TxCommit();
}
catch
{
    channel.TxRollback();
}

// Confirm 模式比事务快 10 倍以上，优先用 Confirm

3.4 Broker 端：持久化

三个层面都要持久化：

1. Exchange 持久化
   channel.ExchangeDeclare("order.exchange", ExchangeType.Direct, durable: true);

2. Queue 持久化
   channel.QueueDeclare("order-queue", durable: true, exclusive: false, autoDelete: false, null);

3. Message 持久化
   var props = channel.CreateBasicProperties();
   props.DeliveryMode = 2;  // 2 = 持久化
   channel.BasicPublish("order.exchange", "order.created", props, body);

注意：持久化影响性能，根据业务需求选择

3.5 消费端：手动 ACK

// 关闭自动确认
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
    try
    {
        var body = ea.Body.ToArray();
        var message = Encoding.UTF8.GetString(body);

        // 处理业务逻辑
        ProcessOrder(message);

        // 手动确认
        channel.BasicAck(ea.DeliveryTag, multiple: false);
    }
    catch (Exception ex)
    {
        // 处理失败
        // requeue=true → 重新入队（可能无限循环）
        // requeue=false → 丢弃或进死信
        channel.BasicNack(ea.DeliveryTag, multiple: false, requeue: false);
    }
};

// autoAck: false → 手动确认
channel.BasicConsume("order-queue", autoAck: false, consumer);

3.6 可靠性总结

消息不丢的完整配置：

生产端：
  ✓ Confirm 模式
  ✓ 持久化消息（DeliveryMode=2）
  ✓ 发送失败重试

Broker：
  ✓ Exchange 持久化（durable=true）
  ✓ Queue 持久化（durable=true）
  ✓ 队列镜像（HA Policy，集群模式）

消费端：
  ✓ 手动 ACK（autoAck=false）
  ✓ 处理完业务再 ACK
  ✓ 失败进死信队列

四、死信队列

4.1 死信产生条件

1
2
3

1. 消费者 nack/reject 且 requeue=false
2. 消息 TTL 过期
3. 队列达到最大长度

4.2 配置死信队列

// 业务队列：指定死信交换机
var args = new Dictionary<string, object>
{
    { "x-dead-letter-exchange", "order.dlx" },
    { "x-dead-letter-routing-key", "order.dead" }
};
channel.QueueDeclare("order-queue", durable: true, exclusive: false, autoDelete: false, args);

// 死信交换机和队列
channel.ExchangeDeclare("order.dlx", ExchangeType.Direct);
channel.QueueDeclare("order-dead-queue", durable: true, exclusive: false, autoDelete: false, null);
channel.QueueBind("order-dead-queue", "order.dlx", "order.dead");

4.3 死信处理

// 消费死信队列
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
    var body = ea.Body.ToArray();
    var message = Encoding.UTF8.GetString(body);

    // 记录失败原因
    var reason = ea.BasicProperties.Headers["x-death"] as List<object>;
    logger.LogError("消息进入死信：{Message}, 原因：{Reason}", message, reason);

    // 告警通知
    alertService.Notify($"消息处理失败：{message}");

    channel.BasicAck(ea.DeliveryTag, false);
};
channel.BasicConsume("order-dead-queue", autoAck: false, consumer);

五、延迟消息

5.1 TTL + DLX 方案

原理：
  消息设置 TTL → 过期后进入死信队列 → 消费者消费死信队列

流程：
  Producer → Queue（TTL=30min, DLX=order.dlx）
                                    ↓ 过期
           order.dlx → dead-queue → Consumer

实现订单 30 分钟未支付自动取消

// 延迟队列：消息过期后进入死信
var delayArgs = new Dictionary<string, object>
{
    { "x-dead-letter-exchange", "order.dlx" },
    { "x-dead-letter-routing-key", "order.timeout" },
    { "x-message-ttl", 1800000 }  // 30 分钟（毫秒）
};
channel.QueueDeclare("order-wait-queue", durable: true, exclusive: false, autoDelete: false, delayArgs);

// 死信交换机和消费队列
channel.ExchangeDeclare("order.dlx", ExchangeType.Direct);
channel.QueueDeclare("order-timeout-queue", durable: true, exclusive: false, autoDelete: false, null);
channel.QueueBind("order-timeout-queue", "order.dlx", "order.timeout");

// 发送延迟消息
channel.BasicPublish("", "order-wait-queue", null, orderBody);
// 30 分钟后，消息过期进入 order-timeout-queue 被消费

5.2 延迟消息插件

1
2

# 安装 rabbitmq_delayed_message_exchange 插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

// 使用延迟插件（更灵活，支持每条消息不同延迟）
var args = new Dictionary<string, object>
{
    { "x-delayed-type", "direct" }
};
channel.ExchangeDeclare("order.delay", "x-delayed-message", durable: true, arguments: args);

// 发送时指定延迟时间
var props = channel.CreateBasicProperties();
props.Headers = new Dictionary<string, object>
{
    { "x-delay", 60000 }  // 延迟 60 秒
};
channel.BasicPublish("order.delay", "order.timeout", props, body);

六、.NET 实战

6.1 使用 RabbitMQ.Client

`1`	`dotnet add package RabbitMQ.Client`

6.2 封装 Producer

public class RabbitMqProducer : IDisposable
{
    private readonly IConnection _connection;
    private readonly IModel _channel;

    public RabbitMqProducer(string connectionString)
    {
        var factory = new ConnectionFactory
        {
            Uri = new Uri(connectionString),
            AutomaticRecoveryEnabled = true,     // 自动重连
            NetworkRecoveryInterval = TimeSpan.FromSeconds(5)
        };

        _connection = factory.CreateConnection();
        _channel = _connection.CreateModel();

        // 开启 Confirm 模式
        _channel.ConfirmSelect();
    }

    public void Publish(string exchange, string routingKey, string message)
    {
        var body = Encoding.UTF8.GetBytes(message);

        var props = _channel.CreateBasicProperties();
        props.DeliveryMode = 2;               // 持久化
        props.ContentType = "application/json";
        props.MessageId = Guid.NewGuid().ToString();

        _channel.BasicPublish(exchange, routingKey, props, body);
        _channel.WaitForConfirmsOrDie(TimeSpan.FromSeconds(5));
    }

    public void Dispose()
    {
        _channel?.Dispose();
        _connection?.Dispose();
    }
}

6.3 封装 Consumer

public class RabbitMqConsumer : IDisposable
{
    private readonly IConnection _connection;
    private readonly IModel _channel;

    public RabbitMqConsumer(string connectionString)
    {
        var factory = new ConnectionFactory
        {
            Uri = new Uri(connectionString),
            AutomaticRecoveryEnabled = true,
            DispatchConsumersAsync = true  // 异步消费
        };

        _connection = factory.CreateConnection();
        _channel = _connection.CreateModel();

        // QoS：每次只推 N 条消息（防止消费者积压）
        _channel.BasicQos(prefetchSize: 0, prefetchCount: 10, global: false);
    }

    public void Subscribe(string queue, Func<string, Task> onMessage)
    {
        var consumer = new AsyncEventingBasicConsumer(_channel);

        consumer.Received += async (model, ea) =>
        {
            try
            {
                var body = ea.Body.ToArray();
                var message = Encoding.UTF8.GetString(body);

                await onMessage(message);

                _channel.BasicAck(ea.DeliveryTag, false);
            }
            catch (Exception ex)
            {
                // 重试次数判断
                var retryCount = GetRetryCount(ea);
                if (retryCount < 3)
                {
                    // 重新入队
                    _channel.BasicNack(ea.DeliveryTag, false, requeue: true);
                }
                else
                {
                    // 进入死信
                    _channel.BasicNack(ea.DeliveryTag, false, requeue: false);
                }
            }
        };

        _channel.BasicConsume(queue, autoAck: false, consumer);
    }

    private int GetRetryCount(BasicDeliverEventArgs ea)
    {
        if (ea.BasicProperties.Headers?.ContainsKey("x-death") == true)
        {
            var death = ea.BasicProperties.Headers["x-death"] as List<object>;
            return death?.Count ?? 0;
        }
        return 0;
    }

    public void Dispose()
    {
        _channel?.Dispose();
        _connection?.Dispose();
    }
}

6.4 使用 MassTransit（更高级的封装）

`1`	`dotnet add package MassTransit.RabbitMQ`

// 注册
builder.Services.AddMassTransit(x =>
{
    x.AddConsumer<OrderCreatedConsumer>();

    x.UsingRabbitMq((context, cfg) =>
    {
        cfg.Host("localhost", "/", h =>
        {
            h.Username("guest");
            h.Password("guest");
        });

        // 配置重试
        cfg.UseMessageRetry(r => r.Exponential(3,
            TimeSpan.FromSeconds(1),
            TimeSpan.FromSeconds(30),
            TimeSpan.FromSeconds(5)));

        // 配置死信
        cfg.ConfigureEndpoints(context);
    });
});

// 消费者
public class OrderCreatedConsumer : IConsumer<OrderCreatedEvent>
{
    private readonly ILogger<OrderCreatedConsumer> _logger;

    public OrderCreatedConsumer(ILogger<OrderCreatedConsumer> logger) => _logger = logger;

    public async Task Consume(ConsumeContext<OrderCreatedEvent> context)
    {
        _logger.LogInformation("收到订单创建事件：{OrderId}", context.Message.OrderId);

        // 处理业务逻辑
        await SendSmsAsync(context.Message);
    }
}

// 生产者
public class OrderService
{
    private readonly IPublishEndpoint _publishEndpoint;

    public OrderService(IPublishEndpoint publishEndpoint) => _publishEndpoint = publishEndpoint;

    public async Task CreateOrderAsync(Order order)
    {
        // 保存订单...

        // 发布事件
        await _publishEndpoint.Publish(new OrderCreatedEvent
        {
            OrderId = order.Id,
            CustomerEmail = order.CustomerEmail,
            Total = order.Total
        });
    }
}

七、集群和高可用

7.1 集群模式

普通集群：
  - Queue 只存在于一个节点
  - 其他节点可以转发消费请求
  - 节点挂了，Queue 不可用

镜像队列（Classic Queue Mirroring）：
  - Queue 在多个节点有副本
  - 主节点写入，同步到从节点
  - 主节点挂了，从节点自动提升

Quorum Queue（仲裁队列，推荐）：
  - RabbitMQ 3.8+ 新模式
  - 基于 Raft 协议实现一致性
  - 替代镜像队列，性能和可靠性更好

7.2 Quorum Queue 配置

// 声明仲裁队列
var args = new Dictionary<string, object>
{
    { "x-queue-type", "quorum" }
};
channel.QueueDeclare("order-queue", durable: true, exclusive: false, autoDelete: false, args);

八、性能调优

8.1 生产端优化

批量发送        — 减少 RTT，一次发送多条
Confirm 批量确认 — 多条消息一起确认
异步 Confirm    — 注册回调处理 ACK/NACK
连接池           — 复用 Connection 和 Channel

8.2 消费端优化

Prefetch Count  — 控制一次性推送的消息数
                  太小 → 吞吐量低
                  太大 → 消费者积压
                  建议：10-100，根据处理速度调整

多消费者        — 一个 Queue 多个 Consumer 并行消费
多 Channel      — 一个 Connection 多个 Channel
手动 ACK        — 避免处理一半自动确认

8.3 Broker 端优化

消息持久化权衡  — 持久化慢但安全，非持久化快但可能丢
惰性队列        — 消息直接写磁盘，内存占用低，适合百万级堆积
流控            — 内存/磁盘告警时限制生产者发送速度
节点数量        — 3-5 个节点，兼顾可用性和性能

九、运维常用操作

# 用户管理
rabbitmqctl add_user admin password
rabbitmqctl set_user_tags admin administrator
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"

# 队列管理
rabbitmqctl list_queues name messages consumers
rabbitmqctl list_queues name durable auto_delete

# 交换机
rabbitmqctl list_exchanges name type

# 连接和通道
rabbitmqctl list_connections
rabbitmqctl list_channels

# 集群状态
rabbitmqctl cluster_status

# 插件
rabbitmq-plugins enable rabbitmq_management    # Web 管理界面
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

# Web 管理界面
# http://localhost:15672
# 默认账号：guest / guest（只能本地访问）

十、小结

本文深入学习了 RabbitMQ：

架构（Connection、Channel、VHost、Exchange、Queue、Binding）
五种 Exchange 类型和路由规则
消息可靠性保证（Confirm、持久化、手动 ACK）
死信队列和延迟消息
.NET 实战（RabbitMQ.Client、MassTransit）
集群高可用（镜像队列、Quorum Queue）
性能调优

下一篇将深入 Kafka：架构、存储、生产者/消费者和 .NET 实战。

消息队列（一）：核心概念

Fri, 22 May 2026 10:00:00 +0800

写在前面

本文是消息队列系列的第一篇，介绍消息队列的核心概念、常见模式和可靠性保证机制。这些知识是理解 RabbitMQ 和 Kafka 的基础。

一、为什么需要消息队列

1.1 同步调用的问题

用户下单流程（同步）：
1. 创建订单        200ms
2. 扣减库存        150ms
3. 发送短信通知    300ms
4. 发放积分        100ms
5. 更新搜索引擎    200ms

总耗时：950ms

问题：
- 用户等了近 1 秒才看到结果
- 短信服务挂了，下单也失败
- 新增下游业务需要改下单代码
- 秒杀时流量直接打到数据库

1.2 异步解耦

用户下单流程（异步）：
1. 创建订单        200ms
2. 发送消息到 MQ   5ms

总耗时：205ms（用户感知）

MQ 下游各自消费：
- 短信服务 → 消费消息 → 发短信
- 积分服务 → 消费消息 → 发积分
- 搜索服务 → 消费消息 → 更新索引

1.3 三大核心作用

1
2
3

异步处理    — 非核心逻辑异步化，降低响应时间
系统解耦    — 上游不依赖下游，各自独立演进
流量削峰    — 突发流量堆积在 MQ，后端按能力消费

二、消息模型

2.1 点对点模式（Point-to-Point）

Producer → Queue → Consumer

特点：
- 一条消息只能被一个消费者消费
- 消费后从队列中移除
- 适用：任务分发（一个任务只执行一次）

示例：订单系统中，一个订单只被一个发货服务处理

2.2 发布订阅模式（Pub/Sub）

                  → Consumer A（短信服务）
Producer → Topic  → Consumer B（积分服务）
                  → Consumer C（搜索服务）

特点：
- 一条消息被所有订阅者消费
- 每个消费者有自己的消费进度
- 适用：事件通知（一个事件触发多个动作）

示例：订单创建后，短信、积分、搜索各做各的

2.3 两种模型对比

点对点         — 一消息一消费，消费即删除，适合任务分发
发布订阅       — 一消息多消费，各自维护进度，适合事件广播

RabbitMQ      — 以 Queue 为中心，通过 Exchange 实现两种模式
Kafka         — 以 Topic/Partition 为中心，天然发布订阅

三、核心概念详解

3.1 Producer（生产者）

职责：创建消息并发送到 MQ

关键决策：
- 发到哪个 Topic/Queue？
- 消息格式是什么？（JSON、Protobuf、Avro）
- 发送失败怎么处理？（重试、记录、告警）
- 要保证消息不丢吗？（确认机制）

3.2 Consumer（消费者）

职责：从 MQ 拉取消息并处理

关键决策：
- 推模式（Push）还是拉模式（Pull）？
  - Push：MQ 主动推给消费者（RabbitMQ 默认）
  - Pull：消费者主动拉取（Kafka 默认）
- 处理失败怎么处理？（重试、死信）
- 消费进度怎么管理？（自动提交 vs 手动提交）

3.3 Broker（消息代理）

MQ 服务器本身，负责：
- 接收和存储消息
- 路由消息到正确的队列
- 管理消费者连接
- 持久化和副本

RabbitMQ：一个 Broker 就是一个 RabbitMQ Server
Kafka：一个集群有多个 Broker，每个 Broker 管理一部分 Partition

3.4 Queue 和 Topic

Queue（队列）：
  - RabbitMQ 的核心实体
  - FIFO 顺序（默认）
  - 消息被消费后删除（默认）
  - 可以设置 TTL、死信等

Topic（主题）：
  - Kafka 的核心实体
  - 一个 Topic 分为多个 Partition
  - 消息持久化，不会因消费而删除
  - 可以被多个 Consumer Group 各自消费

Partition（分区）：
  - Topic 的物理分片
  - 每个 Partition 内消息有序
  - 不同 Partition 可以并行消费
  - 是 Kafka 高吞吐的关键

3.5 消息结构

一条消息包含：

消息头（Metadata）：
  - Topic / Queue 名称
  - Key（路由键）
  - 时间戳
  - 消息 ID

消息体（Payload）：
  - 实际的业务数据
  - JSON / Protobuf / 二进制

属性：
  - 优先级
  - 过期时间（TTL）
  - 持久化标志

四、消息路由模式

4.1 直连路由（Direct）

Producer → Exchange → Queue（routing key 完全匹配）

示例：
  routing key = "order.created" → 订单队列
  routing key = "order.cancelled" → 取消队列

4.2 主题路由（Topic）

Producer → Exchange → Queue（routing key 模式匹配）

支持通配符：
  * 匹配一个单词
  # 匹配零或多个单词

示例：
  "order.*"       匹配 order.created、order.cancelled
  "order.#"       匹配 order.created.payment、order.cancelled.refund
  "*.created"     匹配 order.created、user.created

4.3 广播路由（Fanout）

Producer → Exchange → 所有绑定的 Queue（忽略 routing key）

示例：
  订单创建事件 → 同时发送到短信队列、积分队列、统计队列

4.4 头部路由（Headers）

1
2

不基于 routing key，而是基于消息头部的键值对匹配
比 Topic 更灵活，但性能更低，实际使用较少

五、消息确认机制

5.1 为什么需要确认

消息在传输过程中可能丢失的场景：

生产者 → Broker：
  网络抖动，消息没到 Broker

Broker 内部：
  Broker 宕机，内存中的消息丢失

Broker → 消费者：
  消费者拿到消息后崩溃，消息丢了

每一步都需要确认机制来保证不丢

5.2 生产者确认

RabbitMQ：Publisher Confirm
  - 消息成功写入 Broker 后，Broker 回复 ACK
  - 生产者收到 ACK 才认为发送成功
  - 可以批量确认提高性能

Kafka：acks 配置
  - acks=0     — 发出去就不管了（最快，可能丢）
  - acks=1     — Leader 写入成功就返回（默认）
  - acks=all   — 所有副本都写入才返回（最安全）

5.3 消费者确认

RabbitMQ：Consumer ACK
  - 自动确认（autoAck=true）— 消息发出就确认，可能丢
  - 手动确认（autoAck=false）— 处理完业务后调用 basic.ack
  - 拒绝（nack/reject）— 处理失败，可以重入队列或进死信

Kafka：Offset Commit
  - 自动提交 — 定期提交 offset，可能重复消费
  - 手动提交 — 处理完业务后提交 offset
  - 同步提交 — 阻塞等待提交成功
  - 异步提交 — 不阻塞，性能更好但可能丢提交

六、持久化

6.1 为什么需要持久化

1
2
3

MQ 默认把消息存在内存中：
- Broker 重启后消息全部丢失
- 生产环境必须考虑持久化

6.2 持久化层次

RabbitMQ：
  - Exchange 持久化    — 声明时设置 durable=true
  - Queue 持久化       — 声明时设置 durable=true
  - Message 持久化     — 发送时设置 delivery_mode=2
  - 三者缺一不可，少一个重启后就丢了

Kafka：
  - 天然持久化到磁盘（追加写日志）
  - 通过副本（Replica）保证高可用
  - 副本因子（replication.factor）通常设为 3
  - 数据保留策略：按时间（如 7 天）或按大小

七、重试和死信

7.1 消费失败的处理

消费者处理消息可能失败：
- 网络超时
- 数据库暂时不可用
- 业务校验失败
- 代码 Bug

处理策略：
1. 重试    — 失败后重新消费（适用于临时性故障）
2. 死信    — 重试多次后放入死信队列（永久性故障）
3. 丢弃    — 明确不需要的消息直接丢弃

7.2 重试策略

立即重试       — 适合瞬时故障（网络抖动）
延迟重试       — 指数退避（1s, 2s, 4s, 8s...）
固定次数       — 超过 N 次进入死信
无限重试       — 不推荐，可能阻塞消费

7.3 死信队列（DLQ）

死信产生条件：
1. 消息被拒绝（nack/reject）且不重入队列
2. 消息 TTL 过期
3. 队列满了，无法放入新消息

死信处理：
- 人工排查修复
- 定时任务重新投递
- 告警通知
- 永久记录用于审计

八、消息顺序性

8.1 为什么顺序重要

场景：订单状态变更
  创建 → 支付 → 发货

如果消费乱序：
  先消费"发货" → 订单状态变为"已发货"
  再消费"创建" → 订单状态回退到"待支付"

业务出错！

8.2 保证顺序的方法

RabbitMQ：
  - 一个 Queue 只有一个 Consumer → 保证顺序但牺牲并发
  - 或者用 priority + 去重 → 复杂但可并发

Kafka：
  - 同一个 Partition 内消息有序
  - 相同 Key 的消息发到同一个 Partition
  - 每个 Partition 只被 Consumer Group 中一个 Consumer 消费
  - 所以：相同业务 Key 的消息全局有序

最佳实践：
  - 需要顺序的消息用相同 Key（如订单 ID）
  - 不同 Key 的消息可以并行处理

九、消息幂等性

9.1 为什么需要幂等

消息可能被重复消费：
- 生产者重试导致重复发送
- 消费者处理完但 ACK 失败，MQ 重新投递
- Rebalance 后重复消费

如果消费逻辑不幂等：
  发送短信 → 收到两条
  扣减余额 → 扣了两次
  发放积分 → 发了两次

9.2 幂等方案

方案1：数据库唯一约束
  用消息 ID 作为唯一键，重复插入会失败

方案2：乐观锁/版本号
  UPDATE account SET balance = balance - 100, version = version + 1
  WHERE id = 123 AND version = 5

方案3：状态机
  只有特定状态才能转换
  订单是"待支付"才能执行"支付成功"

方案4：去重表
  消费前先查去重表，处理过就跳过
  用消息 ID + 业务类型作为唯一键

方案5：Kafka 事务 / RabbitMQ 幂等生产者
  框架层面保证

十、消息投递语义

10.1 三种语义

At Most Once（最多一次）    — 消息可能丢，但不会重复
  先提交 offset，再处理消息
  适用：日志、监控数据（丢了无所谓）

At Least Once（至少一次）  — 消息不会丢，但可能重复
  先处理消息，再提交 offset
  适用：大部分业务场景（配合幂等使用）

Exactly Once（精确一次）   — 消息不丢不重复
  需要事务支持
  适用：金融、支付（不能多也不能少）

10.2 各 MQ 支持

RabbitMQ：
  默认 At Least Once
  通过事务或 Publisher Confirm 实现可靠投递
  Exactly Once 需要业务层配合（幂等）

Kafka：
  默认 At Least Once
  通过幂等生产者（enable.idempotence=true）实现 Exactly Once
  通过 Kafka 事务实现跨分区的 Exactly Once

十一、常见消息模式

11.1 工作队列（Work Queue）

Producer → Queue → Consumer 1
                 → Consumer 2
                 → Consumer 3

多个消费者竞争消费，一条消息只被处理一次
适用：任务分发、耗时操作

11.2 发布订阅（Pub/Sub）

Producer → Topic → Consumer A
                 → Consumer B
                 → Consumer C

一条消息被所有消费者处理
适用：事件通知、数据同步

11.3 路由（Routing）

Producer → Exchange → Queue A（key=error）
                    → Queue B（key=info）
                    → Queue C（key=error,warning）

根据 routing key 分发到不同队列
适用：日志分级、按类型处理

11.4 延迟消息（Delayed Message）

Producer → Queue（TTL=30min）→ 死信 Queue → Consumer

消息在队列中等待 30 分钟后过期，进入死信队列被消费
适用：订单超时取消、定时提醒

11.5 RPC（远程过程调用）

Client → Request Queue → Server
Client ← Reply Queue   ← Server

用消息队列实现 RPC：
  1. 客户端发送消息到请求队列，带上 ReplyTo 和 CorrelationId
  2. 服务端处理后将结果发到 ReplyTo 指定的队列
  3. 客户端根据 CorrelationId 匹配响应

适用：跨服务的同步调用（不推荐，用 gRPC 更好）

十二、小结

本文学习了消息队列的核心概念：

消息队列的作用（异步、解耦、削峰）
两种消息模型（点对点、发布订阅）
核心概念（Producer、Consumer、Broker、Queue、Topic、Partition）
消息路由模式（Direct、Topic、Fanout）
确认机制和持久化
重试和死信
消息顺序性和幂等性
投递语义（At Most Once / At Least Once / Exactly Once）
常见消息模式

下一篇将深入 RabbitMQ：架构、Exchange、确认机制和 .NET 实战。