2. Redis 基础回顾：核心数据结构与持久化机制
在深入 Redis 消息队列设计之前，必须牢固掌握 Redis 的五大基础数据结构、持久化策略以及单线程事件模型。这些底层能力直接决定了消息队列的吞吐上限、数据安全与回溯查询的实现方式。
2.1 五大基础数据结构
Redis 提供了五种核心数据类型，每种类型在消息队列场景中都有独特的应用价值。下表从底层编码、常用命令与队列适用性三个维度进行对比。
| 数据结构 | 底层编码 | 核心命令 | 消息队列适用场景 |
|---|---|---|---|
| String | int / embstr / raw | SET / GET / INCR / SETNX | 任务计数器、分布式锁、单条消息缓存 |
| List | quicklist（ziplist + linkedlist） | LPUSH / RPOP / BRPOP / LLEN | 经典 FIFO 消息队列、任务分发 |
| Set | intset / hashtable | SADD / SMEMBERS / SISMEMBER / SPOP | 去重队列、任务标签过滤、消费者组管理 |
| Sorted Set | ziplist / skiplist + dict | ZADD / ZRANGEBYSCORE / ZREM / ZSCORE | 延迟队列、优先级队列、任务回溯按时间戳查询 |
| Hash | ziplist / hashtable | HSET / HGET / HGETALL / HDEL | 任务元数据存储、消息体与状态分离 |
关键认知： 消息队列的索引设计本质上是将 Sorted Set（时间戳排序）与 Hash（任务详情）组合使用，形成“索引 + 数据”分离架构。List 适合简单 FIFO，但无法支持按时间范围回溯。
2.2 Redis 持久化：RDB 与 AOF
消息队列必须保证已投递但未确认的消息不丢失。Redis 提供两种持久化机制，它们在数据安全级别与性能开销上存在显著差异。
2.2.1 RDB（快照持久化）
- 原理： 按时间间隔生成全量内存快照（dump.rdb），使用 fork 子进程写时复制。
- 优点： 文件紧凑，恢复速度快，适合冷备与灾难恢复。
- 缺点： 可能丢失两次快照之间的数据；fork 阻塞时间随内存增大而增加。
- 队列场景建议： 作为辅助备份，不可单独依赖。
2.2.2 AOF（追加文件持久化）
- 原理： 将每次写命令追加到 aof_buf，按策略刷盘（always / everysec / no）。
- 优点： 数据安全性高（everysec 最多丢 1 秒数据）；支持 rewrite 压缩。
- 缺点： 文件体积通常大于 RDB；恢复速度较慢。
- 队列场景建议： 必须开启 AOF，且刷盘策略设为
everysec，平衡性能与安全。
| 对比维度 | RDB | AOF |
|---|---|---|
| 数据完整性 | 可能丢失最后一次快照后的全部数据 | 最多丢失 1 秒数据（everysec） |
| 文件大小 | 紧凑，通常较小 | 较大，需定期 rewrite |
| 恢复速度 | 快（直接加载到内存） | 慢（逐条重放命令） |
| 对主进程影响 | fork 时阻塞，写时复制有内存开销 | 刷盘 I/O 影响，rewrite 时 fork |
| 消息队列推荐 | 仅作为辅助备份 | 必须开启，everysec 策略 |
生产警告： 不要在生产消息队列中关闭持久化。即使使用 Redis Sentinel 或 Cluster，持久化仍是防止全节点同时宕机后数据丢失的最后防线。
2.3 Redis 单线程模型
Redis 的核心处理线程是单线程的，但这里的“单线程”仅指 网络 I/O 与命令执行 由同一个线程串行处理。持久化、AOF rewrite、异步删除等操作由后台线程或子进程完成。
2.3.1 单线程模型的核心优势
- 无锁竞争： 所有命令串行执行，天然避免并发修改问题。
- 原子性： 单个命令天然原子；Lua 脚本可保证多条命令的原子执行。
- 可预测延迟： 不存在线程切换与锁等待，尾延迟（tail latency）稳定。
2.3.2 对消息队列的影响
- 吞吐上限： 单线程受限于 CPU 单核性能，但 Redis 的瓶颈通常在网络 I/O 与内存带宽，而非 CPU。
- 大 Key 风险： 单个耗时命令（如
SMEMBERS百万级 Set、HGETALL大 Hash）会阻塞整个队列，导致所有消费者延迟飙升。 - 优化方向： 拆分大 Key、使用
SSCAN/HSCAN分批读取、避免在队列路径上执行 O(N) 命令。
面试高频题： “Redis 单线程为什么还能这么快？” 核心答案：纯内存操作 + 非阻塞 I/O（epoll/kqueue）+ 命令执行路径极短 + 无锁设计。
2.4 核心知识结构图
下图将 Redis 基础体系与消息队列的映射关系可视化，帮助理解后续章节的索引设计思路。
2.5 本章小结
- 数据结构选择： 消息队列核心组合是 Sorted Set + Hash，前者提供按时间戳排序的索引，后者存储任务详情。
- 持久化策略： 生产环境必须开启 AOF（everysec），RDB 作为辅助备份，两者互补。
- 单线程约束： 避免在队列路径上执行 O(N) 命令，防止阻塞所有消费者。