老王的选型纠结症
决定引入 MQ 之后，老王卡在了选型上。网上攻略看了二十篇，有人说 Kafka 王者，有人说 RocketMQ 真香，还有人说 RabbitMQ 老而弥坚。这一篇不站队，把三家的账摆开来算，最后给一条按场景走的决策路径。
三家的一分钟画像
RabbitMQ：灵活的瑞士军刀。2007 年问世，Erlang 语言编写，AMQP 协议的标杆实现。最大的特色是路由灵活——Exchange 的直连、主题、扇形、头部四种交换机类型，能把一条消息按各种规则分发出去。延迟低、管理界面友好，但吞吐是三家里最弱的，Erlang 也让二开的人才不好找。
Kafka：吞吐量猛兽。2011 年从 LinkedIn 开源，为日志采集和流式处理而生。顺序写磁盘加零拷贝的设计让它单机就能扛每秒百万级消息，批量+压缩进一步摊薄成本。它自带一整套流处理生态（Kafka Streams、Connect），大数据管道几乎是它的主场。但业务侧的功能偏薄：没有内置延迟消息，重试和死信要自己搭，事务语义主要面向流处理。
RocketMQ：电商场景全能选手。2012 年从阿里开源，Java 编写，吞吐十万级，毫秒级延迟。它是三家里业务功能最全的：事务消息、定时/延迟消息、完善的重试与死信队列、消息轨迹查询。吸收了 Kafka 存储设计的精华，又长了一身面向业务的功能。京东、滴滴等大厂的订单类系统大量使用。
核心差异一张表
| 对比项 | RabbitMQ | Kafka | RocketMQ |
|---|---|---|---|
| 单机吞吐 | 万级 | 十万到百万级 | 十万级 |
| 延迟 | 微秒到毫秒级 | 毫秒级（批量攒批） | 毫秒级 |
| 事务消息 | 不支持 | 面向流处理语义 | 半消息+回查，业务友好 |
| 延迟/定时消息 | 插件支持 | 不内置 | 内置（固定级别/任意精度） |
| 重试与死信 | 有，需配置 | 自己搭 | 开箱即用 |
| 消息回溯 | 不支持 | 按 offset 随便回 | 按时间回溯 |
| 典型主场 | 企业集成、低延迟场景 | 日志管道、流计算 | 电商订单、业务消息 |
按场景走的决策路径
- 日志采集、埋点上报、大数据管道：闭眼选 Kafka。吞吐天花板最高，生态最厚，Flink/Spark 的对接是一等公民；
- 订单、支付、积分这类业务消息：优先 RocketMQ。事务消息、延迟消息、重试死信都是业务系统的高频刚需，自己造这些轮子的成本远高于选型差价；
- 企业内部系统间集成、消息路由规则复杂、并发量不大：RabbitMQ 合适。管理省心、协议成熟，路由灵活性的优势在小流量场景里没有对手；
- 团队技术栈：全 Java 团队排查 RocketMQ 源码毫无门槛；Erlang 的 RabbitMQ 和 Scala 的 Kafka，出深坑时排障成本会高一截。
老王的选择
老王的咖啡馆是典型的业务系统：要发订单事件、要做订单超时关闭（延迟消息）、积分服务消费失败需要重试和死信兜底。三条需求撞在 RocketMQ 的枪口上，吞吐十万级对日单百万的业务也绰绰有余。选型定了：RocketMQ 为主，埋点日志走 Kafka，互不越界。
这里多说一句：选型解决的是「场地」，可靠性靠的是「打法」。同一台 RocketMQ，有人用出了 99.99% 的可用性，有人用出了天天丢消息。后面从第 5 篇开始，我们专讲怎么用对。
小结
RabbitMQ 胜在灵活低延迟，Kafka 胜在吞吐和流生态，RocketMQ 胜在业务功能全家桶。没有最好的 MQ，只有和你场景最合拍的 MQ：大数据选 Kafka，业务消息选 RocketMQ，复杂路由小流量选 RabbitMQ。
场地定了，下一课是熟悉场地：Topic、Queue、消费者组、推拉模式——一条消息从生产者走到消费者，中间到底经历了什么。基础概念不打牢，后面的可靠性都是空中楼阁。
评论 (0)