Apache Pulsar, RabbitMQ, RocketMQ选型对比

本文将从五个维度对比RabbitMQ（3.8.4）、RocketMQ（4.7.1）、Pulsar（2.6.1），分别是功能维度、机器消耗维度、高可用维度、社区活跃度维度、学习资源维度。

功能维度

功能为度可以分为多个子维度，例如：优先级队列，延迟队列（定时消息），死信队列，事务消息，非持久化主题、消费重试，消息回溯，消息追踪，消息保留、消息生存时间、多租户，多协议支持，跨语言支持，流量控制，消息顺序性，安全机制（身份认证，权限控制），消息幂等性，多中心等等。

RabbitMQ（3.8.4）、RocketMQ（4.7.1）、Pulsar（2.6.1）这三款产品大都支持这些常见功能，值得注意的是：

RabbitMQ不支持延迟队列（定时消息）、消息过滤、消息回溯、消息保留。

RocketMQ不支持优先级队列、非持久化主题、消息生存时间、多租户、多中心。

Pulsar不支持事务消息（2020年10月底预计发布2.7.0版本包含预览版的事务消息功能）、优先级队列、消息过滤。

另外，Pulsar原生支持多中心方案，称作Geo-replication，相比RabbitMQ的多中心方案（对集群、Federation 和Shovel进行组合使用），配置运维相对来说更加简单易用。

具体见功能对比

总结：功能维度：Pulsar > RabbitMQ > RocketMQ

机器消耗维度

三节点集群	RabbitMQ	RocketMQ	Apache Pulsar
安装所需环境	1. Erlang环境 2. RabbitMQ安装包	1. JAVA环境 2. RocketMQ安装包	1. JAVA环境 2. Pulsar安装包
包含组件	rabbitmq-server	NameServer、Broker	ZooKeeper、BookKeeper、Broker
机器消耗	3	最少3；最多6	最少3；官方建议6；最多9

备注：RabbitMQ和Apache Pulsar的三个节点都可以收发消息，而RocketMQ在主节点可以收发消息，从节点可以向Consumer发消息但是不能接收Producer的消息。

具体见机器消耗对比：

总结：机器消耗维度，RabbitMQ > Pulsar > RocketMQ

高可用维度

RabbitMQ高可用

RabbitMQ 只有Rabbitmq-server这一个组件，依赖「镜像队列」功能实现镜像集群：每个RabbitMQ节点既保存有队列相同的元数据，又保存有队列实际的消息数据。 任一节点宕机，不影响消息在其他节点上进行消费。缺点在于：

1. 性能开销非常大，因为要同步消息到对应的节点，这个会造成网络之间的数据量的频繁交互，对于网络带宽的消耗和压力都是比较重的
2. 扩展性差，rabbitMQ是集群，但不是分布式的，所以当某个Queue负载过重，并不能通过新增节点来缓解压力，因为所有节点上的数据都是相同的，这样就没办法进行扩展了
3. 镜像队列不是负载均衡，因为每个操作在所有节点都要做一遍。镜像队列无法提升消息的传输效率，或者更进一步说，由于镜像队列会在不同节点之间进行同步，会消耗消息的传输效率。

RabbitMQ 3.8版本加入「仲裁队列」作为「镜像队列」的替代方案，仲裁队列使用了Raft协议的一种变体，该协议已成为业界事实上的分布式共识算法。与镜像队列相比，它既安全又实现了更高的吞吐量。缺点在于：目前功能不够完善，缺少一些队列特性的支持，比如：非持久化消息；独占型队列；队列/消息生存时间TTL等等。

RocketMQ高可用

RocketMQ集群包含两个组件：NameServer集群、Broker集群。每台NameServer 机器都拥有所有的路由信息，包括所有的 Broker 节点信息、数据信息等 ，这样只要有一台 NameServer 存活就不会影响系统的稳定性。若Master Broker 挂掉，RocketMQ4.5 版本之前，是人工运维，通过人手工切换Master Broker，RocketMQ4.5 之后，通过Dledger 技术以及Raft 协议进行leader 选主。整个过程很快，大概十几秒或者几十秒就能完成切换动作，完全的全自动的将Slave Broker 选为Master broker 对外提供服务，实现高可用模式。

Pulsar高可用

Pulsar 集群包含 3 个组件：ZooKeeper 集群、BookKeeper 集群和 Broker 集群。

ZooKeeper 集群通常由一组机器组成，一般 3 台以上就可以组成一个可用的 ZooKeeper 集群。

组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。只要集群中存在超过一半的机器能够正常工作，那么整个集群就能够正常对外服务。

Broker 集群中的各个broker 是无状态的，如果拥有某个Topic的Broker崩溃，则将该Topic立即重新分配给另一个Broker。当发生 Topic 的迁移时，Pulsar 只是将所有权从一个 Broker 转移到另一个 Broker，在这个过程中，不会有任何数据复制发生。

Broker 的无状态性质使动态分配成为可能，因此可以根据使用情况快速扩展或收缩集群。

BookKeeper 集群包含一组Bookies节点，一个Topic由多个Ledger构成，一个Ledger由一个或多个Fragment组成，每个Fragment有多个条目Entry组成，每个Entry上包含的就是消息Message。Fragments分布在Bookie集群中，跨多个Bookies带状分布。存储可以单独扩展。如果存储是瓶颈，那么只需要添加更多的Bookies，他们会自动承担负载，不需要Rebalance。当Bookie不可用时，自动恢复模式将自动进行数据重新复制到其他的Bookies。

此外，BookKeeper 通过 Quorum Vote 的方式来实现数据的一致性，跟 Master/Slave 模式不同，BookKeeper 中每个节点也是对等的，对一份数据会并发地同时写入指定数目的存储节点。对等的存储节点，保证了多个备份可以被并发访问；也保证了存储中即使只有一份数据可用，也可以对外提供服务。

具体见高可用对比

总结：高可用方面，Pulsar > = RocketMQ > RabbitMQ

社区活跃度维度

从GitHub上各社区的数据对比，官方仓库start数目上，RocketMQ基本上是另外两款产品的两倍；Issues数目上来看，Pulsar的open数量是RabbitMQ的将近11倍，是RocketMQ的5倍，说明Pulsar还在一个快速迭代的过程中，相对于另外两款欠缺一些稳定性。但是这也从一方面说明了

社区活跃度方面，Pulsar > RocketMQ > RabbitMQ。

学习资源维度

RabbitMQ官网文档非常详细，加上产品成立年份较早，在互联网上可以搜索到非常多的相关教程和书籍（比如B站搜索RabbitMQ，搜索结果29页）。但是由于是Erlang语言编写，二次开发是一个比较高的成本问题。

RocketMQ虽然是阿里开源的项目，但是官网文档和中文文档都比较简陋。但是用JAVA编写，二次开发难度降低，学习的相关教程和书籍也有很多（比如B站搜索RabbitMQ，搜索结果9页）。

Pulsar由于产品较新，学习资源非常有限（比如B站搜索RabbitMQ，搜索结果3页），目前甚至没有一本教程书籍，只能主要依赖官网文档进行学习，但是中文界面翻译又不够完善，还存在很多格式问题，只能看英文版。

总结：学习资源方面，RabbitMQ >= RocketMQ > Pulsar