Redis 过期键删除和内存淘汰策略【Redis 系列之四】

〇、前言

对于 Redis 服务器来说，内存资源非常宝贵，如果一些过期键一直不被删除，就会造成资源浪费。

那么，本文将结合博主收集的资料，简单介绍下过期键删除、内存淘汰两个策略，仅供参考。

博主 Redis 相关文章都在这里了：https://www.cnblogs.com/hnzhengfy/category/2229717.html

一、Redis 的过期时间配置

1.1 设置过期时间的方法

首先是在设置键值对的同时指定过期时间：

# 语法

SET key value [EX seconds] [PX milliseconds]

# 示例

SET mykey "hello" EX 60      # 设置 mykey 的值为 "hello"，并在 60 秒后过期

SET mykey "hello" PX 60000   # 设置 mykey 的值为 "hello"，并在 60000 毫秒（即 60 秒）后过期

然后是给已存在的键添加过期时间，共四种命令：

# 【expire 命令】设置以【秒】为单位的过期时间

# 语法：

EXPIRE key seconds

# 示例：

SET mykey "hello"

EXPIRE mykey 60   # 设置 mykey 在 60 秒后过期

# 【pexpire 命令】设置以【毫秒】为单位的过期时间

# 语法：

PEXPIRE key milliseconds

# 示例：

SET mykey "hello"

PEXPIRE mykey 60000   # 设置 mykey 在 60000 毫秒（即 60 秒）后过期

# 【expireat 命令】设置一个具体的 Unix 时间戳作为过期时间（以【秒】为单位）

# 语法：

EXPIREAT key timestamp

# 示例：

SET mykey "hello"

EXPIREAT mykey 1743283200 # 设置 mykey 在 Unix 时间戳 1743283200 时过期

# 【pexpireat 命令】设置一个具体的 Unix 时间戳作为过期时间（以【毫秒】为单位）

# 语法：

PEXPIREAT key timestamp_ms

# 示例：

SET mykey "hello"

PEXPIREAT mykey 1743283200000 # 设置 mykey 在 Unix 时间戳 1743283200000 时过期

1.2 如何判断一个键是否已经过期？

首先看下一个带过期时间的键如何保存？

Redis 在内存中存储键值对时，会为每个键维护一个独立的数据结构来记录其元信息（如过期时间）。

键值对存储在全局哈希表（dict）中。每个键对应一个 redisObject，该对象包含了键的值以及与该键相关的元信息（例如类型、编码方式等）。

过期时间存储在一个专门的字典（expires 字典）中，键是普通键名，值是该键的过期时间（以 Unix 时间戳的形式存储）。

# 示例

SET mykey "hello" EX 60

# mykey 被存储在主字典中，指向值 "hello"。

# 同时，mykey 也会被添加到 expires 字典中，值为当前时间 + 60 秒的时间戳。

如果一个键没有设置过期时间，则它不会出现在 expires 字典中。

读取键时会先进行过期检查

当访问一个键时（如 GET 命令），Redis 会先检查该键是否存在于 expires 字典中。如果存在，Redis 会将当前时间与 expires 字典中存储的过期时间进行比较：

如果，当前时间 >= 过期时间：认为该键已过期，返回 nil。

如果，当前时间 < 过期时间：认为该键仍然有效。

二、过期键删除策略

2.1 惰性删除（Lazy Deletion）（被动删除）

惰性删除是 Redis 核心工作机制的一部分，因此默认启用，并且无法通过配置项来手动关闭。

针对惰性删除有三个要点：

被动触发：当客户端访问一个键时（如 GET、DEL 等命令），Redis 会首先检查该键是否已设置过期时间。

过期检查：如果键已过期（当前时间 ≥ 过期时间），Redis 会立即删除该键，并返回 nil（表示键不存在）。

不主动清理：未被访问的过期键不会被删除，直到下次被访问时才会触发检查。

优势

高效性：仅在键被访问时检查过期，避免了不必要的 CPU 资源消耗。

低延迟：不会因过期键的清理操作导致系统性能波动。

劣势

内存浪费：长时间未被访问的过期键会持续占用内存，可能导致内存泄漏。

不可控性：无法主动清理未被访问的过期键。

2.2 定期删除（Periodic Deletion）（主动删除）

定期删除就是以固定的时间间隔，来扫描 Redis 数据库中的键，发现过期的键立即删掉，可以通过配置来设置具体频率。

要点：

主动触发：Redis 内部通过一个后台任务（serverCron）周期性地扫描过期键，并主动删除它们。

随机采样：每次扫描时，Redis 会从数据库的 expires 字典中随机选取一批键（默认 20 个），检查是否过期，并删除已过期的键。

动态调整：通过参数 hz（默认值 10）控制扫描频率，即每秒执行 hz 次扫描任务。扫描时长受 CPU 时间限制（默认不超过 25% 的 CPU 时间）。

简要的步骤：

遍历所有数据库：依次检查每个数据库（DB）。
随机采样：从每个数据库的 expires 字典中随机选取 20 个键。
删除过期键：将过期的键从主字典和 expires 字典中删除。
重复扫描：如果发现 25% 以上的采样键已过期，则重复扫描，直到过期键比例低于阈值或达到 CPU 时间限制。
退出条件：若达到预设的 CPU 时间限制（如每秒 25ms），则停止扫描。

优势：

内存友好：主动清理过期键，减少内存浪费。

可控性：通过调整 hz 和扫描参数，平衡性能与内存占用。

劣势：

延迟性：过期键可能在扫描间隔内仍存在，无法立即删除。

资源占用：频繁扫描可能增加 CPU 负载（但通过时间限制避免了极端情况）。

如何配置？

hz：配置 serverCron 的执行频率（默认 10，即每秒 10 次）。

ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC：该参数决定了 Redis 在单次过期键清理周期中，最多可以占用的 CPU 时间比例（默认 25%）。

# 计算公式：

最大允许 CPU 时间（微秒） = (1000000 * ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC) / (server.hz * 100)

# 例如：当 hz=10

最大允许时间 = (1000000 * 25) / (10 * 100) = 25,000 微秒（即 25 毫秒） # 单次清理，只运行 25 毫秒

# 例如：当 hz=1

最大允许时间 = (1000000 * 25) / (1 * 100) = 250,000 微秒（即 250 毫秒） # 单次清理，只运行 250 毫秒

若某次清理发现大量过期键（如 20 个采样键中有 6 个过期），Redis 会继续扫描直到过期键比例下降或时间耗尽。

2.3 综合策略：惰性删除+定期删除

Redis 的过期键删除策略结合了惰性删除（Lazy Deletion）和定期删除（Periodic Deletion），通过两者的互补性实现性能与内存占用的平衡。

两者结合带来的好处：

高效性：惰性删除仅在键被访问时触发，避免了不必要的 CPU 开销。定期删除通过随机采样和动态调整，平衡了 CPU 负载与内存清理效率。

内存友好：惰性删除确保被访问的过期键立即释放内存。定期删除主动清理未被访问的过期键，减少内存泄漏风险。

典型应用场景：

针对高频访问场景，惰性删除更有优势，能够快速清理过期键，减少内存占用。当然，不可避免的有部分键是没有被访问的，这时就需要定期删除来及时清理。

针对内存敏感场景，定期删除可以避免过期键长期占用空间，但要仔细考量配置项的值，避免 CPU 过载。惰性删除则尽快清除失效键。

针对低资源环境，更加需要两者的有机配合。惰性删除减少 CPU 开销，定期删除通过参数控制资源消耗。也可能需牺牲部分内存利用率以换取 CPU 节省。

三、内存淘汰策略

3.1 触发条件

Redis 的内存淘汰策略（Memory Eviction Policy）是在 Redis 达到最大内存限制（由 maxmemory 参数配置）时，用于决定如何淘汰（删除）现有数据以腾出空间的机制。

两个条件全部满足才触发：

达到最大内存限制：当 Redis 使用的内存超过 maxmemory 配置的阈值时。
需要分配新内存：当尝试写入新数据或更新现有数据时，如果内存不足，触发淘汰策略。

3.2 八种内存淘汰策略

八种策略实际上可以分为三类。

1）不淘汰任何数据（默认策略）

maxmemory-policy noeviction

当内存不足时，拒绝所有写操作（如SET、ADD等），并返回错误（OOM command not allowed when used memory > 'maxmemory'）。

适用于对数据完整性要求高的场景，避免因内存不足导致数据丢失。

2）在所有键（allkeys）中选择淘汰

这类策略会从所有键（无论是否设置了过期时间）中选择淘汰对象。

maxmemory-policy allkeys-lru

淘汰最近最少使用的（Least Recently Used）键。根据键的最近访问时间（上次读或写的时间），选择最久未使用的键淘汰。

适合访问模式不固定、需要保留近期活跃数据的场景。

maxmemory-policy allkeys-lfu

淘汰最近最少使用的（Least Frequently Used）键。根据键的访问频率（读写次数），选择使用频率最低的键淘汰。

适合频繁访问少数热点数据的场景（如热门商品缓存）。

maxmemory-policy allkeys-random

随机选择一个键淘汰。

适用于对数据淘汰的公平性要求不高，追求简单快速的淘汰方式。

3）仅在设置了过期时间的键（volatile）中选择淘汰

这类策略仅从设置了过期时间的键中选择淘汰对象。

maxmemory-policy volatile-lru

在设置了过期时间的键中，淘汰最近最少使用的（Least Recently Used）键。

适用于需要淘汰过期可能性高的键，同时保留近期活跃数据。

maxmemory-policy volatile-lfu

在设置了过期时间的键中，淘汰最近最少使用的（Least Frequently Used）键。

适合访问频率低但即将过期的键。

maxmemory-policy volatile-random

在设置了过期时间的键中随机选择一个淘汰。

适用于对过期键的淘汰公平性要求不高的场景。

maxmemory-policy volatile-ttl

优先淘汰剩余生存时间（TTL：Time To Live）最短的键。如果多个键的 TTL 相近，则可能随机选择。

适用于希望尽快清理即将过期的键，避免内存浪费的场景。

注意：volatile-ttl 策略可能因时间因素导致某些键被提前淘汰，即使它们仍被频繁访问。

业务场景	推荐使用的策略
数据完整性要求高	使用 noeviction，避免写入失败
访问模式不固定	使用 allkeys-lru 或 volatile-lru
存在热点数据	使用 allkeys-lfu 或 volatile-lfu
希望优先清理即将过期的数据	使用 volatile-ttl
简单快速淘汰	使用 allkeys-random 或 volatile-random

注意：Redis 的 LRU 和 LFU 并非精确实现，而是通过采样和统计来近似计算，以减少性能开销。例如，maxmemory-policy allkeys-lru 会定期采样部分键来估算最近最少使用情况。

另外，Redis 的内存淘汰策略与键的过期机制（惰性删除+定期删除）是独立的。即使设置了过期时间，未被访问的键仍可能因内存不足被提前淘汰。

3.3 配置和查看

# 配置格式

maxmemory <bytes>          # 设置最大内存限制（如：maxmemory 1gb）

maxmemory-policy <policy>  # 设置淘汰策略（如：maxmemory-policy allkeys-lru）

# 动态配置（需重启后生效）

CONFIG SET maxmemory 1gb

CONFIG SET maxmemory-policy allkeys-lru

# 查看当前配置项

CONFIG GET maxmemory

CONFIG GET maxmemory-policy

Redis 的内存淘汰策略提供了灵活的选择，需根据业务需求权衡数据保留策略、性能开销和公平性。合理配置 maxmemory 和 maxmemory-policy 是优化 Redis 性能和可靠性的关键。