Message Queue on 纪伟的个人博客

后端架构实战（六）：服务间通信——RPC、REST 还是消息

Fri, 04 Apr 2025 10:00:00 +0800

写在前面

上一篇解决了"跨服务数据怎么一致"，这一篇解决"跨服务怎么对话"。

服务间通信是个看似简单、实则踩坑最密集的话题。选错通信方式，会带来延迟、耦合、故障放大一连串问题。核心决策只有一个：同步，还是异步？

这篇会和我的中间件笔记呼应：《消息队列》系列讲了 RabbitMQ/Kafka 本身，《Nginx》系列讲了反向代理和负载均衡。这里讲的是"在架构层怎么选"。

一、同步 vs 异步：第一性抉择

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


同步通信（打电话）：
 调用方发请求 → 等 → 拿到响应
 ✓ 直观、顺序清晰、易理解
 ✓ 能立即知道结果（成功/失败）
 ✗ 调用方被阻塞，吞吐受限
 ✗ 强耦合：被调方挂了，调用方也受影响
 ✗ 故障会沿调用链同步放大

异步通信（发邮件）：
 调用方发消息 → 立即返回 → 被调方按自己节奏处理
 ✓ 解耦、高吞吐、削峰填谷
 ✓ 调用方不等被调方，故障不直接传导
 ✗ 不立即知道结果（要回调/查询）
 ✗ 一致性弱化（最终一致）
 ✗ 调试、追踪更复杂

1
2
3
4
5
6


选择原则：
 必须立即拿到结果 → 同步（查余额、读商品、用户登录）
 结果可以晚点、且能解耦 → 异步（发通知、记日志、算积分）

 反模式：把所有通信都做成同步
 → 一次请求串行调 5 个服务，延迟叠加、雪崩放大。

二、同步通信：REST vs RPC

2.1 REST

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


基于 HTTP，面向"资源"
 GET /orders/123 查
 POST /orders 建
 PUT /orders/123 改
 DELETE /orders/123 删

 ✓ 通用、标准化、人可读
 ✓ 跨语言、跨平台、防火墙友好
 ✓ 生态丰富（网关、监控、文档 Swagger）
 ✗ 基于文本（JSON），序列化开销大
 ✗ 语义偏向 CRUD，复杂业务动作要绕（POST /orders/123/cancel）
 ✗ 没有强类型契约（靠 OpenAPI 补）

 适合：对外 API、和前端/第三方对接、绝大多数业务场景

2.2 RPC（gRPC 为代表）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


基于 HTTP/2 + Protobuf，面向"动作/方法"
 stub.CancelOrder(request) → response

 ✓ 二进制传输，体积小、速度快（比 JSON 快数倍）
 ✓ 强类型契约（.proto 生成各语言客户端）
 ✓ 支持 HTTP/2 多路复用、流式（stream）
 ✗ 不可读（二进制），调试要工具
✗ 浏览器不能直接使用传统 HTTP/2 gRPC；可在 ASP.NET Core 启用 gRPC-Web 或使用 JSON transcoding，且 gRPC-Web 的客户端流和双向流受限
 ✗ 强耦合：proto 一变客户端要重新生成

 适合：内部服务间高频调用、低延迟、大数据量、流式场景

1
2
3
4
5
6


选型经验：
 对外、前端、第三方 → REST
 内部服务间、低延迟、高吞吐 → gRPC
 大多数团队 → REST 打天下，内部热点链路再换 gRPC

 不要一上来全 gRPC，proto 的耦合成本会被低估。

三、异步通信：消息队列

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


通过 Broker（消息中间件）解耦

 生产者 → 消息队列 → 消费者
 生产者不用知道谁消费、有几个、在哪

 ✓ 解耦（生产者消费者互不感知）
 ✓ 削峰（流量高峰积压在队列，消费者按能力处理）
 ✓ 异步、高吞吐
 ✓ 故障隔离（消费者挂了，消息留在队列）
 ✗ 一致性弱（最终一致）
 ✗ 增加架构复杂度（Broker 本身要高可用）

3.1 两大流派

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


RabbitMQ —— 传统消息队列（AMQP）
 特点：丰富的路由（Exchange/Queue/Binding）、可靠投递、消息确认
 模型：一条消息被消费后删除
 强项：业务消息路由、可靠投递、延迟队列
 弱项：吞吐和堆积能力一般

Kafka —— 分布式日志/流平台
 特点：高吞吐、可堆积海量消息、分区有序、支持流处理
 模型：消息是"日志"，可重复消费、按 offset
 强项：日志、事件溯源、大数据管道、超高吞吐
 弱项：路由能力弱、不适合复杂业务路由

 详细对比见《消息队列（四）：RabbitMQ vs Kafka 深度对比》。

3.2 两种消息语义

1
2
3
4
5
6
7
8


点对点（Queue）：一条消息被一个消费者消费
 → 任务分发（一个订单只被一个处理者处理）

发布订阅（Topic）：一条消息被所有订阅者消费
 → 事件广播（订单创建后，积分、通知、统计都各收一份）

 事件驱动架构（EDA）主要用 Pub/Sub：
 订单服务发"订单已创建"，所有感兴趣的下游各自订阅。

四、消息可靠性的三个保证

用消息队列，必须想清楚这三件事；仅配置这些仍不等于端到端“绝不丢”：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 生产端不丢：确认机制 + 重试 + 本地落库
 → 关键消息用 Outbox 模式（上一篇讲过）

2. Broker 不丢：持久化 + 副本 + 确认
 → 消息持久化磁盘、集群多副本、生产者等 broker 确认

3. 消费端不丢：手动确认 + 幂等
 → 处理成功后再 ack（别自动 ack）
 → 处理失败重试，重试要幂等（消息会重复投递）

 三个环节任何一个漏了，消息就会丢。

五、服务间通信的反模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


反模式 1：同步链路过长
 A→B→C→D→E，五个服务串行同步调用
 → 延迟叠加、任意一环故障全链路崩
 → 能异步化的副作用（日志、通知、统计）坚决异步

反模式 2：循环依赖
 A 调 B，B 又调 A
 → 死锁可能、边界划分反了（回到第三篇：拆错了）

反模式 3：共享数据库当通信
 两个服务通过读写同一张表"传话"
 → 表结构耦合，等于没拆，且并发冲突
 → 服务通信要走 API/消息，不偷懒走数据库

反模式 4：消息不带版本
 事件 schema 一改，所有消费者崩
 → 事件契约要版本化、向后兼容

反模式 5：忽略超时和熔断
 同步调用不设超时 → 一个慢服务拖垮调用方线程池
 → 为每条调用设定截止时间或超时预算；熔断是否适用取决于失败率、流量和恢复策略

六、网关：通信的统一入口

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


对外不用让客户端直连每个服务，前面加一层 API 网关：

 客户端 → API 网关 → 各微服务

 网关职责：
 - 统一鉴权（token 校验集中在一处）
 - 限流、熔断
 - 路由（外部 REST 路由到内部 gRPC）
 - 协议转换（gRPC-Web、聚合多个服务）
 - 灰度、A/B

 常见：Kong / APISIX / Nginx（见我的 Nginx 系列）/ Ocelot（.NET）/ YARP（.NET）

 注意：网关是单点，必须高可用（多实例 + 负载均衡）。

七、一份选型速查

1
2
3
4
5
6
7
8
9


需求 选择
──────────────────────────────────────────────
对外 API / 前端调用 REST
内部高频、低延迟调用 gRPC
必须立即拿结果 同步（REST/gRPC）
可解耦、可削峰、能异步 消息队列
事件广播、多下游订阅 Kafka / RabbitMQ Pub-Sub
可靠事件投递 Outbox + 消息队列
统一入口、鉴权、限流 API 网关

八、小结

第一性抉择：同步（要立即结果）还是异步（可解耦、能晚点）
同步：REST（通用、对外）vs gRPC（内部、低延迟、强类型）
异步：消息队列解耦、削峰、故障隔离；RabbitMQ 重路由，Kafka 重吞吐/流
可靠性三层：生产端、Broker、消费端分别定义确认、持久化、重试和幂等语义；仍需故障演练验证端到端保证
五大反模式：同步链路过长、循环依赖、共享库通信、消息不版本化、忽略超时熔断
网关：统一入口，集中鉴权/限流/路由，必须高可用

下一篇讲把这些服务监控起来——可观测性，微服务的神经系统。

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

Fri, 13 Dec 2024 10:00:00 +0800

写在前面

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

一、设计哲学对比

1.1 RabbitMQ：消息代理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

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

1.2 Kafka：分布式日志

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

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

1.3 根本差异

1
2
3
4
5


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

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

二、架构对比

2.1 消息模型

1
2
3
4
5
6
7
8
9


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 消息存储

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


RabbitMQ：
 - 内存为主，持久化消息写入磁盘消息存储（元数据另存内部数据库，不是把消息存进 Mnesia 表）
 - 消息消费后删除
 - 队列深度受资源限制（现代版本主要受磁盘和恢复时间约束）
 - Classic/Quorum Queue 中消息确认后通常删除；RabbitMQ Streams 则支持按保留策略回放

Kafka：
 - 追加写入磁盘日志
 - 消息保留一段时间（如 7 天）后删除
 - 可按时间或容量保留大量积压，但仍受磁盘、分区、复制和恢复时间约束
 - 支持消息回溯（修改 Offset 重新消费）

2.3 消费模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

三、性能对比

3.1 吞吐量

1
2
3


RabbitMQ 与 Kafka 都不能脱离消息大小、确认策略、副本数、磁盘、批量和消费者行为给出固定吞吐数字。

Kafka 的分区日志、顺序 I/O、页缓存和批量传输通常适合高吞吐事件流；RabbitMQ 的 Exchange 路由、逐消息确认和不同队列类型更适合灵活消息代理场景。选型必须用真实工作负载压测，不能把 RabbitMQ 简化成“随机写”、Kafka 简化成“必然百万级”。

3.2 延迟

1

两者延迟都受持久化、复制、批量、网络和积压影响。RabbitMQ 常用于低延迟任务分发；Kafka 可通过批量参数在延迟与吞吐之间取舍，但没有脱离配置的固定“微秒/毫秒”分界。

3.3 消息堆积能力

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


RabbitMQ：
 - 现代队列会把消息移到磁盘，并在内存保留工作集
 - 大量积压会增加磁盘、恢复和消费者追赶压力
 - 现代 Classic Queue 会主动把消息移到磁盘，仅保留较小工作集；旧版 Lazy Queue 模式自 RabbitMQ 3.12 起已不再支持
 - 堆积过多会触发流控（阻塞生产者）

Kafka：
 - 天然持久化到磁盘，堆积是常态
 - 保留型分区日志适合较长时间积压和回放
 - 积压仍会消耗磁盘、页缓存、复制与恢复带宽，并可能影响生产和消费延迟

四、可靠性对比

4.1 消息不丢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


RabbitMQ：
 生产端：Publisher Confirm（确认写入 Broker）
 Broker：持久化（Exchange + Queue + Message）
 消费端：手动 ACK（处理完再确认）
 高可用：RabbitMQ 4.x 使用 Quorum Queue 或 Stream（镜像经典队列已移除）

Kafka：
 生产端：acks=all（等待当前 ISR；能否成功还受 min.insync.replicas 约束）
 Broker：副本机制（Replica + ISR）
 消费端：手动提交 Offset（处理完再提交）
 高可用：多副本 + Leader 选举

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

4.2 消息不重复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


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

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

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

4.3 消息顺序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


RabbitMQ：
 - 单 Queue、单 Consumer 可保持派发顺序，重投递仍可能改变最终处理顺序
 - 多 Consumer 的业务完成顺序通常无法保证
 - 可按业务 Key 分队列，在局部顺序与并发之间取舍

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

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

4.4 消息回溯

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


RabbitMQ：
 Classic/Quorum Queue 的消息确认后通常删除，不能像日志一样任意重置游标
 RabbitMQ Streams 支持保留与回放，选型时应明确使用的队列类型

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

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

五、功能对比

5.1 路由能力

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


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

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

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

5.2 延迟消息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


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

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

结论：
 延迟消息场景 → RabbitMQ

5.3 协议支持

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

5.4 管理和监控

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

六、运维对比

6.1 部署复杂度

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


RabbitMQ：
 单机：docker run -d rabbitmq — 一步搞定
 集群：多节点 + Quorum Queue/Stream；RabbitMQ 4.x 不再使用镜像队列 HA Policy
 依赖：Erlang/OTP（官方 Docker 镜像已内置）
 复杂度：★★☆☆☆

Kafka：
 单机：Broker + KRaft Controller（开发环境可采用 combined mode）
 集群：Broker 与 KRaft Controller；生产规模下通常分离角色并部署奇数个 Controller
 依赖：Kafka 4.0 起仅支持 KRaft，ZooKeeper 模式已移除
 复杂度：★★★★☆

6.2 扩容

1
2
3
4
5
6
7
8
9


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

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

6.3 运维痛点

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


RabbitMQ：
 - 内存管理需要调优
 - 大量 Queue 时性能下降
 - Quorum Queue 的多数派复制对磁盘和网络有要求
 - 不同 Queue/Stream 类型的语义与性能取舍

Kafka：
 - Partition 数量管理（只能增不能减）
 - Rebalance 导致消费暂停
 - KRaft Controller 仲裁、元数据与升级运维
 - 磁盘空间管理

七、.NET 生态对比

7.1 客户端库

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

7.2 代码复杂度

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


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

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

八、适用场景对比

8.1 选 RabbitMQ 的场景

1
2
3
4
5
6
7
8


✓ 消息路由复杂（多种 Exchange、灵活绑定）
✓ 需要延迟消息（TTL + DLX、定时任务）
✓ 企业系统集成（支持 AMQP、MQTT、STOMP）
✓ 吞吐、延迟和积压模型经真实工作负载压测后符合要求
✓ 需要较低延迟的任务分发
✓ 需要请求/响应模式（RPC over MQ）
✓ 快速原型和小型项目
✓ 团队已有 RabbitMQ 经验

8.2 选 Kafka 的场景

1
2
3
4
5
6
7
8
9


✓ 需要分区化事件日志和较高顺序吞吐
✓ 需要较长保留、积压与回放
✓ 事件驱动架构（Event Sourcing、CQRS）
✓ 多个消费者独立消费同一数据（Consumer Group）
✓ 需要消息回溯（重新消费历史数据）
✓ 流计算（Kafka Streams、Flink、Spark）
✓ 日志收集和监控数据管道
✓ 需要 Kafka 内事务性“消费—处理—生产”，并能正确配置消费者隔离级别
✓ 大数据平台（和 Hadoop、Spark 生态集成）

8.3 都能用的场景

1
2
3
4
5


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

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

九、选型决策树

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


核心语义？
├── Exchange 路由、工作队列、逐消息确认 → 优先评估 RabbitMQ
├── 分区日志、长期保留、按位点回放 → 优先评估 Kafka
└── 两者都能满足 → 用真实负载、故障恢复和运维成本 POC

特殊需求：
├── 需要 Kafka 内事务性处理 → Kafka（外部副作用仍需额外一致性设计）
├── 需要消息回溯 → Kafka
├── 需要流计算 → Kafka
├── 需要多协议支持 → RabbitMQ
└── 需要快速上手 → RabbitMQ

十、常见误解

10.1 “Kafka 比 RabbitMQ 好”

1
2
3
4
5
6
7
8


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

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

10.2 “RabbitMQ 性能不够”

1

不要用脱离条件的“每秒多少条”直接选型。真实消息大小、确认策略、积压量、保留周期和恢复目标比宣传数字更重要；Kafka 的优势还包括可回放的分区日志，而不只是峰值吞吐。

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

1
2
3
4
5


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

十一、系列总结

11.1 知识体系回顾

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


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

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

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

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

11.2 核心结论

1
2
3
4
5


1. RabbitMQ 和 Kafka 不是替代关系，而是互补
2. 根据消息量级、路由需求、运维能力做选择
3. 复杂路由、任务分发和多协议集成可优先评估 RabbitMQ
4. 分区事件日志、长保留、回放和流处理可优先评估 Kafka
5. 不确定时先定义交付边界、顺序范围、积压时长和运维能力，再用代表性负载验证

消息队列（三）：Kafka 深入

Wed, 11 Dec 2024 10:00:00 +0800

写在前面

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

一、Kafka 架构

1.1 整体架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Producer → Broker Cluster → Consumer Group
 ↑
 KRaft Controller（元数据管理；Kafka 4.0 起不再支持 ZooKeeper 模式）

核心组件：
- Broker — Kafka 服务器节点
- Topic — 消息分类（逻辑概念）
- Partition — Topic 的物理分片
- Replica — Partition 的副本
- Producer — 消息生产者
- Consumer — 消息消费者
- Consumer Group — 消费者组
- KRaft Controller — 集群元数据和控制器选举；ZooKeeper 模式仅存在于 Kafka 3.x 及更早版本

1.2 和 RabbitMQ 的本质区别

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


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

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

1.3 消息流转过程

1
2
3
4
5


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

二、Topic 和 Partition

2.1 Partition 的作用

1
2
3
4


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

2.2 Partition 数量选择

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

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

2.3 Key 和 Partition 路由

1
2
3
4
5


Producer 发送消息时可以指定 Key：
- Key 为 null — 粘性分区策略（sticky partitioning），在分区间均匀分布（旧版本为逐条轮询）
- Key 不为 null — 对 Key 做 Hash，相同 Key 到同一个 Partition

在 Topic 分区数与分区器规则稳定时，这会让相同业务 ID 的记录进入同一 Partition；消费者还需避免并行处理和失败重试造成业务完成顺序变化

1
2
3
4
5
6
7
8


// 指定 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）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Kafka 的核心存储设计：

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

特点：
- 顺序写磁盘 → 极快（顺序写比随机写快几个数量级，具体数字依硬件而定）
- 不可修改 → 只能追加
- 通过 Offset 随机读取

3.2 Segment 分段

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


一个 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）

1
2
3
4
5
6
7
8


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

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

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

3.4 页缓存（Page Cache）

1
2
3
4
5
6


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

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

3.5 数据保留和清理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


保留策略（二选一）：
- 按时间：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
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 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 配置

1
2
3
4
5
6
7
8


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

4.3 批量发送和缓冲

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


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

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

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

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

 // 压缩
 CompressionType = CompressionType.Lz4,

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

4.4 幂等生产者

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

五、消费者

5.1 Consumer Group

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


核心概念：
- 一个 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 管理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


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

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


// 手动提交
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");
 // 若继续处理同一 Partition 的后续记录并提交，失败消息仍可能被跳过。
 break;
 }
}

5.3 Rebalance

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


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

Eager Rebalance 会先撤回全部分区再重新分配；
CooperativeStickyAssignor 使用增量协作式再均衡，只撤回需要迁移的分区。

Rebalance 的问题：
- Eager 策略会造成消费组短暂停顿，协作式策略可缩小影响范围
- 可能重复消费（Rebalance 前 Commit 了吗？）
- 频繁 Rebalance 影响性能

减少 Rebalance：
- 合理设置 session.timeout.ms（默认 45s）
- 合理设置 heartbeat.interval.ms（默认 3s）
- 避免两次 poll 间隔超过 max.poll.interval.ms；session.timeout.ms 主要用于检测心跳失联
- 使用 CooperativeStickyAssignor（增量 Rebalance）

5.4 消费者配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


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 副本机制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


每个 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 选举

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Leader 挂了时：
1. Controller（KRaft 模式下由仲裁节点担任）检测到
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 副本配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 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 语义

1
2
3
4
5


Kafka 事务保证：
- 原子性：一批消息要么全部成功要么全部失败
- 跨 Partition：可以同时写入多个 Partition
- 消费-处理-生产：从 Topic A 消费，处理完写入 Topic B，把位移提交纳入同一事务；
 该保证只覆盖 Kafka 内部的读写，外部副作用（发短信、写库）仍需业务幂等

7.2 事务生产者

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


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 事务消费者

1
2
3
4
5
6
7
8


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 封装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


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 封装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


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 注册和使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 注册 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, "您的订单已创建");
 }));

九、常用运维命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 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 深入

Mon, 09 Dec 2024 10:00:00 +0800

写在前面

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

一、RabbitMQ 架构

1.1 整体架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

1.2 消息流转过程

1
2
3
4
5
6


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

1.3 Virtual Host

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

二、Exchange 详解

2.1 Direct Exchange

精确匹配 Routing Key。

1
2
3
4


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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 声明 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。

1
2
3
4
5


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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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。

1
2
3
4
5


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

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

2.5 Exchange 类型选择

1
2
3
4


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

三、消息可靠性保证

3.1 三个环节

1
2
3


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

3.2 生产端：Publisher Confirm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 开启 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 生产端：事务（不推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


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

// Confirm 模式没有事务的同步开销，吞吐明显更高，优先用 Confirm

3.4 Broker 端：持久化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


三个层面都要持久化：

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


// 关闭自动确认
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 可靠性总结

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


消息不丢的完整配置：

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

Broker：
 ✓ Exchange 持久化（durable=true）
 ✓ Queue 持久化（durable=true）
 ✓ Quorum Queue 或 Stream 复制（RabbitMQ 4.x；镜像经典队列已移除）

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

四、死信队列

4.1 死信产生条件

1
2
3


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

4.2 配置死信队列

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 业务队列：指定死信交换机
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 死信处理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 消费死信队列
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 方案

1
2
3
4
5
6
7
8
9


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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 延迟队列：消息过期后进入死信
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
3


# 先从插件发布页下载与 RabbitMQ 版本匹配的 .ez 文件并放入 plugins 目录
# 安装 rabbitmq_delayed_message_exchange 插件
rabbitmq-plugins enable rabbitmq_delayed_message_exchange

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// 使用延迟插件（更灵活，支持每条消息不同延迟）
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 实战

本节代码使用 RabbitMQ.Client 6.x 的同步 IModel API。RabbitMQ.Client 7.x 已改为以 IChannel、CreateConnectionAsync、CreateChannelAsync 和异步发布/消费 API 为主；安装最新版包时不能直接复制本节代码，应按 7.x API 指南迁移。

6.1 使用 RabbitMQ.Client

1

dotnet add package RabbitMQ.Client --version 6.8.1

6.2 封装 Producer

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


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)
 {
 // 直接 requeue 不会增加 x-death，可能形成无限热循环。
 // 这里拒绝并进入已配置的死信队列；有限重试应使用独立重试队列或成熟框架。
 _channel.BasicNack(ea.DeliveryTag, false, requeue: false);
 }
 };

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


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

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

1

dotnet add package MassTransit.RabbitMQ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60


// 注册
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 集群模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


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

镜像队列（Classic Queue Mirroring，历史方案，RabbitMQ 4.0 已移除）：
 - Queue 在多个节点有副本
 - 主节点写入，同步到从节点
 - 主节点挂了，从节点自动提升

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

7.2 Quorum Queue 配置

1
2
3
4
5
6


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

八、性能调优

8.1 生产端优化

1
2
3
4


批量发送 — 减少 RTT，一次发送多条
Confirm 批量确认 — 多条消息一起确认
异步 Confirm — 注册回调处理 ACK/NACK
长连接复用 — 复用 Connection；Channel 不应被多个并发发布线程共享，可按并发单元创建

8.2 消费端优化

1
2
3
4
5
6
7
8


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

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

8.3 Broker 端优化

1
2
3
4


消息持久化权衡 — 持久化慢但安全，非持久化快但可能丢
现代 Classic Queue — 主动把消息移到磁盘、仅保留较小工作集；旧 Lazy Queue 配置已不再支持
流控 — 内存/磁盘告警时限制生产者发送速度
节点数量 — 3-5 个节点，兼顾可用性和性能

九、运维常用操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


# 用户管理
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 类型（Direct、Fanout、Topic、Headers）和路由规则
消息可靠性保证（Confirm、持久化、手动 ACK）
死信队列和延迟消息
.NET 实战（RabbitMQ.Client、MassTransit）
集群高可用（RabbitMQ 4.x 使用 Quorum Queue 或 Stream；镜像经典队列仅作历史迁移背景）
性能调优

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

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

Sat, 07 Dec 2024 10:00:00 +0800

写在前面

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

一、为什么需要消息队列

1.1 同步调用的问题

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


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

总耗时：950ms

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

1.2 异步解耦

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

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

1.3 三大核心作用

1
2
3


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

二、消息模型

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

1
2
3
4
5
6
7
8


Producer → Queue → Consumer

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

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

2.3 两种模型对比

1
2
3
4
5


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

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

三、核心概念详解

3.1 Producer（生产者）

1
2
3
4
5
6
7


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

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

3.2 Consumer（消费者）

1
2
3
4
5
6
7
8


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

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

3.3 Broker（消息代理）

1
2
3
4
5
6
7
8


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

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

3.4 Queue 和 Topic

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Queue（队列）：
 - RabbitMQ 的核心实体
 - Broker 按入队顺序派发，但重投递、多消费者和并行处理会影响最终处理顺序
 - 消息被消费后删除（默认）
 - 可以设置 TTL、死信等

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

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

3.5 消息结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


一条消息包含：

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

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

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

四、消息路由模式

4.1 直连路由（Direct）

1
2
3
4
5


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

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

4.2 主题路由（Topic）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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）

1
2
3
4


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

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

4.4 头部路由（Headers）

1
2


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

五、消息确认机制

5.1 为什么需要确认

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


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

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

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

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

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

5.2 生产者确认

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

Kafka：acks 配置
 - acks=0 — 发出去就不管了（最快，可能丢）
 - acks=1 — Leader 写入成功就返回
 - acks=all — 当前 ISR 中满足 `min.insync.replicas` 的副本确认后才返回；并不等待已掉出 ISR 的副本
 - Kafka 3.0 起默认 acks=all（同时默认开启幂等生产者）

5.3 消费者确认

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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 持久化层次

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

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

七、重试和死信

7.1 消费失败的处理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

7.2 重试策略

1
2
3
4


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

7.3 死信队列（DLQ）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

八、消息顺序性

8.1 为什么顺序重要

1
2
3
4
5
6
7
8


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

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

业务出错！

8.2 保证顺序的方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


RabbitMQ：
 - 单 Queue、单 Consumer、逐条确认可保持派发顺序；失败重投递仍需业务状态机或版本号防止回退
 - 多消费者并行时应按业务 Key 分队列，或由业务层处理乱序

Kafka：
 - 同一个 Partition 内消息有序
 - 相同 Key 的消息发到同一个 Partition
 - 每个 Partition 只被 Consumer Group 中一个 Consumer 消费
 - 所以：相同业务 Key 可保持分区内记录顺序；处理失败、重试和并行回调仍需额外约束

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

九、消息幂等性

9.1 为什么需要幂等

1
2
3
4
5
6
7
8
9


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

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

9.2 幂等方案

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


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

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

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

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

方案5：Kafka 幂等生产者或事务 + 消费端业务幂等
 RabbitMQ Publisher Confirms 用于确认 Broker 是否接收消息，不能替代业务去重

十、消息投递语义

10.1 三种语义

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

At Least Once（至少一次） — 在确认、持久化和副本等前提成立时尽量避免丢失，但可能重复
 先处理消息，再提交 offset
 适用：大部分业务场景（配合幂等使用）

Exactly Once（精确一次） — 在明确的系统边界内让一次处理的结果只生效一次
 通常需要事务、幂等写或 fencing 等机制；Broker 语义不能自动覆盖数据库、短信等外部副作用
 适用：需要严格定义原子边界并验证故障行为的场景

10.2 各 MQ 支持

1
2
3
4
5
6
7
8
9


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

Kafka：
 默认 At Least Once
 幂等生产者（enable.idempotence=true）用于避免生产者重试造成的重复写入
 Kafka 事务可把多分区写入及消费位点提交纳入同一事务；端到端语义还取决于消费者隔离级别和外部副作用

十一、常见消息模式

11.1 工作队列（Work Queue）

1
2
3
4
5
6


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

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

11.2 发布订阅（Pub/Sub）

1
2
3
4
5
6


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

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

11.3 路由（Routing）

1
2
3
4
5
6


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

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

11.4 延迟消息（Delayed Message）

1
2
3
4


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

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

11.5 RPC（远程过程调用）

1
2
3
4
5
6
7
8
9


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 实战。