[MQ]消息队列产品的功能整理

上篇文章“[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 \tag 方式。tag标签可以看做另一个维度的主题(暂理解为分类)，方便消费者按tag来做进一步过滤。 方式二：ActiveMQ 的selector，配合前端的Stomp的header中的selector实现消息的过滤。	无	selector		topic \tag	支持
消息查询	查询队列消息 已消费/未消费消息查的询 消息轨迹的查询 ...

分享请注明出处
本文链接：https://blog.csdn.net/debug_fan/article/details/105074769