📚 课程目录第3章 Redis核心机制

3. Redis 核心机制：数据结构、过期策略与持久化

在 Dev 环境中构建缓存一致性闭环，首先需要深入理解 Redis 的内部机制。本章聚焦于 Redis 的核心数据结构、过期策略以及持久化方式（RDB / AOF），并给出在 Dev 环境中的推荐配置。这些机制直接决定了缓存的读写性能、数据一致性与故障恢复能力。

3.1 核心数据结构与 Dev 环境选型

Redis 提供了多种数据结构，不同结构适用于不同的缓存场景。在 Dev 环境中，我们应优先选择语义清晰、内存效率高的结构。

数据结构	底层编码	典型场景	Dev 环境推荐
String	int / embstr / raw	计数器、Session、简单 KV	✅ 首选，性能最高
Hash	ziplist / hashtable	对象属性缓存（如用户信息）	✅ 适合结构化数据
List	quicklist	消息队列、时间线	⚠️ 注意阻塞风险
Set	intset / hashtable	标签、去重、交集/并集	✅ 适合集合运算
Sorted Set	ziplist / skiplist	排行榜、延时队列	✅ 适合带权重的有序数据

Dev 环境选型原则：优先使用 String 和 Hash。String 用于简单 KV 和计数器，Hash 用于缓存具有多个字段的对象（如用户、订单），避免序列化整个对象的开销。

3.2 过期策略：被动 + 定期删除

Redis 的过期策略是缓存一致性闭环的关键。它采用惰性删除（被动）与定期删除（主动）相结合的方式，在内存效率与 CPU 开销之间取得平衡。

惰性删除：当客户端访问一个 key 时，Redis 检查其是否过期，若过期则立即删除并返回 nil。这种策略对 CPU 友好，但可能导致过期 key 长时间占用内存。
定期删除：Redis 每隔 100ms 随机抽取一部分设置了过期时间的 key，检查并删除已过期的 key。默认每秒执行 10 次，每次耗时不超过 25ms。

Dev 环境注意：如果大量 key 在同一时间过期，Redis 的定期删除可能产生短暂的 CPU 尖刺。建议在业务层面为不同缓存设置随机过期时间（例如基础 TTL + 随机偏移），避免缓存雪崩。

3.3 持久化方式：RDB vs AOF

持久化决定了 Redis 重启后数据能否恢复。在 Dev 环境中，我们需要根据数据一致性要求选择合适的持久化策略。

特性	RDB（快照）	AOF（追加文件）
数据格式	二进制压缩文件	文本协议（RESP）
恢复速度	快（直接加载到内存）	慢（逐条重放命令）
数据丢失风险	较高（两次快照间的数据丢失）	较低（可配置 fsync 策略）
文件体积	小（压缩存储）	大（需定期 rewrite）
对性能影响	fork 子进程时可能阻塞	写入频繁时影响吞吐

  Dev 环境推荐：开启 AOF + 每秒 fsync，同时保留 RDB 作为快速恢复的兜底方案。这样既能保证最多丢失 1 秒的数据，又能利用 RDB 加快重启速度。

3.4 Dev 环境配置示例

以下是一个适用于 Dev 环境的 Redis 配置文件（redis.conf）关键片段，兼顾了数据安全与开发调试的便利性。

# 绑定本机地址，仅允许本地访问
bind 127.0.0.1

# 保护模式开启
protected-mode yes

# 端口
port 6379

# 持久化：同时开启 RDB 和 AOF
save 900 1
save 300 10
save 60 10000

appendonly yes
appendfsync everysec

# AOF 重写触发条件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 内存淘汰策略：用于缓存场景
maxmemory 512mb
maxmemory-policy allkeys-lru

# 慢查询日志（Dev 调试用）
slowlog-log-slower-than 10000
slowlog-max-len 128

配置说明：
maxmemory-policy allkeys-lru：当内存达到上限时，使用 LRU 算法淘汰所有 key，适合缓存场景。
slowlog-log-slower-than 10000：记录执行时间超过 10ms 的命令，便于在 Dev 环境排查性能瓶颈。

3.5 数据结构与持久化协同流程

下图展示了 Redis 在 Dev 环境中的核心工作流程：客户端写入数据，Redis 根据数据结构编码存储，同时触发过期检查与持久化策略。

3.6 持久化配置对比与 Dev 环境建议

下表总结了不同持久化组合在 Dev 环境中的适用场景与权衡。

持久化组合	数据安全性	恢复速度	磁盘 I/O	Dev 环境推荐度
仅 RDB	低（可能丢失最近一次快照后的数据）	快	低（定期 fork）	⚠️ 仅用于纯缓存，可接受重启丢失
仅 AOF（always fsync）	极高（最多丢失 1 个写命令）	慢	高（每次写入都 fsync）	❌ 不推荐，性能开销大
RDB + AOF（everysec）	高（最多丢失 1 秒数据）	中（RDB 加速加载，AOF 补全）	中（每秒 fsync）	✅ 强烈推荐
关闭持久化	无（重启即丢失）	最快	无	⚠️ 仅用于临时测试，不用于开发调试

  Dev 环境最佳实践：

开启 RDB + AOF（everysec），兼顾数据安全与性能。

设置 maxmemory 和 maxmemory-policy，防止内存溢出。

为不同业务缓存设置随机过期时间，避免缓存雪崩。

开启 slowlog，便于在 Dev 环境排查慢查询。