过期表是什么
每个设置了生存时间的键，都会在过期字典里留一条记录：键的指针与到期时间戳。主字典负责取值，过期字典只负责记录「什么时候该删」。因此 TTL 不是零成本的元数据，键数量大时过期字典自身的内存占用与扫描成本都会显现出来。
基本信息
| 结构 | 过期字典（expires dict），与主字典相互独立 |
|---|---|
| 每条记录 | 键指针加到期时间戳 |
| 清理方式 | 惰性删除（访问时判断）加定期抽样扫描 |
| 观测方式 | INFO keyspace 的 keys 与 expires 两列对照 |
| 影响面 | 内存开销与扫描 CPU 开销，键越多越明显 |
两条清理路径
| 路径 | 触发时机 | 特点 |
|---|---|---|
| 惰性删除 | 访问该键时判断是否过期 | 精确但有延迟，冷键可能长期占内存 |
| 定期抽样扫描 | 后台周期任务按过期键比例调整强度 | 集中到期时 CPU 峰值明显 |
| 主动清理强度 | 由 hz 与 active-expire-effort 这类参数影响 | 提高强度加快回收但增加 CPU 负担 |
| 观测口径 | expired_keys 为累计回收计数 | 单点值说明规模，趋势要看差分 |
查看与核对
查看与核对
redis-cli INFO keyspace # 每个库的 keys 与 expires 数量
redis-cli DBSIZE
redis-cli INFO stats | grep expired_keys # 累计过期回收计数
redis-cli TTL some:key # 确认单个键的剩余生存时间
redis-cli --scan --pattern 'sess:*' | head -20 # 抽查键命名与 TTL 规范是否一致典型使用场景
- 会话类数据：按会话维度设 TTL，评估会话总量对内存的影响
- 容量估算：用 expires 占比修正内存预算，避免只算数据本身
- 抖动排查：大量键集中到期时观察回收压力与延迟尖刺
- 清理规范核对：抽查键命名与 TTL 是否成对，防止漏设或漏删
- 淘汰策略配套：选择 volatile 系列策略时，确认确实有足量带 TTL 的键
过期扫描是抽样式的，TTL 在时间上越分散，键越容易被及时回收；同一时刻集中到期的海量键会造成回收压力，给 TTL 加随机抖动是常用做法。
过期键的回收会占用主线程，删除大对象时可能看到延迟尖刺；可在评估后使用异步释放相关选项（如 lazyfree-lazy-expire），改动前先在测试环境验证。