从夯到拉，锐评5大主流消息队列

先叠个甲

这篇文主打一个主观锐评，虽然参考了吞吐量、高可用这些硬指标，但更多的是聊聊后端老兵在实际生产环境里的“血泪史”。

消息队列（MQ）这东西，面试的时候全在造火箭（削峰填谷、异步解耦、最终一致性），真到了线上，往往是谁吞了我的消息？消息怎么又重复了？卧槽队列怎么又堆积了？

简单说，“夯”就是稳如老狗，半夜不用起夜；“拉”就是坑有点多，运维起来像伺候大爷。

当然了，没有最废的MQ，只有最不合适的业务场景（求生欲再次拉满）。

咋评的？

不整那些跑分对比了，主要看这几点：

1. 稳不稳：丢不丢消息？高并发打过来会不会宕机？
2. 快不快：吞吐量到底行不行？堆积几百万条消息后，性能会不会断崖式下跌？
3. 爽不爽：高级特性（延迟消息、顺序消息、死信队列）是不是开箱即用？
4. 坑不坑：运维成本高不高？报错信息像不像天书？

🔥 夯（顶流，硬通货）

RocketMQ

• 一句话评价：阿里双十一抗压王，金融级业务的“标准答案”。
• 为什么夯： 如果你在做电商、支付、订单系统，或者团队在纠结选啥，闭眼选 RocketMQ。它是真刀真枪在极端并发下验证过的，设计上极其偏向业务。
• 强在哪： 原生支持延迟消息（不用自己搞定时任务或者死信队列绕弯子）、事务消息、顺序消息。而且用 Java 写的，国内大厂后端改起源码来毫无压力。消息堆积能力极强，堆个几亿条也不怎么影响读写性能。
• 适合谁： 对消息可靠性要求极高、业务逻辑复杂的企业级应用，尤其是电商和金融领域。

💎 顶级（吞吐巨兽，数据之王）

Kafka

• 一句话评价：吞吐量天花板，大数据的唯一真神。
• 咋样： 如果说 RocketMQ 是个精细的账房先生，Kafka 就是个狂暴的泥头车。它的吞吐量极其恐怖，动辄百万级 TPS，日志收集、流处理、数据同步领域，它是绝对的统治者。
• 注意点： Kafka 追求的是极致的吞吐和速度，所以牺牲了一部分业务灵活性（比如不支持灵活的延迟消息，Tag 过滤也比较弱）。而且早年重度依赖 ZooKeeper（现在慢慢剥离了 KRAFT），运维门槛不低，一旦集群出问题，恢复起来让人头皮发麻。
• 适合谁： 海量日志处理、用户行为轨迹埋点、大数据流计算。

👤 小清新（极简主义，Go圈特供）

NSQ

• 一句话评价：我就想简单发个消息，别给我整那些复杂的集群。
• 咋样： 纯 Go 编写，没有任何外部依赖（不需要 ZooKeeper、Raft 啥的），部署极其简单，下载个二进制文件一跑就完事了。去中心化架构，天生高可用。
• 坑点： 它默认是内存存储（可以配落盘），而且不保证消息的强顺序性，甚至在极端情况下可能会重复投递或者丢消息（依赖客户端重试机制）。
• 适合谁： Go 技术栈团队，追求极简运维，业务对消息丢失和乱序有一定容忍度，或者做内部系统异步通知的。

🤖 NPC（功能齐全，但老态龙钟）

RabbitMQ

• 一句话评价：曾经的万金油，现在的高并发软肋。
• 咋样： 这货是基于 Erlang 写的（AMQP协议），路由机制（Exchange）极其灵活强大，功能非常全面，早年间中小公司几乎人手一个。后台管理界面做得也是最漂亮的。
• 现状： 一旦并发量上去，或者消息开始大量堆积，RabbitMQ 的性能会断崖式下跌。而且 Erlang 这个语言太小众了，国内能看懂源码甚至做二次开发的团队屈指可数，出了底层 Bug 只能干瞪眼。
• 适合谁： 并发量不大、对路由规则要求极高的传统企业级业务。新一代的高并发互联网项目很少首选了。

💀 拉完了（别闹了/时代的眼泪）

Redis Pub/Sub (或 List)

• 一句话评价：你是个缓存，别来抢 MQ 的饭碗好吗？
• 咋拉： 很多人图省事，直接拿 Redis 的 Pub/Sub 当消息队列用。但凡网络抖一下，或者消费者下线一秒钟，消息就永远消失了，连个渣都不剩。用 List 做队列稍微好点，但没有 ack 机制，没有高级特性。虽然 Redis 后来出了 Stream，但用它做正经 MQ 的人依然寥寥无几（毕竟怕撑爆宝贵的内存）。
• ActiveMQ（真·时代的眼泪）： 顺便鞭尸一下 ActiveMQ，十年前的王者，现在连 Apache 官方都懒得大力更新了，吞吐量低、偶发丢消息。快跑。

总结一下