[TOC] #### 1. 回顾一下 --- 上一讲我们认识了消息队列，也知道了它在系统中的位置 那接下来，一个很现实的问题来了：RabbitMQ、Kafka、RocketMQ，到底该选哪个 ？ 别慌，今天我们只聊最主流的三个：RabbitMQ、Kafka、RocketMQ。先说结论：没有最好的，只有最适合的。 #### 2. 一句话认识它们 --- RabbitMQ + 老牌消息队列，用 Erlang 语言写的。 + 特点是稳定、可靠、灵活，社区成熟，文档丰富。 + 适合业务消息、任务分发、服务解耦这些场景。 Kafka + LinkedIn 开源的，用 Scala/Java 写的。 + 特点是吞吐量极大，擅长处理海量数据流。 + 适合日志收集、大数据管道、实时数据流这些场景。 RocketMQ + 阿里巴巴开源的，用 Java 写的，是双十一的核心基础设施。 + 特点是高吞吐 + 低延迟，还支持事务消息。 + 适合电商订单、金融交易、高并发业务这些场景。 #### 3. 关键指标对比 --- 看不懂没关系，下面一个一个解释 | 指标 | RabbitMQ | Kafka | RocketMQ | | ------------ | ------------ | ------------ | ------------ | | 开发语言 | Erlang | Scala/Java | Java | | 吞吐量 | 万级/秒 | 百万级/秒 | 十万级/秒 | | 延迟 | 微秒级 | 毫秒级 | 毫秒级 | | 消息可靠性 | 高 | 高 | 高 | | 消息顺序 | 不保证（单队列可） | 分区内有序 | 队列内有序 | | 事务消息 | 不支持 | 不支持 | 支持 | | 延迟消息 | 插件支持 | 不支持 | 原生支持 | | 消息回溯 | 不支持 | 支持 | 支持 | | 管理界面 | 自带（好用） | 无（需第三方） | 自带 | | 学习成本 | 低 | 中 | 中 | | 社区活跃度 | 高 | 很高 | 高 | #### 4. 吞吐量：能处理多少消息 --- 这是最直观的区别 RabbitMQ 更偏向业务消息场景，Kafka 更擅长处理超大规模数据流，RocketMQ 则介于两者之间 至于具体吞吐量，会受到机器配置、消息大小、网络环境等因素影响，不同环境差异很大 + 如果你的系统一天几百万条消息，RabbitMQ 够用了。 + 如果你的系统一天几十亿条消息（比如大型日志平台），Kafka 更合适。 #### 5. 延迟：消息从发出到被消费要多久 --- 三者的延迟都已经足够低，对于绝大多数业务系统来说，用户几乎感知不到差别。 RabbitMQ 在业务消息场景下通常拥有不错的实时性，因此经常被用于订单、通知、任务分发等场景。 大多数业务场景，毫秒级的延迟完全感知不到。 但如果你做的是实时竞价、高频交易这种对延迟极其敏感的场景，RabbitMQ 有优势。 #### 6. 消息回溯：能重新消费历史消息吗 --- RabbitMQ：消息消费完就删了（默认行为），不能回溯。 Kafka：消息会保留一段时间（比如 7 天），可以重新消费。 RocketMQ：也支持消息回溯。 这意味着什么？ 假设你的消费者代码有 bug，消费了 1 万条消息，处理全错了。 用 Kafka 的话，你可以修好 bug，重新从头消费一遍；用 RabbitMQ 的话，消息已经没了，只能认栽。 所以日志、数据管道这种场景，Kafka 更合适。 #### 7. 事务消息：这个厉害了 --- RocketMQ 原生支持事务消息。 什么意思？ 举个例子：用户下单，要同时扣库存和创建订单。如果订单创建成功了，但库存扣失败了，数据就不一致了。 RocketMQ 的事务消息可以保证：扣库存和创建订单要么都成功，要么都失败。这个能力 RabbitMQ 和 Kafka 都不原生支持。 不过对于大部分中小型项目来说，很少会因为事务消息这一项能力就直接选择 RocketMQ。 更多时候还是根据团队技术栈和业务场景来决定。 #### 8. 延迟消息：定时投递 --- RocketMQ 原生支持延迟消息，可以设置消息在 1 秒、5 秒、10 秒之后才投递。 RabbitMQ 需要装插件才能实现，Kafka 不支持。 什么场景需要延迟消息？ + 订单 30 分钟未支付自动取消 + 会议开始前 15 分钟提醒 + 消息撤回后 2 分钟内可恢复 + 抽奖活动在20分钟后自动开奖 这些场景用 RocketMQ 最方便，但 RabbitMQ 装个插件也能搞定。 #### 9. 学习成本 --- RabbitMQ 最低，管理界面好用，概念清晰，PHP 支持也好。 Kafka 中等，概念比较多（Partition、Consumer Group、Offset），但文档丰富。 RocketMQ 中等，功能最多，但也最复杂。不过如果你熟悉 Java 生态，上手会快一些。 很多大厂其实会同时使用 RabbitMQ、Kafka、RocketMQ，它们并不是谁淘汰谁的关系，而是解决不同的问题。 选型的时候，应该先看业务场景，再看工具。 #### 10. 那我到底选哪个 --- 给你一个简单的决策树： ```plaintext ├── 日志收集、大数据管道、海量数据流 │ └── → Kafka │ ├── 电商订单、金融交易、需要事务消息 │ └── → RocketMQ │ ├── 业务消息、任务分发、服务解耦 │ └── → RabbitMQ │ └── 不确定 / 中小型项目 / 刚入门 └── → RabbitMQ（最容易上手） ``` 对于我们 PHPer 来说，RabbitMQ 是最自然的选择。 而且学会 RabbitMQ 之后，再去接触 Kafka 或 RocketMQ，会发现很多核心思想其实是相通的。 生产者、消费者、消息投递、消费确认这些概念，本质上都差不多。 原因很简单： + PHP 社区支持最好，有成熟的 Composer 包 + 学习成本最低，管理界面直观，中小型项目完全够用 + 概念通用，学会了 RabbitMQ，以后切 Kafka 或 RocketMQ 也不难 #### 11. 本文小结 --- | 场景 | 推荐 | | -------------------- | -------- | | 业务消息、任务分发 | RabbitMQ | | 日志收集、大数据 | Kafka | | 电商、金融、事务 | RocketMQ | | PHPer 入门学习 | RabbitMQ | 记住一个原则：先选场景，再选工具。 不要因为 Kafka 吞吐量高就盲目上 Kafka，你的项目可能根本用不到那么高的吞吐量。 选最合适的，不选最牛的。 下一讲，我们正式进入 RabbitMQ，先来看看它的整体架构是什么样的。