是否选择使用标准消息队列产品，取决于你的数据和业务场景的需求。当数据量大、场景复杂后，才必须引入标准消息队列，因为它有高吞吐、持久化、长久堆积的特性。

业界都有哪些消息队列

RabbitMQ支持延时消息、死信队列、优先级队列、事务消息等等。 RabbitMQ 是 2007 年由国外一家叫做 Rabbit 的公司开源的，用 Erlang 写成的消息队列。主要满足业务中消息总线的场景。特点是功能丰富，低流量下稳定性较高，基本具备消息队列所应该具备的所有功能。缺点是在大流量的情况下会有明显的瓶颈和稳定性风险。

ActiveMQ 项目最初是由 LogicBlaze 的创始人于 2004 年创建的，支持实现 JMS 规范的消息队列。因为生态、功能定位方面的原因，在国内用的人并不多。 

AMQP 是一个消息队列协议规范，它不是一款具体的消息队列。因为不同消息队列的访问协议是不一样的，导致不同的消息队列需要用不同的 SDK 访问，客户的切换成本很高。2003 年，多个金融服务机构希望制定一个消息队列的协议规范，希望不同的消息队列的协议都根据这个标准实现，这样就可以不需要重复开发 SDK，不同的应用程序之间的交互和切换可以更简单、更方便。这就是 AMQP 的由来。

RocketMQ 在定位上和 RabbitMQ 很像，功能丰富，在业务消息中经常会用到。不过 RocketMQ 是在移动互联网浪潮下发展起来的，业务场景更加复杂，也支持更多功能，比如消息 Tag、消息轨迹、消息查询等等。RocketMQ 是 2013 年阿里研发，2016 年开源，可满足大规模微服务场景的消息队列产品。可以理解为是 RabbitMQ 的高可用、分布式升级版。功能丰富，基本可以满足业务消息场景下的所有需求。稳定性、数据可靠性方面的表现都较好。性能介于 RabbitMQ 和 Kafka 之间。

Pulsar 和 Kafka 很像，主要定位在流领域，主打大吞吐的流式计算。但 Kafka 的功能比较简单，支持基本的发布订阅、幂等、事务消息。Pulsar 在满足这些功能的基础上，也希望支持 RocketMQ 和 RabbitMQ 的功能，所以功能最丰富。Pulsar 的架构设计比 Kafka 更符合当前云原生架构，它的定位是 Kafka 的升级版，主要解决 Kafka 当前的一些痛点问题，比如集群扩缩容慢、分区迁移需要 Rebalance、无法支持超多分区等。性能目前没有特别大的差距。不过 Pulsar 发展时间较短，架构较复杂，功能支持较多，当前阶段在稳定性上 Kafka 会比 Pulsar 好非常多。

此文章为11月Day1学习笔记，内容来源于极客时间《深入拆解消息队列 47 讲》