1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

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

1
2
3
4
5

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

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

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 各自消费（发布订阅）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

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

 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 管理消费进度

1
2
3

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

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

1

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

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

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

 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 在消息不重复方面更成熟

 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 模型更适合顺序消费场景

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

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

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

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

 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

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

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

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

结论：
  延迟消息场景 → RabbitMQ

 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 接口

 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）
  社区有开源方案但需要额外部署
  管理便利度：★★★☆☆

 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 模式已移除
  复杂度：★★★★☆

1
2
3
4
5
6
7
8
9

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

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

 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

 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 处理
  配置项多但代码结构简单

1
2
3
4
5
6
7
8

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

1
2
3
4
5
6
7
8
9

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

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

1
2
3
4
5
6
7
8

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

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

1

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

1
2
3
4
5

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

 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 生态、选型决策

1
2
3
4
5

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