1. 消息队列概述：核心概念、应用场景与 Redis 选型理由
1.1 消息队列的核心概念
消息队列（Message Queue，MQ）是一种基于生产者-消费者模型的异步通信机制。生产者将消息发送到队列，消费者从队列中拉取或由队列推送消息进行处理。消息队列在分布式系统中扮演着“缓冲带”和“通信总线”的角色。
| 核心概念 | 定义 | 典型角色 |
|---|---|---|
| 生产者（Producer） | 负责创建并发送消息的应用程序或服务 | 订单服务、日志采集器 |
| 消费者（Consumer） | 从队列中获取并处理消息的应用程序或服务 | 邮件发送服务、数据分析任务 |
| 消息（Message） | 在系统间传递的数据单元，通常包含业务载荷和元数据 | JSON 字符串、序列化对象 |
| 队列（Queue） | 先进先出（FIFO）的数据结构，用于暂存消息 | Redis List、Kafka Topic 分区 |
| 主题（Topic） | 消息的逻辑分类，支持发布/订阅模式 | 订单事件、用户行为流 |
| 确认机制（ACK） | 消费者处理完成后向队列发送确认，防止消息丢失 | Redis BRPOPLPUSH、Kafka Offset |
关键理解：消息队列的本质是“空间换时间”——用队列存储的临时空间，换取系统间处理速度的解耦与弹性。
1.2 核心应用场景
场景一：异步解耦
在微服务架构中，服务间直接调用会形成强依赖链。引入消息队列后，上游服务只需将消息写入队列，下游服务独立消费，双方无需同时在线。
- 典型例子：用户注册后，订单服务发送“注册成功”消息，邮件服务和积分服务各自异步处理。
- 收益：注册接口响应时间从 800ms 降至 50ms，邮件服务故障不影响注册主流程。
场景二：削峰填谷
面对突发流量（如秒杀、大促），消息队列作为缓冲区，将瞬时请求暂存，下游消费者按自身处理能力匀速拉取，避免数据库被击穿。
- 典型例子：秒杀系统将 10 万请求写入队列，库存服务以每秒 1000 笔的速度处理，平滑度过流量尖峰。
- 收益：系统峰值压力降低 90%，数据库连接数保持稳定。
场景三：日志与事件收集
分布式系统的日志、监控指标、业务事件通过消息队列集中采集，实现统一存储与分析。
实践建议：在日志场景中，Redis 的 List 结构配合 XADD 命令，能以微秒级延迟完成日志写入，非常适合高频低价值数据的暂存。
1.3 为什么选择 Redis 作为消息队列？
业界消息队列产品众多（RabbitMQ、Kafka、RocketMQ），Redis 在特定场景下具有不可替代的优势。下表从关键维度进行对比：
| 对比维度 | Redis | RabbitMQ | Kafka |
|---|---|---|---|
| 部署复杂度 | 极低，单节点即可运行 | 中等，需 Erlang 环境 | 较高，依赖 Zookeeper |
| 消息延迟 | 微秒级（纯内存操作） | 毫秒级 | 毫秒级（批量时更低） |
| 吞吐量 | 单节点 10 万+/秒 | 单节点 5-10 万/秒 | 百万级/秒（分区并行） |
| 持久化能力 | RDB/AOF，可配置 | 强，消息确认机制完善 | 强，日志文件持久化 |
| 消息可靠性 | 中等，需额外设计 ACK | 高，支持事务与确认 | 高，副本机制保证 |
| 功能丰富度 | 基础队列、Pub/Sub、Stream | 丰富路由、死信队列 | 分区、偏移量管理 |
| 运维成本 | 低，Redis 集群成熟 | 中等 | 高，需专业运维 |
选型边界：Redis 不适合需要严格消息顺序、事务性投递、海量消息长期堆积（超过内存容量）的场景。在这些场景下，请优先考虑 Kafka 或 RabbitMQ。
1.4 Redis 消息队列的三种实现模式
Redis 提供了多种数据结构来支持消息队列，每种模式适用于不同的业务需求：
- List 模式（LPUSH + BRPOP）： 最基础的 FIFO 队列，适合简单任务分发。
- Pub/Sub 模式： 发布/订阅，适合广播通知，但消息不持久化。
- Stream 模式（Redis 5.0+）： 支持消费者组、消息持久化、ACK 机制，是 Redis 消息队列的“专业方案”。
本课程将重点围绕 Redis Stream 展开，因为它弥补了前两种模式的不足，同时保留了 Redis 的高性能优势。