Redis 过期键删除和内存淘汰策略

## 〇、前言 对于 Redis 服务器来说，内存资源非常宝贵，如果一些过期键一直不被删除，就会造成资源浪费。 那么，本文将结合博主收集的资料，简单介绍下过期键删除、内存淘汰两个策略，仅供参考。 *博主 Redis 相关文章都在这里了：* ## 一、Redis 的过期时间配置 ### 1.1 设置过期时间的方法 首先是在设置键值对的同时指定过期时间： ```csharp # 语法 SET key value [EX seconds] [PX milliseconds] # 示例 SET mykey "hello" EX 60 # 设置 mykey 的值为 "hello"，并在 60 秒后过期 SET mykey "hello" PX 60000 # 设置 mykey 的值为 "hello"，并在 60000 毫秒（即 60 秒）后过期 ``` 然后是给已存在的键添加过期时间，共四种命令： ```csharp # 【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 时间戳的形式存储）。 ```csharp # 示例 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 时间）。 简要的步骤： 1. 遍历所有数据库：依次检查每个数据库（DB）。 2. 随机采样：从每个数据库的 expires 字典中随机选取 20 个键。 3. 删除过期键：将过期的键从主字典和 expires 字典中删除。 4. 重复扫描：如果发现 25% 以上的采样键已过期，则重复扫描，直到过期键比例低于阈值或达到 CPU 时间限制。 5. 退出条件：若达到预设的 CPU 时间限制（如每秒 25ms），则停止扫描。 - **优势：** 内存友好：主动清理过期键，减少内存浪费。 可控性：通过调整 hz 和扫描参数，平衡性能与内存占用。 - **劣势：** 延迟性：过期键可能在扫描间隔内仍存在，无法立即删除。 资源占用：频繁扫描可能增加 CPU 负载（但通过时间限制避免了极端情况）。 - **如何配置？** hz：配置 serverCron 的执行频率（默认 10，即每秒 10 次）。 ACTIVE\_EXPIRE\_CYCLE\_SLOW\_TIME\_PERC：该参数决定了 Redis 在**单次过期键清理周期**中，最多可以占用的 CPU 时间比例（默认 25%）。 ```csharp # 计算公式： 最大允许 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 配置和查看 ```csharp # 配置格式 maxmemory # 设置最大内存限制（如：maxmemory 1gb） maxmemory-policy # 设置淘汰策略（如：maxmemory-policy allkeys-lru） # 动态配置（需重启后生效） CONFIG SET maxmemory 1gb CONFIG SET maxmemory-policy allkeys-lru ``` ```csharp # 查看当前配置项 CONFIG GET maxmemory CONFIG GET maxmemory-policy ``` Redis 的内存淘汰策略提供了灵活的选择，需根据业务需求权衡数据保留策略、性能开销和公平性。合理配置 maxmemory 和 maxmemory-policy 是优化 Redis 性能和可靠性的关键。