Redis Key过期删除策略深度解析与实战总结

Redis 的 Key 过期删除策略，堪称其内存管理机制中最引人入胜、也最受面试官青睐的模块。它并非依赖单一规则清理过期数据，而是采用一套组合拳：被动删除与主动删除双管齐下。这套设计究竟如何运作？让我们一步步深入拆解。

1. 被动删除（惰性删除 - Lazy Expiration）

工作原理
通俗来说就是：你不找我，我就不删。当客户端发起请求、访问某个 Key 时，Redis 会先检查该 Key 是否已过期。若已过期，立即删除并返回 nil——仿佛它从未存在过。若未过期，则正常返回数据。

优点
对 CPU 极其友好。只有在被访问的时刻才消耗资源，其他时间完全闲置。简单直接，不会干扰那些无人问津的 Key。

缺点
对内存不太友好。如果某些过期 Key 永远无人访问，它们就会一直滞留在内存中。极端情况下，可能导致内存浪费甚至“泄露”。

2. 主动删除（定期删除 - Periodic Expiration）

工作原理
既然仅靠被动删除不可靠，Redis 还会主动出击。它以固定频率（默认每秒 10 次）执行以下步骤：

1. 随机抽检：从设置了过期时间的 Key 集合中，随机挑选 20 个。
2. 过期清理：将这 20 个中已过期的 Key 删除。
3. 动态循环：若本次抽检中超过 25% 的 Key 已过期，说明过期 Key 积压严重，需要重复步骤 1 和 2。
4. 时间阀值：为防止影响主线程，每次扫描最多持续 25ms。时间一到，无论是否清理完毕，立即停止。

相关配置参数（在 redis.conf 中）：

# 每秒执行过期扫描的次数（默认 10）
hz 10

# 每次扫描的 CPU 时间百分比上限（默认 25%）
# 实际上每次扫描最多 25ms（1000ms / hz * 25%）

优点
能有效减少内存中过期 Key 的堆积，在 CPU 消耗与内存占用之间找到不错的平衡点。

缺点
并非实时清理，可能存在某个 Key 已过期几分钟却未被扫描到的情况。而且，定期执行本身也会增加一定的 CPU 开销。

3. 内存淘汰策略（Eviction Policies）

如果说前两种策略是“日常保洁”，那么当内存真正吃紧时——即达到 maxmemory 限制——Redis 会启动最后防线：根据你配置的淘汰策略强行腾出空间。

# 内存限制（默认不限制）
maxmemory 

# 淘汰策略
maxmemory-policy 

可选的淘汰策略有以下几种：

4. 实际工作流程示例

5. 性能优化建议

监控过期 Key 数量
想知道系统中有多少 Key 已被清理？可以这样查询：

redis-cli info stats | grep expired_keys

合理配置 hz 值
hz 值决定了主动扫描的频率。

hz 100   # 更高频率，清理更及时，但 CPU 消耗也更高
hz 1     # 更低频率，CPU 友好，但可能导致过期 Key 堆积

避免大量 Key 同时过期
这是一个非常经典的优化点。如果大批 Key 在同一秒过期，会导致 Redis 在那一瞬间 CPU 飙升。通常的做法是加入随机偏移量：

# 不好的做法：同时设置相同过期时间
for i in range(100000):
    redis.set(f"key:{i}", "data", ex=3600)

# 好的做法：添加随机偏移
for i in range(100000):
    redis.set(f"key:{i}", "data", ex=3600 + random.randint(0, 300))

6. 特殊情况处理

AOF/RDB 持久化
- RDB：生成快照时，过期的 Key 不会被保存到文件中。
- AOF：当 Key 过期时，Redis 会追加一条 DEL 命令到 AOF 文件里。

主从复制
- 主节点删除过期 Key 后，会主动向从节点发送一条 DEL 命令。
- 从节点没有自主删除过期 Key 的权限，完全听从主节点的指令。

集群模式
- 每个节点独立管理自己的过期 Key。
- 当槽位发生迁移时，Key 的过期信息也会一并迁移到目标节点。

总结

Redis 的过期删除策略，本质上是一套 惰性删除 + 定期删除 的组合拳：

• 惰性删除：保证每次访问的“正确性”，确保不会返回已过期的数据。
• 定期删除：作为补充，主动清理那些无人访问的过期 Key，减少内存浪费。
• 内存淘汰：在极端情况下，作为防止内存耗尽的最后一道防线。

这套机制在 CPU 使用率、内存效率和实现复杂性之间，取得了相当不错的平衡。也正是因此，Redis 才能在高并发场景下流畅地处理海量带有过期时间的 Key。