【消息队列】开源消息队列与云消息队列调研
目录开源队列产品对比云队列产品对比调研总结1.针对自建队列产品：2.针对云队列产品：3.综合考虑：开源队列产品对比队列名称ActiveMQRabbitMQRocketMQKafka定位非日志的可靠消息传输非日志的可靠消息传输非日志的可靠消息传输系统间的数据量管道队列模式√√√√订阅模式√√√√回复模式√√
目录
开源队列产品对比
| 队列名称 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 定位 | 非日志的可靠消息传输 | 非日志的可靠消息传输 | 非日志的可靠消息传输 | 系统间的数据量管道 |
| 队列模式 | √ | √ | √ | √ |
| 订阅模式 | √ | √ | √ | √ |
| 多语言支持 | JAVA优先 | 语言无关 | JAVA优先 | JAVA优先 |
| 开发语言 | java | Erlang | java | Scala |
| 支持协议 | JSM、OpenWire、STOMP、REST、XMPP、AMOP | AMOP | 自定义的一套协议 | 一套自行设计的基于TCP的二进制协议 |
| 特点 | 功能齐全 | 性能好(快)，支持多语言 | 各环节分布式扩展设计；支持上万个队列；多种消费模式 | 成熟的日志领域 |
| 持久化 | 内存、文件、数据库 | 内存、文件 | 磁盘文件 | 磁盘文件 |
| 事务 | 支持 | 不支持 | 支持 | 不支持 |
| 可用性 | 高，主从 | 高，主从 | 非常高，分布式、主从 | 非常高，分布式、主从 |
| 部署方式 | 单机/集群 | 单机/集群 | 单机/集群 | 单机/集群 |
| 集群管理 | zookeeper | 自我支持 | name server | zookeeper |
| 选主方式 | 自动选举 |
自动选举 最早加入集群的broker |
不支持自动选举 通过设定 brokername，brokerid实现，brokername相同，brokerid=0时为master，其他为slaver |
自动选举 |
| 数据可靠性 | 好 |
好 producer支持同步/异步ack。 支持队列数据持久化，镜像模式支持主从同步 |
很好 支持roducer单条发送，broker端支持同步刷盘、异步刷盘、同步双写、异步复制 |
非常好 支持producer单条发送、同步刷盘、同步复制，但这种场景性能明显下降 |
| 负载均衡 | 支持 | 支持 | 支持 | 支持 |
| 写入性能 |
好 内存性能约为RocketMQ的1/2 磁盘性能约为RocketMQ的1/3 |
很好 每条10个字节测试：单机单broker约7w/s，单机3broker约12w/s |
非常好 每条10个字节测试：百万条/s |
|
| 单机支持队列数 | 默认配置为1000，基于内存 | 基于内存 | 单机最高支持5万个队列，load不会发生明显变化 | 单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长 |
| 性能稳定性 | 消息堆积时，性能不稳定，明显下降 | 队列较多，消息堆积时性能稳定 |
队列/分区多时性能不稳定，明显下降。 消息堆积时性能稳定 |
|
| 堆积能力 | 一般，生产者、消费者正常时，性能表现稳定；消费者不消费时，性能不稳定 | 非常好，所有消息存储在一个commit log中 | 非常好，消息存储在log中，每个分区一个log文件 | |
| 文档的完备性 | 高 | 高 | 中 | 高 |
| 首次部署难度 | 低 | 低 | 高 | 中 |
| 评价 |
优点： 成熟的产品，适合小规模场景 各种协议支持比较好 老牌产品，对Java语言支持很好
缺点： 性能一般 不适用于大量队列的应用场景 |
优点： 当前最主流的消息中间件 支持多种客户端语言、支持amqp协议 基于erlang开发，性能好；使用RAM模式时，性能也比较好 管理界面较丰富，在互联网公司有大规模应用 生态丰富，使用者众多
缺点： erlang语言难度大，集群不支持动态扩展 不支持事务、消息吞吐能力有限 消息堆积时，性能会明显下降 |
优点： 在高吞吐、低延时、高可用上有非常好的表现，消息堆积时，性能也很好 支持多种消费方式 顺序消费能力 支持broker消息过滤 支持事务 集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠
缺点： 相比于kafka，使用者较少，生态不完善，消息堆积、吞吐率有所不如 不支持自动主从切换，master失效后，消费者需要一定时间才能感知 |
优点： 高吞吐、低延迟、高可用、集群热扩展、集群容错都有非常好的表现 producer端提供缓存、压缩功能，可节省性能，提高效率 提供顺序消费能力 提供多种客户端语言 生态完善，在大数据方面有大量配套的设施
缺点： 消费集群数量收到分区数目的限制 单机topic多时，性能会明显下降 不支持事务 |
云队列产品对比
| 队列名称 | RocketMQ(阿里云产品) | RabbitMQ(阿里云产品) | CMQ(腾讯云产品) |
|---|---|---|---|
| 队列&订阅 | 满足 | 满足 | 满足 |
| 功能特性 |
多种消息类型 (普通消息、事务消息、定时和延时消息、顺序消息)、 消息重试、监控报警、集群消费等等功能 |
消息类型 (普通消息、延时消息) 资源报表、监控报警等等功能 比RocketMQ功能更少 |
腾讯自研 消息路由功能、配合云函数触发消息传递等等 功能上其实就是实现了队列的基本功能，只是增加了队列的可用性和简化了用户的操作 |
| SDK接入 |
区分社区和商业版SDK， 商业版支持语言种类更多(商业版支持go) |
阿里云推荐使用开源RabbitMQ SDK，支持多语言 | 支持语言种类少( Java、Python、PHP 及 C++ ) |
| 定价 |
分包年月和按量 根据topic数量收费，每个topic都大概需要几块/天 |
只支持包年包月 按queue数量计费，50个队列起售 约1200元/月 |
目前是免费的，2021年下半年会有一次升级，很可能改成收费 |
(自卖自夸)
阿里云RabbitMQ对比开源RabbitMQ：https://help.aliyun.com/document_detail/188208.html
腾讯云CMQ对比开源RabbitMQ,RocketMQ：https://cloud.tencent.com/document/product/406/4586
调研总结
1.针对自建队列产品：
ActiveMQ老练易用，与java兼容程度高，但性能一般
RabbitMQ性能好，响应速度快，使用率高、但性能稳定性不强，并且语言难度大，出现问题难以维护
RocketMQ综合能力强，高级特性多，但它是标准的发布-订阅模型，不完全遵循JMS协议，默认不支持(点对点+订阅)模式，这里需要自行扩展，基于topic可实现
kafka大规模分布式消息队列，吞吐数据能力强，但受到队列数量限制
2.针对云队列产品：
直接使用云的队列产品，优势是上手容易，有清晰的控制台管理队列，按他们文档的说法，自身的可用性和功能性都远远高于开源队列产品。
阿里云主推RocketMQ，功能是最完善的。
腾讯云产品功能有限，但是对队列有足够保障。
但阿里云的队列产品的话价格会比较昂贵，腾讯云队列后续很大概率会收费。
3.综合考虑：
单从调研来看，从性价比的方面考虑更推荐使用开源队列。
看上去三种队列都能满足一般需求。
RocketMQ似乎是最有潜力的。
参考文档(可能不全)
- https://blog.csdn.net/fxbin123/article/details/90261669
- https://blog.csdn.net/lyly4413/article/details/80838716
- https://tianjunwei.blog.csdn.net/article/details/84592864
- https://blog.csdn.net/zhuyanlin09/article/details/101751549
- https://blog.csdn.net/ffzhihua/article/details/103385399
- https://www.jianshu.com/p/027accb2b7ae
- https://blog.csdn.net/weixin_39738380/article/details/111611643
Kafka开源项目指南提供详尽教程，助开发者掌握其架构、配置和使用，实现高效数据流管理和实时处理。它高性能、可扩展，适合日志收集和实时数据处理，通过持久化保障数据安全，是企业大数据生态系统的核心。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)