devbox
Monodyee
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

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

作者：Monodyee | 2024-05-24 09:48:51

赞

踩

消息队列选型对比

目录

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

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

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Monodyee/article/detail/616890
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号