📚 课程目录第3章 Redis核心概念回顾

3. Redis 核心概念回顾：数据结构、过期策略、持久化（RDB/AOF）、哨兵与集群模式

在进入 PostgreSQL 与缓存异步任务编排的联合调试之前，必须对 Redis 的核心机制建立清晰、准确的认识。本章将系统回顾 Redis 的五大支柱：数据结构、过期策略、持久化（RDB/AOF）、哨兵模式与集群模式。这些概念是后续理解缓存一致性、数据可靠性及高可用编排的基础。

3.1 核心数据结构与适用场景

Redis 提供了丰富的数据结构，每种结构都针对特定场景进行了优化。下表总结了最常用的五种结构及其典型用途：

数据结构	底层编码	典型命令	适用场景
String	int / embstr / raw	SET / GET / INCR / DECR	计数器、分布式锁、Session 共享、缓存单值
Hash	ziplist / hashtable	HSET / HGET / HGETALL / HINCRBY	对象存储（用户信息、商品详情）、结构化缓存
List	quicklist	LPUSH / RPUSH / LPOP / BRPOP	消息队列、时间线、最新消息列表
Set	intset / hashtable	SADD / SREM / SMEMBERS / SINTER	标签系统、去重、共同好友、抽奖
Sorted Set	ziplist / skiplist	ZADD / ZRANGE / ZREVRANGE / ZSCORE	排行榜、延迟队列、优先级调度、限流滑动窗口

实践提示：在异步任务编排中，Sorted Set 常用于实现延迟队列（以时间戳作为 score），List 配合 BRPOP 实现可靠的任务分发。选择合适的数据结构能显著降低代码复杂度。

3.2 过期策略与内存淘汰

Redis 的过期机制是缓存有效性的核心。它采用被动过期与主动过期相结合的混合策略：

被动过期（惰性删除）：当客户端访问一个 key 时，Redis 检查其是否已过期，若过期则立即删除并返回 nil。这种策略对 CPU 友好，但可能导致已过期的 key 仍占用内存。
主动过期（定期删除）：Redis 每隔 100ms 随机抽取一部分设置了过期时间的 key，检查并删除已过期的 key。通过 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 参数控制每次检查的数量，平衡 CPU 与内存开销。

当内存使用达到 maxmemory 限制时，Redis 会根据配置的淘汰策略进行内存回收。以下是常见的淘汰策略对比：

策略名称	淘汰范围	行为描述	推荐场景
noeviction	全部	不淘汰，写入操作直接返回错误	数据库级缓存，不允许丢失数据
allkeys-lru	全部 key	淘汰最近最少使用的 key	通用缓存，访问模式符合 LRU
volatile-lru	设置了 TTL 的 key	在过期 key 中淘汰最近最少使用的	混合存储，部分 key 需要持久
allkeys-random	全部 key	随机淘汰任意 key	访问模式均匀，无热点
volatile-ttl	设置了 TTL 的 key	淘汰剩余 TTL 最短的 key	优先保留即将过期的 key（较少使用）

注意：在异步任务编排中，如果使用 Redis 存储任务状态，建议将任务 key 的过期时间设置为任务超时时间的 2-3 倍，避免任务尚未完成就被主动过期删除。同时，maxmemory-policy 应设置为 noeviction 或 volatile-lru，防止关键任务数据被意外淘汰。

3.3 持久化机制：RDB 与 AOF

Redis 提供两种持久化方式，用于在服务器重启后恢复数据。理解它们的差异对设计高可用缓存系统至关重要。

3.3.1 RDB（Redis Database）

原理：在指定时间间隔内生成内存数据的快照（dump.rdb）。
触发方式：手动（SAVE / BGSAVE）、自动（save 配置）、主从复制全量同步。
优点：文件紧凑，适合备份与灾难恢复；恢复速度比 AOF 快。
缺点：可能丢失最后一次快照之后的数据；BGSAVE 在 fork 子进程时可能阻塞主进程。

3.3.2 AOF（Append Only File）

原理：以日志形式记录每次写操作命令，追加到 AOF 文件末尾。
刷盘策略：
- appendfsync always：每次写入都 fsync，最安全但最慢。
- appendfsync everysec：每秒 fsync 一次，兼顾性能与安全（推荐）。
- appendfsync no：由操作系统决定刷盘时机，性能最好但可能丢失大量数据。
优点：数据安全性高（最多丢失 1 秒数据）；AOF 文件可读，便于误操作恢复。
缺点：文件体积通常比 RDB 大；恢复速度较慢。

  生产建议：同时开启 RDB 和 AOF（aof-use-rdb-preamble yes）。AOF 用于保证数据不丢失，RDB 用于快速重启和备份。在异步任务编排场景中，建议 AOF 刷盘策略设置为 everysec，在性能与可靠性之间取得平衡。

3.4 高可用架构：哨兵模式与集群模式

在缓存异步任务编排中，Redis 的高可用性直接决定了任务调度的可靠性。下面通过两张 SVG 图分别展示哨兵模式与集群模式的核心架构。

3.4.1 哨兵模式（Sentinel）

哨兵模式提供主从切换与故障检测能力，适用于中小规模部署。它由一组 Sentinel 进程组成，监控主节点和从节点的健康状态。

3.4.2 集群模式（Cluster）

集群模式提供数据分片与自动故障转移，适用于大规模分布式缓存场景。数据被自动分布到 16384 个哈希槽（slot）中，每个节点负责一部分 slot。

3.5 三种部署模式对比

下表从多个维度对比单机、哨兵与集群三种部署模式，帮助你在异步任务编排场景中做出合理选择：

维度	单机模式	哨兵模式	集群模式
数据容量	单节点内存上限	单节点内存上限	可水平扩展至 PB 级
高可用	无	自动故障转移	自动故障转移 + 数据分片
数据分片	不支持	不支持	自动分片（16384 个 slot）
读写分离	不支持	支持（配置从节点只读）	支持（从节点只读）
客户端复杂度	低	中（需支持 Sentinel）	高（需支持 Cluster 协议）
推荐场景	开发测试、小规模缓存	中小规模生产环境	大规模、高并发、海量数据