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）
  - 消息消费后删除
  - 队列深度有限（内存限制）
  - 不支持消息回溯（消费了就没了）

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
 4
 5
 6
 7
 8
 9
10
11

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

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

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

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

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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

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

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

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

Kafka：
  生产端：acks=all（确认写入所有 ISR）
  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 → 无法保证顺序
  - 需要顺序的场景只能单消费者，牺牲并发

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

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

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

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

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  — 一步搞定
  集群：3 节点 + HA Policy
  依赖：无（Erlang 自包含）
  复杂度：★★☆☆☆

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

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 时性能下降
  - 镜像队列同步慢
  - 惰性队列性能权衡

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

 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）
✓ 日志收集和监控数据管道
✓ 需要 Exactly-Once 语义
✓ 大数据平台（和 Hadoop、Spark 生态集成）

1
2
3
4
5

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

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

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

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

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

1
2
3
4
5
6
7
8

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

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

1
2
3

大多数业务场景远远到不了 RabbitMQ 的性能瓶颈。
万级/秒的吞吐量对绝大多数系统够用了。
只有在日志收集、大数据管道等场景才需要 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. 不确定时先用 RabbitMQ（更简单），规模上来再考虑 Kafka