主流消息队列特性对比及选型

1、消息队列定义

  消息队列是一种用于在不同应用程序之间传递消息的通信方式。它通常由一个中间件系统管理，允许应用程序发送、接收和处理消息，而无需直接连接或了解彼此的细节。

2、消息队列作用

2.1 异步

  异步通信指的是消息的发送和接收是非阻塞的，发送方发送消息后不需要等待接收方的响应即可继续执行其他任务。接收方在消息到达时会进行处理。这种通信方式可以提高系统的并发性和响应速度，因为发送方无需等待接收方的响应，可以并行地处理其他任务。

2.2 削峰

  削峰填谷是指利用消息队列平滑处理系统的峰值流量。在高负载时，消息队列可以缓冲请求，防止系统过载，即“削峰”；而在低负载时，系统可以从消息队列中获取消息并处理，保证资源的充分利用，即“填谷”。这种方式可以使系统在高峰和低谷时段之间进行平滑过渡，提高系统的稳定性和性能。

2.3 解耦

  解耦指的是将系统中的各个组件之间的依赖关系降低到最小程度，使得各个组件可以独立地修改、更新或替换。在消息队列中，通过引入消息队列作为中间件，不同组件之间通过消息进行通信，从而实现了解耦。发送方和接收方之间不直接进行通信，而是通过消息队列进行消息的传递，使得各个组件之间的关联性降低，系统更易于维护、扩展和升级。

 

3、消息模型

3.1 P2P模式

   P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

P2P的特点

• 每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
• 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
• 接收者在成功接收消息之后需向队列应答成功

如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。

 

3.2 Pub/Sub模式

   包含三个角色：主题（Topic），发布者（Publisher），订阅者（Subscriber） 。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

Pub/Sub的特点

• 每个消息可以有多个消费者
• 发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
• 为了消费消息，订阅者必须保持运行的状态。
  

​    为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。
​    如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。

 

4、主流消息队列

star截至2024.04.06

	队列名称	特性	适用场景	stars
1	Apache Kafka	1. 高吞吐量和低延迟，适用于大规模数据流处理。 2. 消息持久化和副本机制，保证数据不丢失。 3. 分布式架构和水平扩展性，支持高可用性和容错性。 4. 支持多个消费者组和分区，灵活的消息处理模型。	Kafka 适用于大规模的数据流处理场景，如日志收集与分析、事件驱动架构、实时数据处理等。它具有高吞吐量、持久性、水平扩展等特性，适合处理海量的消息和数据。	27.2k
2	RocketMQ	1. 高可靠性和低延迟，适用于实时消息处理场景。 2. 支持多种消息模式，如事务消息、批量消息等。 3. 高度可扩展，支持大规模分布式部署。 4. 支持多个消费者组和消息过滤，灵活处理消息路由和消费。	RocketMQ 适用于阿里巴巴生态系统内部的各种应用场景，如实时消息处理、事务消息、流式计算等。它具有高可靠性、低延迟、水平扩展等特性，适合处理大规模的分布式消息流。	20.5k
3	NATS	1. 轻量级和低延迟，适合快速消息传递。 2. 简单易用，适合构建微服务架构和云原生应用。 3. 支持发布/订阅模式和请求/响应模式。 4. 不提供持久性保证，适合短期通信和实时事件处理。	NATS 适用于构建快速、轻量级的通信系统，特别适合于微服务架构和云原生应用。它具有低延迟、简单易用的特性，适合于构建需要快速消息传递的分布式系统。	14.6k
4	Apache Pulsar	1. 高可靠性和低延迟，适用于大规模流式数据处理。 2. 多租户支持和多数据中心部署，适应复杂的环境。 3. 提供灵活的消息传递模式和可定制性。 4. 支持事务消息、批量消息等特性，满足不同的业务需求。	Pulsar 适用于大规模的流式数据处理场景，如实时分析、事件驱动架构、消息队列解耦等。它具有水平扩展、高可靠性、多租户支持等特性，适合处理海量的实时数据流。	13.7k
5	RabbitMQ	1. 支持多种消息传递模式，包括点对点、发布-订阅、路由、通配符等。 2. 可靠性消息传递，支持消息持久化和投递确认机制。 3. 高度可定制性，可以通过插件扩展功能。 4. 可靠的集群和节点监控机制，保证系统的可用性和可靠性。	RabbitMQ 适用于各种场景，包括异步任务处理、工作队列、发布/订阅、路由、负载均衡等。它提供了丰富的消息传递模式和高度可定制性，适合需要灵活消息处理的应用场景。	11.5k
6	ZeroMQ	1. 轻量级和高性能，适用于高性能的消息传递场景。 2. 简单易用的 API 和模式，支持多种消息传递模式。 3. 集成了套接字通信模式，支持多语言和多平台。 4. 不提供持久性和可靠性保证，适合短期通信和内部消息传递。	ZeroMQ 适用于构建分布式系统和网络通信应用，特别适合于需要低延迟和高性能的场景。它提供了简单易用的 API 和轻量级的消息传递模式，适合于编写高性能的通信代码。	9.2k
7	Apache ActiveMQ	1. 完全支持 JMS（Java Message Service），适合 Java 应用开发。 2. 提供丰富的特性和可定制性，支持多种消息传递模式。 3. 高可用性和可扩展性，支持集群部署和消息复制。 4. 支持多种传输协议和编程语言，适用于多样化的应用场景。	ActiveMQ 适用于 Java 应用程序和需要 JMS（Java Message Service）支持的场景。它具有丰富的功能和可定制性，适合构建复杂的消息驱动应用和集成系统。	2.2k
8	Amazon SQS	1. 完全托管，无需管理基础设施。 2. 高可靠性和持久性，保证消息不丢失。 3. 简单易用，适合快速启动和部署。 4. 支持标准队列和 FIFO 队列，满足不同的消息传递需求。	Amazon SQS 适用于云原生应用和需要快速部署、简化管理的场景。它提供了高可靠性的消息传递服务，无需管理基础设施，适合需要快速启动的应用和服务。	-
9	Redis	1. 快速，可用于简单的消息通知和发布/订阅模式。 2. 支持持久化和数据备份，保证数据不丢失。 3. 具有其他 Redis 功能的集成，如数据缓存、计数器等。 4. 不适合处理大规模的消息流和复杂的消息处理场景。	Redis 作为消息队列的适用场景通常包括简单的消息通知、任务队列、发布/订阅等	-

 
参考链接：
https://blog.miuyun.work/archives/1712401343121
https://www.jianshu.com/p/689ce4205021
 
如有不对，烦请指出，感谢！