【每日八股】Redis篇（四）：持久化（下）

Redis 过期机制？

Redis 的过期机制通过惰性删除 + 定期删除组合策略实现，同时结合持久化、主从复制等机制处理数据一致性。

过期键删除策略

定时删除

• 触发条件：在设置 key 的过期时间时，创建一个定时事件，当时间到达时，由事件处理器执行 key 的删除操作。
• 优点：内存可以被尽快释放，因此定时删除对内存最友好。
• 缺点：定时删除对 CPU 不友好，删除过期 key 会占用相当一部分 CPU 时间，CPU 紧张时如果将 CPU 用于删除和当前无关的过期键，会对服务器的响应时间和吞吐量产生影响。

惰性删除

• 触发条件：访问键时触发检查。
• 行为：如果键过期，直接删除并返回空值。
• 优点：CPU 友好，仅实际访问时消耗资源。
• 缺点：可能导致内存泄露（过期但长期不被访问的键无法释放）。

定期删除

• 触发条件：Redis 定期扫描过期字典。
• 行为：随机选取N个过期的键。删除其中已过期的键，若过期键比例超过25%，则重复该过程。
• 优点：平衡内存和 CPU 资源。

Redis 采用惰性删除 + 定期删除两种策略配合使用：平衡 CPU 的合理使用并避免内存浪费。具体来说，Redis 在访问或修改 key 之前，会调用 expireIfNeeded 函数检查 key 是否过期：

• 如果 key 过期，删除 key，返回 null 给客户端；
• 如果没有过期，不做任何处理，返回正常的 value。

此外，Redis 在定期删除时，从过期字典中随机抽取N（比如 20 ）个key，检查这些 key 是否过期，并删除其中已经过期的 key。如果已经过期的 key 在这 N 个 key 中的数量大于 25%，则重复上述步骤直到比重小于 25%。

持久化与过期键

RDB 持久化

• 生成 RDB：过期键不会被保存到 RDB 文件中。
• 加载 RDB：主服务器会忽略过期键，从服务器保留过期键（依赖主从同步删除）。

AOF 持久化

• 写入 AOF：键过期后执行 DEL 命令时，AOF 文件追加DEL记录。
• AOF 重写：重写时检查键是否过期，过期键不写入新的 AOF。

主从复制与过期键

从服务器不主动删除过期键：而是依赖主服务器同步DEL命令。

主服务器删除逻辑：主服务器删除过期键后，向从服务器发送DEL命令。从服务器读到过期键，返回空值（但不会主动删除）。

Redis 的内存淘汰策略？

不淘汰策略（默认策略）

当运行内存超过最大内存设置时，不进行数据淘汰，此时拒绝写入操作，但是可以进行查询和删除操作。

淘汰有过期时间的数据

在设置了过期时间的数据当中进行淘汰：

• volatile-random：随机淘汰设置了过期时间的任意键值；
• volatile-ttl：优先淘汰更早过期的键值；
• volatile-lru：淘汰所有设置了过期时间的键值中，最久未使用的键值；
• volatile-lfu：淘汰所有设置了过期时间的键值中，最少使用的键值；

淘汰所有数据

• allkeys-random：随机淘汰任意键值；
• allkeys-lru：淘汰整个键值中最久未使用的键值；
• allkeys-lfu：淘汰整个键值中最少使用的键值；

Redis 持久化时对过期键会如何处理？

RDB

生成 RDB 文件时：

• 已过期的键不会写入 RDB 文件；
• 仍在有效期内的键会保留过期时间信息；

加载 RDB 文件时：

• 主节点：加载时会检查键的过期时间，自动过滤已过期的键；
• 从节点：会完整加载所有的键（包含已过期的），依赖主节点同步 DEL 命令来删除。

AOF

AOF 写入时：

• 当键过期被删除时，会追加一条 DEL 命令到 AOF 文件；
• 通过redis.conf的appendfsync配置控制同步策略；

AOF 重写时：

• 重写过程会检查键的过期时间，已过期的键不会写入新的 AOF；

主从模式特殊处理

• 从节点不会主动删除过期键，依赖主节点的 DEL 命令同步；
• 读取从节点时可能返回逻辑上已经过期的数据。

关键注意事项：

1. 内存中已过期但未被删除的键会被持久化保留；
2. 持久化文件中的过期时间使用绝对时间戳存储；
3. 混合持久化模式同时遵循上述 RDB 和 AOF 的处理规则。

Redis 主从模式中，对过期键会如何处理？

从库不会进行过期扫描，即使从库中的 key 过期了，如果有客户端访问从库时，依然可以得到 key 对应的值。从库的过期键处理依靠主服务器控制，主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。