【消息队列】几个mq组件的对比: redis stream/rabbitmq/rocketmq/kafka

1. 消息队列

几个组件：

• Redis Stream：实用于对性能要求高、可靠性要求不高的场景
  
• Rocket MQ：可靠性高，性能精良，但官方对 go 不太友爱，sdk 缺少很多功能支持
  
• Rabbit MQ：性能适中，利用较复杂，路由、绑定等利用增长了学习资本
  
• Kafka：实用于高吞吐量场景，设置机动但复杂
  

可靠性：RocketMQ > Kafka > RabbitMQ > Redis Stream
性能：Kafka > Redis Stream > RocketMQ > RabbitMQ
程度扩展：Kafka > RocketMQ > RabbitMQ > Redis Stream
利用复杂度：Redis Stream < RabbitMQ < RocketMQ < Kafka

特性对比

生产者：

特性	Redis Stream	Rocket MQ	Rabbit MQ	Kafka
主动创建 topic	支持	不支持，可开启rocketmq设置但官方不发起	不支持，需声明互换机	支持，需开启kafka设置
topic 范例	无	多种，一样平常利用 FIFO 次序消息范例	多种，一样平常利用 fanout 发布订阅模式	无
指定分区	不支持	支持	不支持	支持
长期化	支持	支持	支持	支持
消息整理计谋	生产消息时可设置 MaxLen 队列可容纳的最大长度（默认永世生存）	通过设置文件设置消息生存最长时间（默认未消耗的消息生存3天）	初始化队列时可设置x-message-ttl 消息生存最长时间（默认未消耗消息永世生存）	通过设置文件设置消息生存最长时间（默认未消耗的消息默认生存7天）

消耗者：

特性	Redis Stream	Rocket MQ	Rabbit MQ	Kafka
主动创建消耗者组	支持	不支持，可开启rocketmq设置但官方不发起	不支持，需声明队列并绑定互换机	支持，需开启kafka设置
单次拉取消息的巨细限定	可设置最大拉取个数	可设置maxMessageNum 最大拉取个数	可通过 Qos 设置最大拉取个数	可设置拉取的最大消息巨细（字节）
单次拉取消息的方式	可设置壅闭拉取/主动拉取	主动拉取	壅闭拉取	壅闭拉取
消耗的起始位置（新创建订阅关系时）	可机动指定起始offset	从最新开始消耗	从最新开始消耗	从最新开始消耗
消耗的起始位置（已存在订阅关系时）	可机动指定起始offset	从前次offset开始消耗	从前次offset开始消耗	从前次offset开始消耗
主动 ACK	不支持	不支持	支持	支持
ACK 机制	支持	支持	支持	支持
NACK 机制	不支持	不支持	支持，消息会被重新分配	不支持
消耗超时（凌驾时间未ACK/NACK）	消息不绝处于Pending状态	超时消息会被重新分配，可设置超时时间 invisibleDuration	消息不绝处于Pending状态	消息会等候rebalance后被重新分配

2. 延时队列

几个组件：

	Redis	Rocket MQ	Rabbit MQ	Kafka
延时队列支持	不支持，但可基于 ZSET 实现	支持	支持	不支持
安装依赖	无	无	需安装延时队列插件	-
topic 范例	无	DELAY 消息范例	互换机范例 x-delayed-message	-
实用场景	可靠性要求不高、不渴望引入复杂中央件	高可靠性和性能要求、数据量大	须要可靠的延时队列、消息量适中	-

可靠性：RocketMQ > RabbitMQ > Redis
性能：Redis > RocketMQ > RabbitMQ
延长精度：Redis > RabbitMQ > RocketMQ