3. 主流消息队列选型对比：RabbitMQ、Kafka、RocketMQ、Redis Stream
做消息中间件选型，说白了就是一场权衡游戏。没有银弹，只有最合适的。
我见过不少团队，上来就拍脑袋选 Kafka，结果业务量一天就几万条消息，运维成本比消息本身还高。也见过有人硬扛着 RabbitMQ 做海量日志，最后集群崩得稀里哗啦。
今天我把四个主流选手——RabbitMQ、Kafka、RocketMQ、Redis Stream——掰开揉碎讲清楚。你听完至少能避开 80% 的选型坑。
核心观点：选型不是比谁功能多，而是看你的业务场景最不能容忍什么。
3.1 四款消息队列的定位与出身
先看一张总览表，心里有个底。
| 特性 | RabbitMQ | Kafka | RocketMQ | Redis Stream |
|---|---|---|---|---|
| 诞生时间 | 2007 | 2011 | 2012（开源） | 2018（Stream 特性） |
| 协议 | AMQP 0-9-1 | 自定义 TCP 协议 | 自定义 TCP 协议 | RESP（Redis 协议） |
| 核心模型 | Exchange + Queue | Topic + Partition | Topic + Queue | Stream + Consumer Group |
| 存储方式 | 内存 + 磁盘（可选） | 磁盘（顺序写） | 磁盘（顺序写） | 内存 + RDB/AOF |
| 语言 | Erlang | Scala/Java | Java | C |
你看，光出身就决定了它们的基因。RabbitMQ 是 Erlang 写的，天生适合做复杂路由。Kafka 为日志而生，追求吞吐。RocketMQ 是阿里内部孵化的，针对电商场景做了大量优化。Redis Stream 嘛，是 Redis 生态的补充，轻量但功能有限。
3.2 RabbitMQ：灵活路由的瑞士军刀
我个人习惯把 RabbitMQ 叫做「消息路由器」。它的 Exchange 机制太强了，direct、topic、fanout、headers 四种类型，几乎能覆盖所有路由场景。
优势：
- 路由灵活度极高，适合复杂业务逻辑
- 管理界面成熟，开箱即用
- 支持延迟队列、死信队列等高级特性
- 社区活跃，文档齐全
劣势：
- 吞吐量有限，单机撑死几万 TPS
- 消息堆积能力差，积压多了性能断崖式下跌
- Erlang 语言小众，出问题排查困难
我的经验：曾经有个金融项目，需要根据交易类型把消息路由到不同的处理模块。RabbitMQ 的 topic exchange 一把梭，配置清晰，运维省心。但如果你的场景是每天几亿条日志，别碰它。
3.3 Kafka：吞吐量之王
Kafka 的设计哲学很纯粹——顺序写磁盘，零拷贝，批量压缩。说白了，它把 IO 效率压榨到了极致。
优势：
- 吞吐量极高，单机轻松百万 TPS
- 消息持久化能力强，堆积几亿条不降速
- 分区机制天然支持水平扩展
- Exactly-Once 语义支持完善
劣势：
- 运维复杂，依赖 Zookeeper（或 KRaft）
- 消息延迟较高，不适合毫秒级场景
- 路由能力弱，只有发布订阅模式
- 消息重复概率高，需要业务端去重
避坑指南：我曾经帮一个团队排查 Kafka 消费延迟问题。他们用了默认配置，消费端一次拉 500 条，每条处理 10ms，结果消费速度远低于生产速度。后来改成批量拉取 + 异步提交 offset，问题才解决。记住，Kafka 是为批量而生的，别拿它当 RPC 用。
3.4 RocketMQ：电商场景的实战派
RocketMQ 是阿里双十一练出来的。它的设计很务实，既有 Kafka 的高吞吐，又兼顾了 RabbitMQ 的灵活性。
优势：
- 事务消息支持完善，适合分布式事务场景
- 延迟消息精度高，支持秒级定时
- 消息轨迹追踪，排查问题方便
- Java 生态友好，二次开发成本低
劣势：
- 社区活跃度不如 Kafka
- 客户端 SDK 质量参差不齐
- 国外普及度低，英文资料少
适用场景：订单系统、交易流水、库存同步等需要事务保证的业务。RocketMQ 的事务消息 + 回查机制，能有效解决「发消息和本地事务不一致」的经典问题。
3.5 Redis Stream：轻量级的选择
Redis Stream 是 Redis 5.0 引入的特性。很多人把它当消息队列用，但我得说句实话——它更适合做「临时通道」。
优势：
- 部署简单，无需额外组件
- 延迟极低，微秒级
- 支持消费者组，类似 Kafka 的分组消费
劣势：
- 数据可靠性差，宕机可能丢消息
- 堆积能力弱，内存有限
- 功能单一，没有死信、重试等机制
我的建议：Redis Stream 适合做「轻量级任务队列」或「实时通知通道」。比如用户注册后发送欢迎邮件，丢了可以重发，这种场景用它很香。但核心交易数据，千万别放 Redis 里。
3.6 选型决策矩阵
你想想看，选型其实就三个维度：吞吐量、可靠性、灵活性。我画了一张图帮你理清思路。
3.7 选型速查表
最后给一张速查表，你直接对着业务场景找答案。
| 业务场景 | 推荐方案 | 理由 |
|---|---|---|
| 复杂路由、任务分发 | RabbitMQ | Exchange 机制灵活，死信队列方便 |
| 海量日志、埋点数据 | Kafka | 吞吐量碾压，堆积不降速 |
| 订单、交易、库存 | RocketMQ | 事务消息 + 高可用，适合核心链路 |
| 实时通知、轻量任务 | Redis Stream | 部署简单，延迟极低 |
| 物联网设备数据采集 | Kafka / RocketMQ | 设备多、数据量大，需要高吞吐 |
| 微服务异步解耦 | RabbitMQ / RocketMQ | 路由灵活，运维成本可控 |