上篇文章“[MQ]消息队列与企业服务总线的简单比较，MQ&ESB”是宏观概念，这个表格是基于主流MQ产品的功能特性做的初步梳理。重点看了RabbitMQ，其他MQ产品只是简单了解（未论证和研究）。供参考备忘。
如果有理解上的偏差，也顺手请留言指正。谢谢！
| 说明 | RabbitMQ | ActiveMQ | ZeroMQ | RocketMQ | Kafka | Redis | |
| 产品简介 | 开发语言：Erlang | 开发语言：Java | 开发语言：C/C++ | 开发语言：Java 阿里参照Kafka设计思想实现的，但对消息的可靠传输及事务性等做了优化。 |
开发语言：scala | 开发语言：C 它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。 |
|
| 产品特点 | 高并发支持好 稳定性和可靠性好 |
号称最快的消息队列系统，偏重于实时数据通信场景。 无独立服务器，可当作一个组件库来用。 |
追求高吞吐量，一开始的目的就是用于日志收集和传输。 | ||||
| 协议支持 | AMQP STOMP(1.0, 1.1，1.2) MQTT HTTP(有三种方式) XMPP |
AMQP MQTT OpenWire STOMP |
zmq_ipc(本地进程间通讯) Socket(TCP,INROC,IPC,PGM) |
自定义 | 基于TCP的自定义协议 | 自定义redis协议 | |
| 集群支持 | 支持 | 支持 | 无 | 支持 | 支持 | 支持 | |
| 消息存储 | 磁盘文件、内存 | 磁盘文件，本地数据库(KahaDB/LevelDB)、JDBC | 不支持（为了提高性能） | 磁盘文件 | 磁盘文件 | 磁盘文件 | |
| 消息交互模式 | 1.点对点模式(point to point)(p2p) 保证每个消息都能消费，且只被消费一次（消费者接收到消息后要发送一条确认信息，然后队列就移除该消息）。 2.订阅发布模式(publish/subscribe) 广播模式，一个消息人人都可消费（生产者产生消息并发送到指定主题(topic)的队列中，消费者订阅主题(topic)，所有订阅者都能拿到消息）。 3.请求响应模式 请求端发起请求，并等待回应端回应请求。 4.管道模式(push pull) <-还没理解清楚，是基于1的变种应用? 单向发出，每个消息只有一个接收者。 |
点对点模式 订阅发布模式 |
点对点模式 订阅发布模式 |
请求响应模式 订阅发布模式 push pull模式 |
订阅发布模式 | 订阅发布模式-消费者拉取消息 | |
| 消息的消费模式 | 支持的两种模式： 1.push模式（推） 服务端收到消息后，主动将消息推给消费者。 优点：实时 缺点：推送量超过消费者的处理能力，造成消息堆积。 2.pull模式（拉取） <-轮询? 服务端收到消息后什么也不做，等者消费者主动来拉取。 优点：按处理能力拉取 缺点：实时性低 |
push模式（推） pull模式（拉取） |
push模式（推） pull模式（拉取） |
push模式（推） pull模式（拉取） |
pull模式（拉取） | ||
| 消息确认机制 | 是消息可靠投递的保障手段。ACK-成功，NACK-失败。 1.生产端消息确认 生产者投递消息后，如果服务端收到消息，则返回一个应答； 如果不成功(返回失败或超时)，则服务端不会有这个消息，生产端可选择重传等补偿措施。 2.消费端消息确认 a)消费者收到消息后，给服务端返回一个应答确认； b)分自动确认和手动确认； 自动确认-消息发送给消费者后立即确认(消费者处理消息时出错会造成“消息丢失”)； 手动确认-消费者指定接收成功与否； c)如果不成功(返回失败或超时)，会重回队列以及自行实现补偿措施； >>根据实现技术又可分为单条确认，批量确认，批量异步确认 |
支持 | 支持 | 无 | 支持 | ||
| 消息事务 | 事务范围是一个消息的投递过程（生产者到服务端，或者服务端到消费者），要么投递成功，要么回滚。目的也保证消息的可靠性。回滚的效果： 生产者发消息回滚-服务端不会有这个消息 消费者接收消息回滚-重新放回服务端消息队列 >>因为事务的性能没有“消息确认机制”高，所以通常不推荐(?) |
支持 | 支持 | 无 | 无 | ||
| 批量消息 | 生产端批量发送消息 <-意义？ | 支持批量发送消息 支持批量拉取消息-pull模式 |
支持批量发送消息 | 支持 | 不支持 | 支持 | 支持 |
| 延时消息 | 延时消息/定时消息，主要是投递。 将消息发送到MQ服务端，但并不立马投递，而是延迟一定时间猜投递(延时消息)或在之后的某个时间点才投递(定时消息)。 |
无（但可通过死信队列机制实现） | 支持 | 无 | 支持 | 无 | |
| 消费者限流机制 | 消费端为push模式（服务端推消息）时，能够对消息的推送做规则限定。 如：超过当前处理量限定、消息数据大小限定后暂停推送。 |
qos (服务质量保证)功能 在非自动确认消息的前提下，如果指定数目的消息未被确认前，不消费新的消息。 |
无 | ||||
| 消息顺序性 | 其实各个MQ产品都并没严格去实现消息的顺序。 1.“消费者拿到消息 vs. 消息被处理完”是两个概念，好比“拿到一个任务 vs. 把任务处理完”。而MQ只负责把消息发到消费者，并不涉及处理这个环节。 2.MQ的单个消息队列，消息都会按放入的顺序被消费（先放入的先被消费）。但消息队列同时能存在多个，如果放入不同队列，也没办法保证顺序。 3.即便单个消息队列中的消息是有顺序的，但也有异常情况可能打乱这个顺序。如：如事务回滚后重发，就会导致顺序被打乱。 顺序控制，确实也应该在业务实现层去。 |
每队列单消费者有序 | 每队列单消费者有序 | 无 | 每队列单消费者有序 | 每队列单消费者有序 | 有序 |
| 消息优先级机制 | 优先级高的消息会被优先消费。 注意，只在有消息堆积的情况下，才存在优先级一说。 |
支持 | 支持 | ||||
| 消息重发机制 | 消息收发失败后的重发机制。 | 无 | 支持设置重发策略 | 无 | 支持 | 无 | |
| 消息重复机制 | 也应该在业务层去实现，而不在MQ一层解决。 在MQ这一层在异常情况下是可能出现消息重复的：重复发布，重复消费。如：网络故障导致消费者消费了消息，但消息队列没得到ACK的接收成功响应。 |
无 | 无 | 无 | |||
| 消息清理机制 | 超过设定时间则做清除处理。通过设置TTL(Time To Live)，即生存时间来实现。 | 1.发送时指定 2.队列上指定 |
支持 | 过期删除 | 过期删除 | ||
| 死信队列机制 | DLX - 死信队列(dead-letter-exchange) 不能正常被处理的消息会进入特殊队列。如： 消息被拒绝，且设置为不重发； 消息过期被清理(超过TTL) 队列达到最大长度 可监听这个队列并做后续处理，有的产品只支持人工干预。 |
支持 | 支持 | 支持（但放入后只能人工干预） | 无 | ||
| 消息路由 | 根据匹配条件，将收到的消息放置到不同的消息队列。 | 1.根据发布订阅的主题(Topic)过滤 - 字符串通配符 2.根据消息头henders匹配 - 是1的加强版，通过多组条件来匹配。消息头可以传入多组值，来用于匹配运算<参见行最后一列的图>。 |
支持 | ||||
| 消息复制 | 两种情况，特指后者： 1.在多服务器集群使用时，为了保障消息不丢，复制到其他服务器。 2.收到消息后，创建消息的副本放入其他队列。 |
不直接支持。 但通过消息过滤能实现 |
无 | ||||
| 消息过滤 | 消费者对消息的过滤 方式一：RocketMQ的 topic ag 方式。tag标签可以看做另一个维度的主题(暂理解为分类)，方便消费者按tag来做进一步过滤。 方式二：ActiveMQ 的selector，配合前端的Stomp的header中的selector实现消息的过滤。 |
无 | selector | topic ag | 支持 | ||
| 消息查询 | 查询队列消息 已消费/未消费消息查的询 消息轨迹的查询 ... |
|
分享请注明出处
本文链接：https://blog.csdn.net/debug_fan/article/details/105074769