[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,先来看看它的整体架构是什么样的。