Appearance
两种中间件对比与选型
这篇笔记专门对比 RabbitMQ、Kafka 这两种常见消息中间件的差异，以及它们各自更适合的业务场景。
这里先解释两个容易混用的词：
消息队列：强调“把消息先放到中间层，再由消费者异步处理”这类能力消息中间件：强调“提供消息存储、转发、投递、确认、重试等机制的基础设施产品”
在日常交流里，这两个词经常混着用。
如果不特别区分，工程语境下可以把它们理解成同一类东西。
1. 先说结论：这两个产品分别更像什么
可以建立一个非常粗的第一印象：
| 产品 | 第一印象 |
|---|---|
RabbitMQ | 更偏业务消息路由，模型清晰，路由灵活 |
Kafka | 更偏高吞吐日志流和事件流平台 |
这张表只是帮助建立第一层直觉，不够用来直接做选型。
真正选型时，至少还要继续看：
- 吞吐要求
- 顺序要求
- 路由复杂度
- 团队运维成本
2. 核心差异对比表
| 对比维度 | RabbitMQ | Kafka |
|---|---|---|
| 设计侧重点 | 灵活路由和业务消息分发 | 高吞吐日志流和事件流 |
| 核心模型 | Exchange、Queue、Binding、Routing Key | Topic、Partition、Offset、Consumer Group |
| 更常见优势 | 路由灵活、模型直观、功能成熟 | 吞吐高、扩展强、适合大规模数据流 |
| 更常见场景 | 异步解耦、通知分发、业务事件投递 | 日志采集、埋点、流式处理、事件总线 |
| 顺序能力 | 可以做，但通常不是最大亮点 | 更常保证分区内顺序 |
| 路由能力 | 很强，尤其适合复杂路由 | 相对更简单，重点不在复杂路由 |
| 吞吐特点 | 中等到较高 | 通常最高 |
| 延迟消息 | 常通过 TTL、死信队列或插件实现 | 不是最典型亮点 |
| 学习切入点 | 先学消息路由模型 | 先学分区和位点模型 |
3. 一些核心名词到底是什么意思
3.1 Exchange
Exchange 是 RabbitMQ 里的“交换器”。
它可以理解成 消息先到交换器，再由交换器决定该把消息路由到哪个队列。
它解决的是 生产者不需要直接写死某个消费队列，而是先按路由规则分发。
3.2 Partition
Partition 是 Kafka 里的“分区”。
它可以理解成 一个 Topic 在物理上拆成多个可并行处理的分片。
它解决的是：
- 提升并发吞吐
- 支撑水平扩展
- 在分区内维护顺序
3.3 Offset
Offset 是 Kafka 里消息在某个分区中的位置编号。
它可以理解成 消费者读到哪里了，用一个递增的位置来记录。
它不等于“消息被删除了”。
Kafka 更常见的思路是：消息保留在日志里，消费者自己记录消费进度。
4. 从业务场景看，分别更适合什么
| 业务场景 | 更推荐的方向 | 原因 |
|---|---|---|
| 下单后发短信、发优惠券、发站内信 | RabbitMQ | 路由灵活，适合多个下游分发 |
| 用户行为埋点、日志采集、点击流分析 | Kafka | 吞吐高，适合大规模事件流 |
| 一个事件要广播给多个不同系统 | RabbitMQ | Fanout、Topic 这类模型更自然 |
| 需要对海量消息做流式计算 | Kafka | 和日志流、流处理体系更契合 |
| 需要多个业务系统按规则分发同一条消息 | RabbitMQ | 交换器和绑定关系更容易表达这类路由规则 |
| 需要大量消息保留、回放和消费进度管理 | Kafka | 位点和分区模型更适合这类事件流场景 |
5. 如果从“问题”出发，该怎么选
5.1 你的核心问题是“消息怎么灵活分发”
更推荐看 RabbitMQ。
因为它的强项在于：
- 路由模型直观
Exchange类型丰富- 一条消息发给多个不同消费队列很自然
5.2 你的核心问题是“数据量很大，吞吐压力很高”
更推荐看 Kafka。
因为 Kafka 更擅长：
- 高吞吐写入
- 大规模事件流
- 分区扩展
- 日志保留与回放
6. 选型时最容易掉进去的误区
6.1 误区一：只看吞吐，不看业务模型
吞吐当然重要，但如果你的业务核心问题是“一个事件怎么按规则分发给不同系统”，那单纯追求吞吐最高并不一定合适。
6.2 误区二：把“支持顺序”理解成“天然全局有序”
这两种产品都不能简单理解成：只要用了它，就能自动保证所有消息全局有序。
工程上更常见的是：对同一个业务 key 保证局部顺序。
6.3 误区三：以为有消息中间件就自动不会丢消息
消息从生产到消费经过多个阶段：
- 生产者发送
- Broker 接收和持久化
- Broker 投递
- 消费者处理
- 消费者确认
任何一个阶段出问题，都可能带来丢失、重复或乱序风险。
所以真正要关注的，是：
- 可靠投递机制
- 消费确认
- 幂等
- 重试与补偿
7. 一份更实用的选型建议
如果你只是想先建立第一层工程直觉，可以抓住这两点：
- 需要灵活路由和典型业务消息分发，优看
RabbitMQ - 需要高吞吐日志流和大规模事件流，优看
Kafka
如果你的系统还不大，最重要的通常不是“理论上最强的能力”，而是：
- 团队会不会用
- 运维能不能接住
- 场景是否真的需要这些高级特性
8. 一句话总结
这两个产品并不是简单的“谁更强”，而是各自更偏向不同问题：
RabbitMQ 更偏消息路由与业务分发，Kafka 更偏日志流、吞吐和大规模事件流。