消息队列基础知识和主流消息队列对比

徐州蔡徐坤

于 2025-02-13 16:12:28 发布

阅读量1k

点赞数 30

分类专栏：消息队列文章标签：消息队列 mq rabbitmq kafka 队列

本文链接：https://blog.csdn.net/qq_29864051/article/details/145614673

版权

消息队列专栏收录该内容

1 篇文章

订阅专栏

消息队列基础知识

一、消息队列概述

消息队列（Message Queue，MQ）本质上是一个数据存储队列，用于临时保存和传输消息。

消息中间件是一种基于高效、可靠的消息传递机制，实现跨平台数据通信的工具。它在分布式系统中发挥重要作用，主要用于异步处理、解耦应用、削峰限流、消息通讯，从而提升系统的性能、可用性、扩展性，并确保数据的最终一致性。

目前，常见的消息队列技术包括 ActiveMQ、RabbitMQ、Kafka、RocketMQ 等，每种方案在不同场景下具有独特优势。

二、消息队列应用场景

通常来说，使用消息队列主要能为我们的系统带来下面三点好处：

异步处理
削峰/限流
降低系统耦合性

除了这三点之外，消息队列还有其他的一些应用场景，例如实现分布式事务、顺序保证和数据流处理。

异步处理

在处理用户请求时，涉及到的耗时操作可以通过消息队列实现异步化。请求数据被发送到消息队列后，系统立即返回响应，从而减少用户等待时间，提升交互体验。而后续的业务逻辑则由消息消费者进行处理。

然而，由于数据写入消息队列后便立即返回，后续的校验、数据库写入等环节仍可能失败。因此，在使用消息队列进行异步处理时，需要合理调整业务流程。例如，在用户提交订单后，订单信息会先进入消息队列，此时不应直接告知用户“订单提交成功”。只有当订单消费者完成处理，甚至完成库存扣减后，再通过短信或邮件通知用户订单确认成功，以避免交易纠纷。这与日常购买电影票或火车票的流程类似。

削峰限流

在高并发场景下，比如电商秒杀、促销活动，用户请求会在短时间内激增，可能会直接压垮后端服务。削峰限流的核心思想是利用消息队列作为缓冲区，让请求先进入队列，然后由后端服务按照自身处理能力逐步消费，从而避免系统被突发流量冲击导致崩溃。

削峰限流的工作流程：

用户请求激增：活动开始后，短时间内大量订单请求涌入。
消息队列缓冲：所有请求先写入消息队列，而不是直接打到数据库或核心业务服务。
后端逐步消费：后端系统按照自身的处理能力，有节奏地从队列中取出请求进行处理。
避免系统崩溃：即使瞬时流量过大，消息仍然被队列吸收，后端不会被超载。

示例：电商秒杀场景

传统做法：数百万用户同时提交订单，数据库直接写入，导致数据库崩溃。
使用消息队列后：所有订单请求先进入队列，后端按照自身能力逐步处理，比如每秒处理 1000 个订单，剩余的订单依然在队列中等待，不会导致系统崩溃。

降低系统耦合性

在传统架构中，如果系统 A 需要调用系统 B 的功能，通常是直接调用，这意味着：

系统 A 必须知道系统 B 的地址、接口协议。
如果系统 B 改变了接口或不可用，系统 A 可能会崩溃。

而引入消息队列后，系统 A 和系统 B 之间不再直接通信，而是通过消息队列进行数据传输：

系统 A（生产者） 只需把消息发送到消息队列。
系统 B（消费者） 只需从消息队列中消费消息。
两者不需要相互感知对方的存在，这样就降低了耦合度。

通过引入消息队列，系统之间的直接依赖减少了，修改或新增模块时，只需要调整消息的消费逻辑，不会影响原有系统，大大提高了可扩展性和维护性。

发布/订阅（Pub/Sub）模型

消息队列使用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。 从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。

示例：

例如，我们商城系统分为用户、订单、财务、仓储、消息通知、物流、风控等多个服务。用户在完成下单后，需要调用财务（扣款）、仓储（库存管理）、物流（发货）、消息通知（通知用户发货）、风控（风险评估）等服务。使用消息队列后，下单操作和后续的扣款、发货、通知等操作就解耦了，下单完成发送一个消息到消息队列，需要用到的地方去订阅这个消息进行消费即可。

三、如何选择合适的消息队列

如何选择合适的消息队列中间件？

目前主流的消息队列包括 ActiveMQ、RabbitMQ、Kafka、RocketMQ，每种都有其特点和适用场景。在选择合适的消息队列时，可以从以下几个关键因素进行衡量：

1. 开源性

选择开源的消息队列至关重要。如果在实际应用过程中遇到影响业务的 Bug，可以直接修改源码进行修复或规避，而不必被动等待官方发布新版本。此外，开源产品通常有更广泛的社区支持和更快的更新迭代。

2. 社区活跃度

一个活跃的社区意味着更高的稳定性和更好的生态支持。流行的开源项目通常会有更多的用户反馈和 Bug 修复，使用过程中遇到问题也更容易找到解决方案。此外，社区活跃的产品往往能与其他系统更好地集成。

3. 关键技术指标

一个合格的消息队列必须具备以下核心特性：

消息可靠性：支持消息持久化，确保数据不会丢失，即使系统故障也能恢复。
高可用性：支持集群部署，避免单点故障导致系统不可用，同时确保消息不丢失。
性能表现：具备高吞吐、低延迟的能力，能够满足业务需求，避免成为系统瓶颈。

在实际应用中，需要根据业务场景权衡这些因素，选择最合适的消息队列方案。例如，Kafka 适用于高吞吐的日志和流式数据处理，RabbitMQ 更适合事务消息和分布式系统解耦，而 RocketMQ 在大规模高并发场景下表现优秀。

消息队列对比表格

主流消息队列对比（RabbitMQ、ActiveMQ、RocketMQ、Kafka）

特性	RabbitMQ	ActiveMQ	RocketMQ	Kafka
单机吞吐量	万级，适用于低并发场景	万级，适用于低并发场景	十万级，单机可达十万级，性能较高	十万级以上，适用于高吞吐场景
Topic 数量对吞吐量的影响	Topic 数量过多会影响吞吐量，但影响相对较小	Topic 数量过多影响吞吐量，影响较大	支持上千个 Topic，吞吐量仅小幅下降，适用于大规模主题应用	Topic 数量较多时吞吐量大幅下降，需增加机器资源
消息写入性能	RAM 速度为 RocketMQ 的 1/2，Disk 速度约为 RAM 的 1/3	依赖磁盘存储，写入性能一般	优秀，单机单 Broker 可达 7 万条/s（10 字节消息）	极高，百万条/s（10 字节消息）
可用性	高，主从架构，Master 提供服务，Slave 仅做备份，数据量大时可能产生性能瓶颈	高，基于 ZooKeeper + LevelDB 的主从架构	高，支持多 Master、多 Slave，支持同步/异步复制	非常高，分布式架构，支持 Replica 机制，Leader 宕机后自动选举
消息延迟	微秒级，适用于低延迟场景	毫秒级	毫秒级	毫秒级以内，适用于实时数据处理
消息可靠性	高，有 Slave 备份，保证数据不丢失	可能会有少量数据丢失	可通过参数优化配置实现 0 丢失	优化后可做到 0 丢失
持久化能力	内存 + 文件，支持数据堆积，但影响生产速率	内存 + 文件 + 数据库，性能较低	磁盘文件，只要磁盘足够大，就能无限堆积	磁盘文件，高效持久化
是否有序	单个 Client 保证有序	支持有序消息	支持全局或分区有序消息	支持分区有序，多 Client 需自行保证
消息批量操作	不支持	支持	支持	支持
集群支持	支持，但集群架构较复杂	支持	支持，高可扩展	支持，天然分布式架构
事务支持	不支持	支持	支持，支持分布式事务	不支持事务，但可通过低级 API 方式保证“仅消费一次”