| 组件 | RocketMQ | RabbitMQ | ActiveMQ | Kafka | Redis | ZeroMQ | Pulsar支持云原生，发展潜力大 |
| 协议 | 支持Tcp，JMS，openMeesaging | 支持AMQP，XMPP，SMTP，STOMP | 支持AMQP MQTTJMS协议 | 支持Tcp接入 | 没有什么队列协议，支持订阅模式 | TCP、UDP、IPC、广播 | TCP |
| 性能 | 10万条/秒 | 万级 | 万级 | 单机写入 TPS 号称在百万条/秒 | 万级 | 万级 | 万亿，计算与存储分离，易扩展 |
| 可靠性（消息丢失） | 支持异步/同步刷盘;异步/同步Replication支持磁盘 | 经过消息确认、持久化等手段保证，支持内存，文件 | 较低概率丢失数据，支持内存，文件，数据库 | 异步刷盘方式，异步Replication较低概率丢失数据 | 内存型，提供aof，rdb两种但是还是会丢失 | 有多种可靠性，请求回应方式https://zguide.zeromq.org/docs/chapter4/ | 通过broker分布式存储 |
| 时效性 | 支持push模型，pull模型 | 支持push模型，pull模型 | Push 模式毫秒级 | pull 模式支持pull长轮询 | pull模式1：M | Pull 与 push 模式支持 N：M | Pull 与 push 模式支持 N：M |
| 持久化 | 高性能和低延迟的文件存储同步刷盘 异步刷盘 | 高性能文件存储 | 需要外带高性能日志系统，如leveldb | 通过磁盘顺序读写与零拷贝机制 | aof和rdb两种机制进行持久化，但还是会丢失(pub/sub) 有个缺点就是消息无法持久化Stream。它提供了消息的持久化和主备复制功能 | 支持，在消息发送端保存https://zguide.zeromq.org/docs/chapter4/#Disconnected-Reliability-Titanic-Pattern | 通过broker分布式存储，raft 协议同步数据，也就是过半成功才返回ack给生产者 |
| 队列数 | 单机支持最高5万个队列，性能稳定 | 5w个队列，单机单线程https://www.cloudamqp.com/blog/part1-rabbitmq-best-practice.html | 单机超过64个队列/分区，消息发送性能降低严重 | 本来是通过自身数据结构存储，看内存 | |||
| 事务 | 支持，通过半消息实现（暂存到mqserver，不提供给消费者，生产者的本地事务全完成才给消费者，否则把消息丢弃）https://rocketmq.apache.org/rocketmq/the-design-of-transactional-message/https://help.aliyun.com/document_detail/112010.html?spm=a2c4g.11186623.6.564.49ff2d67ZYvxCl | 事务机制有关的方法有三个：txSelect(), txCommit()以及txRollback() | 支持 | 不支持 | 支持 | 不支持 | 支持https://pulsar.apache.org/docs/en/transactions/ |
| 死信 | 支持 | 支持专门有一个dead letter exchange进行存储 | 支持 | 不支持 | 不支持，需要额外开发 | 不支持 | 支持 |
| 批量发送 | 支持，1024条，设定缓存条数，时间进行批量消费 | 不支持 | 不支持 | 支持，带有异步生产者 | 不支持 | 支持，订阅模式1:N N:M, 它会进可能发送所有消息http://wiki.zeromq.org/area:faq | 支持 |
| 消息有序性 | 严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序 | 保证独立分区消息的顺序 | 独立消费者、独立队列保证消费有序 | 保证独立分区内消费的顺序，但一台Broker down机，机会产生消息乱序 | Pipelining一个消费者 | 不支持 | 支持，通过分区实现，使用 SinglePartition或者RoundRobinPartition模式 |
| 延迟推送 | 支持 | 可支持，通过TTL设置消息到死信队列中进行消费https://www.cnblogs.com/mfrank/p/11260355.html | 支持NMS schedule | 不支持 | 能支持blpop/brpop，需要在消费端实现，但是这样会让消费端阻塞 | 本身不支持，需要额外实现 | 支持 |
| 广播消息 | 支持集群消费：当使用集群消费模式时，消息队列RocketMQ版认为任意一条消息只需要被集群内的任意一个消费者处理即可。广播消费：当使用广播消费模式时，消息队列RocketMQ版会将每条消息推送给集群内所有注册过的消费者，保证消息至少被每个消费者消费一次。 | 支持 | 支持 | 不支持 | 支持 | 支持，Push-Pull模型实现 | 支持，其实就是订阅多个消费者，使用push方式 |
| 消息过滤 | 支持 | 不支持，但可以自行封装。 | 支持 | 支持，使用 streams过滤消息 | 支持，streamed message | 不支持 | 支持 |
| 消息查询 | 根据message id | 支持Producer客户端设置Message ID属性，为每条消息设置唯一标识符 | 只能针对主题，额外用命令过滤查询 | 不支持 | Redis streams支持 | 不支持 | 支持，支持sqlhttps://pulsar.apache.org/docs/zh-CN/next/sql-getting-started/ |
| 消息回溯 | 支持，支持按照时间回溯 | 不支持。RabbitMQ中消息一旦被确认消费就会被标记删除 | 不支持 | 支持，offset查找，但确定不了那个消费者，那个生产者生成，消费 | 不支持 | 不支持 | |
| 消息优先 | 支持 | 支持 | 支持 | 支持，按offset进行 | 支持，需要在消费端实现 | 不支持 | 支持 |
| 消息重发 | 支持，重试间隔时间顺延 | 不支持 | 不支持 | 支持 | 不支持 | 不支持 | 支持 |
| 消息积压（消费不来） | 能够持久化 | 支持 | 支持 | 支持topic下消费者较长时间离线，消息堆积量大 | 支持 | 不支持 | |
| 消息确认 | 支持 | 支持 | 支持 | 支持 | 支持，维护两个队列：pending队列和doing表 | 支持 | 支持，消费者ack确认，给broker，从而可删除消息体 |
| 信息轨道追踪（生产者，消费者，队列的信息状态）https://help.aliyun.com/document_detail/43357.html | 可以通过Message ID、Message Key或Topic的时间范围查询相关的消息轨迹，找到消息的实际收发状态，帮助诊断问题 | 支持 | 不支持 | 不支持 | 不支持 | 不支持 | 不支持 |
| API完备性 | SDK支持丰富 | SDK支持丰富 | SDK支持丰富JMS版本多 | SDK丰富，大多支持TCP | SDK丰富 | SDK丰富 | SDK丰富 |
| 分布式系统高可用 | 非常高(分布式架构) | 集群模式 | 主从，取决于存储，如果是用kahadb ，需要zookeepr支持 | 分布式架构Broker、Producer、Consumer都原生自动支持分布式， | 集群，哨兵，主从 | 去中心化，不支持集群 | 非常可靠，分布式系统 |
| 消息分发 | round-robin轮询机制，轮询消费者 | round-robinprefetchCount，消费者来不及处理，消息会堆积在队列中，新启动的消费者可以马上从队列中取到消息开始工作 | 轮询（默认）或按照严格顺序 | 依赖zookeeper自动实现复杂均衡zookeeper管理集群中的broker sonsumer，通过zookeeper的协调机制，producer会记录topic对应的broker，对broker进行轮询或者随机访问broker | 轮询机制只能一个topic 一个consumer | 接收端负载均衡 | 支持轮询机制sharding机制 |
| 管理界面、监控指标 | 支持web管理工具丰富支持web和终端命令 | 支持web和终端命令运维工具丰富 | 支持，使用一般 | 支持，终端命令 | 有丰富的运维指令，需要额外按照非官方的管理工具 | ZMQ 协议开放监控内容，需要自己开发https://blog.csdn.net/yaomingyang/article/details/101380723 | 支持web管理工具丰富支持web和终端命令https://pulsar.apache.org/docs/zh-CN/next/admin-api-overview/ |
| 社区支持、文档完备 | 阿里与apache社区支持 | 完整 | 成熟，社区活跃高，现在维护越来越少 | 完善 | 完善 | 少 | 完善，而且国际化 |
| 权限控制 | 用户方面：ACL特性服务方面：所有服务组件API级别的鉴权 | 支持SSL、SASL身份认证和读写权限控制。 | 用户验证队列增删改授权 | 支持SSL、SASL身份认证和读写权限控制 | 单一，只有用户验证 | 无 | 多租户系统设计用户与服务都支持鉴权 |
| 热启动实时修改参数不用重启节点，直接reload实时加载 | updateBrokerConfig更新 broker信息，不用重启而且能够在nameserv 上进行分发 | rabbitmqctl eval大部分参数能够变更如果需要升级整个node需要红绿部署 | 支持runtimeConfigurationPlugin checkPeriod=”1000″ | 支持动态修改Dynamic Update Mode通过zookeeper 同步所有broker | 支持 | 不支持 | ？ |
| 流量控制 | 基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面。 | 异步发送如果超过内存阀值，也就是活动窗口 ProducerWindowSize 就会进行阻塞https://activemq.apache.org/producer-flow-control | 支持client和user级别，通过主动设置可将流控作用于生产者或消费者。 | 需要自身实现 | 不支持 | 多租户，能够适当低进行磁盘配额、流控制、限流调节 | |
| 多租户 | 开源版本没有 | 支持Virtual Hosts | 不支持 | 没有 | 不支持 | 不支持 | 支持 |
| 冷热数据 | 支持，分层存储，当 backlog 大小到达如10m，也可以精细到topichttps://pulsar.apache.org/docs/en/concepts-tiered-storage/ | ||||||
| 特点 | 场景异步解耦秒杀或团队抢购活动（削峰填谷）大规模机器的缓存同步分布式事务的数据一致性https://help.aliyun.com/document_detail/112010.html?spm=a2c4g.11186623.6.564.49ff2d67ZYvxCl | Erlang 并发性能好 | 功能齐全 | 日志处理 | 基本上都需要自身实现队列的所有事情基本上 Redis Streams 是比较容易实现消息队列 | 支持高并发的异步 Socket 框架支持的通讯模型适用于大型集群和分布式计算多线程去锁化定位只是一个多线程网络库场景分布式任务分发，如游戏加机saltstack的底层就使用了ZeroMQ作为通信机制Mongrel2是使用ZeroMQ开发的一个Web服务器 | 计算与存储分开易水平扩展多租户低延迟多地理集群复制基本上所有队列的特性都包含并且提供高可用的解决方案 |
版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明消息队列技术选型对比！
