消息队列基础知识和主流消息队列对比
消息队列基础知识和主流消息队列对比
消息队列（Message Queue，MQ）是一种在分布式系统中用于临时保存和传输消息的机制，它在提升系统性能、可用性和扩展性方面发挥着重要作用。本文将为您详细介绍消息队列的基础知识、应用场景，并对比主流的消息队列产品，帮助您更好地理解和选择合适的消息队列方案。
一、消息队列概述
消息队列（Message Queue，MQ）本质上是一个数据存储队列，用于临时保存和传输消息。消息中间件是一种基于高效、可靠的消息传递机制，实现跨平台数据通信的工具。它在分布式系统中发挥重要作用，主要用于异步处理、解耦应用、削峰限流、消息通讯，从而提升系统的性能、可用性、扩展性，并确保数据的最终一致性。
目前，常见的消息队列技术包括ActiveMQ、RabbitMQ、Kafka、RocketMQ等，每种方案在不同场景下具有独特优势。
二、消息队列应用场景
通常来说，使用消息队列主要能为我们的系统带来下面三点好处：
- 异步处理
- 削峰/限流
- 降低系统耦合性
除了这三点之外，消息队列还有其他的一些应用场景，例如实现分布式事务、顺序保证和数据流处理。
异步处理
在处理用户请求时，涉及到的耗时操作可以通过消息队列实现异步化。请求数据被发送到消息队列后，系统立即返回响应，从而减少用户等待时间，提升交互体验。而后续的业务逻辑则由消息消费者进行处理。
然而，由于数据写入消息队列后便立即返回，后续的校验、数据库写入等环节仍可能失败。因此，在使用消息队列进行异步处理时，需要合理调整业务流程。例如，在用户提交订单后，订单信息会先进入消息队列，此时不应直接告知用户“订单提交成功”。只有当订单消费者完成处理，甚至完成库存扣减后，再通过短信或邮件通知用户订单确认成功，以避免交易纠纷。这与日常购买电影票或火车票的流程类似。
削峰限流
在高并发场景下，比如电商秒杀、促销活动，用户请求会在短时间内激增，可能会直接压垮后端服务。削峰限流的核心思想是利用消息队列作为缓冲区，让请求先进入队列，然后由后端服务按照自身处理能力逐步消费，从而避免系统被突发流量冲击导致崩溃。
削峰限流的工作流程：
- 用户请求激增：活动开始后，短时间内大量订单请求涌入。
- 消息队列缓冲：所有请求先写入消息队列，而不是直接打到数据库或核心业务服务。
- 后端逐步消费：后端系统按照自身的处理能力，有节奏地从队列中取出请求进行处理。
- 避免系统崩溃：即使瞬时流量过大，消息仍然被队列吸收，后端不会被超载。
示例：电商秒杀场景
- 传统做法：数百万用户同时提交订单，数据库直接写入，导致数据库崩溃。
- 使用消息队列后：所有订单请求先进入队列，后端按照自身能力逐步处理，比如每秒处理 1000 个订单，剩余的订单依然在队列中等待，不会导致系统崩溃。
降低系统耦合性
在传统架构中，如果系统 A 需要调用系统 B 的功能，通常是直接调用，这意味着：
- 系统 A 必须知道系统 B 的地址、接口协议。
- 如果系统 B 改变了接口或不可用，系统 A 可能会崩溃。
而引入消息队列后，系统 A 和系统 B 之间不再直接通信，而是通过消息队列进行数据传输：
- 系统 A（生产者）只需把消息发送到消息队列。
- 系统 B（消费者）只需从消息队列中消费消息。
- 两者不需要相互感知对方的存在，这样就降低了耦合度。
通过引入消息队列，系统之间的直接依赖减少了，修改或新增模块时，只需要调整消息的消费逻辑，不会影响原有系统，大大提高了可扩展性和维护性。
消息队列使用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。从上图可以看到消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。
示例：
例如，我们商城系统分为用户、订单、财务、仓储、消息通知、物流、风控等多个服务。用户在完成下单后，需要调用财务（扣款）、仓储（库存管理）、物流（发货）、消息通知（通知用户发货）、风控（风险评估）等服务。使用消息队列后，下单操作和后续的扣款、发货、通知等操作就解耦了，下单完成发送一个消息到消息队列，需要用到的地方去订阅这个消息进行消费即可。
三、如何选择合适的消息队列
如何选择合适的消息队列中间件？
目前主流的消息队列包括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 方式保证“仅消费一次” |
参考链接
[1].秒懂消息队列MQ，万字总结带你全面了解消息队列MQ-阿里云开发者社区
[2].消息队列MQ快速入门（概念、RPC、MQ实质思路、队列介绍、队列对比、应用场景）_zmq rpc-CSDN博客
[3].消息队列基础知识总结 | JavaGuide
[4].10分钟搞懂！消息队列选型全方位对比-腾讯云开发者社区-腾讯云