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

先叠个甲

这篇文着重突出主观锐评，虽说有吞吐量、高可用这类硬指标作为参考，然而更多的是去讲讲后端老兵在实际生产环境当中的“血泪史”。

有关消息队列（MQ）此物，于面试之际满嘴皆是造火箭之事（诸如削峰填谷、异步解耦、最终一致性等），然一旦至线上之时，常常会出现这般情况：究竟是谁把我的消息给吞了？消息为何又重复出现了？哎呀，卧槽，队列怎么又堆积起来了？

简而言之，“夯”那便是如同安稳至极的老狗一般，在半夜时分根本无需起床去解决夜间生理需求；“拉”则是存在较多状况，其在进行运维工作时就好似去伺候极为难服侍的大爷一样。

固然没错啦，不存在最为废掉的MQ，仅有最为不契合的业务场景呢（求生欲又一次满满当当啦）。

咋评的？

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

它稳不稳定呢：消息会不会丢失？高并发情况下打过来会不会导致宕机？它快不快呀：吞吐量到底能不能达到预期？堆积几百万条消息后，性能会不会出现断崖式下跌？它用起来爽不爽呢：高级特性（延迟消息、顺序消息、死信队列）是不是可以直接使用？它行不行得通呢：运维成本高不高？报错信息是不是像那种很难懂的天书一样？关于夯了顶流、顶流被形容为硬通货的、名为RocketMQ的，顶级的、顶级被称作吞吐巨兽、数据之王的、名为Kafka的，小清新的、小清新是极简主义、Go圈特供的、名为NSQ的，NPC的、NPC功能齐全但却老态龙钟的、名为RabbitMQ的，拉完了的、拉完了也就是别闹了或者说是时代的眼泪的、名为Redis Pub/Sub (或List)的，总结如下包括一个建议是关于分层消息队列的。

RocketMQ

电商/金融闭眼选，业务特性拉满，稳。

顶级

Kafka

大数据、日志处理、超高并发选它。

小清新

NSQ

Go圈极简选它，部署一秒钟，没有运维包袱。

NPC

RabbitMQ

功能全、路由强，但高并发容易拉胯，老项目维持现状。

拉完了

Redis / ActiveMQ

别拿缓存当正经 MQ 考验人性；老古董快淘汰。

相关标签： # 消息队列 # RocketMQ # Kafka # NSQ # RabbitMQ