Forrest’s 博客📌Redis-内存过期和内存淘汰策略
type
status
date
slug
summary
category
tags
icon
password
AI summary
Blocked by
Blocking
Category
Redis是一个内存数据库，内存往往是有限的。同时缓存与真实数据也存在数据不一致问题，所以Redis中的数据往往会设置TTL（time-to-live）。
重点：管理的是 被设置了 TTL 的 key 的生命周期
Redis 提供三种机制，用来处理已经过期的 key：
- 定期删除（periodic deletion）
- Redis 默认每100ms 执行一次“定期扫描”
- 随机抽取部分有设置TTL的key
- 对过期key删除
- 如果发现过期key占比较高，循环步骤c，但整体保证cpu低于25%，确保不会阻塞主线程
- 惰性删除（lazy deletion）
- 不会主动清理，只有key被client访问时执行，以节省CPU
- 内存淘汰策略（eviction）在达到 maxmemory 时强制删除
策略 | 触发时机 | 优点 | 缺点 |
定期删除 | 定时任务扫描 | 不积压过期 key | 可能有延迟删除 |
惰性删除 | 查询 key 时 | CPU 成本最低 | 未被访问的 key 会一直占内存 |
内存淘汰 | 内存不足触发 | 防止 OOM | 属于紧急措施 |
内存淘汰策略
按照key的类别来看
- allkeys-* 表示所有key
- volatile-* 表示有设置TTL的
从筛选的策略角度看
- lru
- lfu
- random
- ttl
策略名 | 删除范围 | 逻辑 | 特点 |
volatile-lru | 仅 TTL key | LRU 删除 | 比较温和 |
allkeys-lru | 所有 key | LRU 删除 | 缓存场景最常用 |
volatile-lfu | 仅 TTL key | 删除访问次数最低 | 适合频率敏感业务 |
allkeys-lfu | 所有 key | 删除访问次数最低 | Redis 4.0 起最推荐 |
volatile-random | 仅 TTL key | 随机删 | 简单粗暴 |
allkeys-random | 所有 key | 随机删 | 适合极端性能要求 |
volatile-ttl | 仅 TTL key | 删除 TTL 最短（最先过期） | 适合同 TTL 场景 |
noeviction | 不删除 | 直接报错 | 防止数据丢失 |
生产的最佳实践
从缓存的核心来看问题
- 热数据需要保存在内存中
- 冷数据需要被淘汰
- 对于高并发缓存场景：allkeys-lru比较合适。LRU反映 “最近没被访问”，贴合业务。
- 会话、登录态场景：volatile-lru比较合适。session数据都设置了TTL，只希望淘汰“会过期”的数据
- 高频访问系统（计数器、热点 API）：allkeys-lfu（趋势策略）。LFU能识别“访问频率非常高”的数据，优于LRU。
- 避免使用random，除非极端性能追求
- 为了防止redis OOM，一定要配置好maxMemory
Prev
【计算机网络】应用层
Next
Redis-大key问题
Loading...