消息队列对比

引用：

常用消息队列对比
消息队列及常见消息队列介绍

常用消息队列

1. RabbitMQ

用erlang语言开发的消息队列系统，支持很多协议：AMQP，XMPP，SMTP，STOMP。非常重量级，适合企业级开发。核心是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由（Routing），负载均衡（Load balance）、数据持久化都有很好的支持。

主要特性：

• 跨平台，支持多种语言客户端
• 可靠性：提供了多种技术在性能和可靠性之间权衡，包括持久性机制、投递确认、发布者证实、高可用性机制。
• 灵活的路由：消息在到达队列前通过交换机进行路由。
• 消息集群：多个RabbitMQ服务器可以聚合在一起，作为一个单独的逻辑代理使用
• 队列高可用：队列恶意在集群中的机器上进行镜像
• 支持多种协议
• 管理界面
• 跟踪机制
• 插件机制：提供了许多插件进行多方面扩展，也可以自己编写插件

缺点：

• erlang不利于二次开发和维护
• 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。这个特性使得RabbitMQ易于使用和部署，但是运行速度较慢，消息封装后较大
• 需要学习比较复杂的接口和协议

2. ActiveMQ

由Apache出品的开源消息队列系统，是一个完全支持JMS 1.1和J2EE 1.4规范的JMS Provider实现。少量代码就可以高效实现高级应用场景，可插拔的传输协议支持。

主要特性：

• 服从JMS规范
• 连接性：支持多协议
• 持久化插件和安全插件
• 代理集群：多个ActiveMQ代理可以组成集群
• 异常简单的管理

优点：

• 跨平台，支持多种语言客户端
• 可以用JDBC持久化数据到数据库
• 支持JMS
• 支持自动重连
• 有安全机制，可以对Queue和Topic进行认证和授权
• 监控完善
• 界面友善

缺点：

• 社区活跃度不及RabbitMQ高
• 不适用于上千个队列的应用场景，而且据说会丢消息
• 目前重心在下一代产品Apollo上

3. RocketMQ

阿里的开源产品，用Java实现，参照kafka设计思想。

主要特性：

• 高性能、高可靠、高事实、分布式
• Producer、Consumer、队列都可以分布式
• Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个Consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合
• 能够保证严格的消息顺序
• 提供针对消息的过滤功能
• 提供丰富的消息拉取模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力
• 较少的依赖

优点：

• 单机支持1万以上持久化队列
• RocketMQ的所有消息都是持久化的，先写入系统PageCache，然后刷盘，保证内存和磁盘都有一份数据，访问时直接从内存读取
• 模型简单，接口易用
• 性能好，可以大量堆积消息在broker中
• 支持多种消费，包括集群消费、广播消费等
• 多个环节分布式扩展设计，主从HA
• 开发度较活跃，版本更新很快

缺点：

• 支持的客户端语言不多，只有java和c++，主要是java
• 社区关注度和成熟度不高
• 没有web管理界面
• 没有实现JMS等接口

4. ZeroMQ

C语言开发的，号称史上最快的消息队列，专为高吞吐量/低延迟的场景开发，可以在任何平台通过任何代码连接，通过inproc（进程内）、IPC（进程间）、TCP、TIPC、多播传送消息，支持发布-订阅、推-拉、共享队列等模式，高速异步IO引擎。

主要特性：

• 无锁的队列模型
  对于跨线程间的交互的数据交换通道pipe，采用无锁的队列算法CAS，在pipe两端注册有异步事件，在读或者写消息到pipe时，会自动触发读写事件
• 批量处理的算法
• 多核下的线程绑定，无需CPU切换

优点：

• 高吞吐，低延迟
• 简单灵活，专注传输层，使Socket编程更加简单

缺点：

• 要当消息队列用的话二次开发量大
• 不支持消息持久化
• 需要自己保证可靠性

5. Kafka

Linkedin发布并开源的分布式消息发布订阅系统，现在是Apache的顶级项目

主要特性：

• 快速持久化，通过磁盘顺序读写和零拷贝机制，可以在O(1)的系统开销下进行消息持久化
• 高吞吐，在一台普通的服务器上可以达到10W/s的吞吐速率
• 完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡
• 支持同步和异步复制两种高可用性集群
• 支持数据批量发送和拉取
• 数据迁移、扩容对用户透明
• 无需停机即可扩展机器
• 严格的消息顺序
• 丰富的消息拉取模型
• 高效订阅者水平扩展
• 实时消息订阅
• 亿级消息堆积能力
• 定期删除机制

优点：

• 支持多种语言客户端
• 性能好
• 完全分布式架构，并有replica机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积
• 支持批量操作
• 消费者采用Pull方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次
• 有优秀的第三方Kafka Web管理界面Kafka-Manager
• 在日志领域比较成熟

缺点：

• Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
• 使用短轮询方式，实时性取决于轮询间隔时间
• 消费失败不支持重试
• 支持消息顺序，但是一台代理宕机后，就会产生消息乱序
• 社区更新较慢

6. CMQ

CMQ(Cloud Message Queue) 是腾讯云基于开源消息引擎自研的一个是分布式消息系统。

主要特性：

• 消息生产实时3副本落盘
• 分布式Raft算法保证消息强一致
• 提供消息发布订阅、消息回溯、消息一对多投递、顺序消息等服务
• 具有高可靠、高可用、跨IDC、透明动态伸缩、消息接近生产消费等优势。

其他

比如Redis

MQ对比

--	RabbitMQ	ActiveMQ	RocketMQ	Kafka	CMQ
社区/公司	Mozilla Public License	Apache	阿里巴巴	Apache	腾讯
开发语言	Erlang	Java	Java	Scala & Java	应该是C++
客户端语言	多语言	多语言	Java，C++	Java为主，语言无关	多语言
协议支持	多协议支持	多协议支持	自定义	Tcp之上自定义	目前HTTP
消息批量操作	不支持	支持	支持	支持	支持
消息推拉模式	Pull，Push	Pull，Push	Pull，Push	Pull	Pull，Push
高可用	Master/Slave，master提供服务，slave备份	基于ZooKeeper + LevelDB的MS	支持多M，多MS，异步复制模式，多M多S模式，同步双写	replica机制，leader宕机会重新选举	leader重新选举
数据可靠性	可靠	M/S	可靠	可靠	可靠
单机吞吐量	万级	万级	低十万级	高十万级	高万级
消息延迟	微秒级	-	-	毫秒级	毫秒级
持久化能力	内存+文件，堆积量影响生产速率	内存+文件+数据库	磁盘文件	磁盘文件	磁盘
是否有序	单Client有序	可以有序	有序	多Client有序	单Client有序
支持事务	支持	支持	支持	不支持，但是可以通过Low Level API 保证仅消费一次	不支持
集群	支持	支持	支持	支持	支持
负载均衡	支持	支持	支持	支持	支持
管理界面	较好	一般	命令行	官方只有命令行	较好
部署方式	独立	独立	独立	独立	-
适合场景	非海量高可靠	非海量高可靠	海量大规模分布式系统	日志等海量数据流	-