热度元数据会一起落盘
开启内存淘汰后，RDB 会顺带保存每个键的空闲时间（LRU 口径）或访问频率（LFU 口径）元数据，加载后据此近似恢复热度状态，让重启之后的淘汰判断不至于完全失忆。但精度有限：它记录的是快照那一刻的状态，而且 LRU 时钟精度并不高，停机时间越长热度信息越陈旧。
基本信息
| 依赖条件 | 需配置 maxmemory 与淘汰策略才会实际使用 |
|---|---|
| 保存内容 | LRU 空闲时间、LFU 频率计数器 |
| 恢复方式 | 加载时读取并初始化键的计数器 |
| 查看命令 | OBJECT IDLETIME 与 OBJECT FREQ |
| 主要局限 | 精度有限，停机越久数据越陈旧 |
典型使用场景
- 重启后热点键的保留表现与预期不符，需要判断是否与热度元数据老化有关
- 评估重启对缓存命中率的短期影响，为容量预留做准备
- 排查重启后集中淘汰：确认是数据增长还是热度判断失准
- LFU 策略下核对某个键的访问频率是否符合业务预期
- 设计重启与扩容流程时，把热度重建期纳入容量与性能评估
查看热度信息
查看热度信息
redis-cli CONFIG GET maxmemory-policy # 确认是否启用了淘汰策略
redis-cli OBJECT IDLETIME mykey # 该键未被访问的秒数
redis-cli OBJECT FREQ mykey # 仅 LFU 策略下可用
redis-cli INFO keyspace # 结合键数量观察重启后的变化策略与可用命令
| 淘汰策略 | 保存的元数据 | 可用命令 |
|---|---|---|
| allkeys-lru 等 LRU 系 | 键的空闲时间 | OBJECT IDLETIME |
| allkeys-lfu 等 LFU 系 | 访问频率计数器 | OBJECT FREQ |
| volatile 系 | 同上，仅对有 TTL 的键生效 | 按策略选用对应命令 |
| noeviction | 不依赖热度元数据 | 命令仍可执行，但与淘汰无关 |
OBJECT IDLETIME 记录的是「未被访问的秒数」而不是最后访问时间戳，把它当时间戳解读会得出错误结论。
重启加载后热度信息被恢复成快照时的状态，重启过程中停止的访问时长不会被计入，因此命中率通常需要一段时间才回到稳态。