redis过期键通过惰性删除和定期删除双机制清理：访问时惰性检查，后台线程每秒默认10次随机抽查20个键，超25%过期则重试，但不保证即时全覆盖。
Redis过期键什么时候真正被删除？
Redis不会在键过期的瞬间立即释放内存，而是采用“惰性删除 + 定期删除”双机制。这意味着你看到 TTL 返回 0 或负数，不等于该键已从内存中消失；它可能还躺在数据库里，只是下次访问时才会被惰性检查并清除。
定期删除由后台线程执行，默认每秒运行 10 次（hz 配置项），每次随机抽查 20 个带过期时间的键。若其中超过 25% 已过期，就再抽一轮——但这个过程不保证全覆盖，尤其在大量键集中过期时，容易堆积“逻辑过期但物理未删”的脏数据。
- 高并发场景下，依赖惰性删除会导致内存持续虚高，甚至触发
maxmemory限制后提前淘汰健康数据 -
redis.conf中的hz值可调（建议 10–100），但过高会增加 CPU 占用，过低则延迟清理 - 用
INFO keyspace查看各 db 的expires数量，比DBSIZE更能反映真实压力
RDB 和 AOF 如何对待过期键？
RDB 快照生成时，只会保存当时未过期的键；AOF 重写（bgrewriteaof）也会过滤掉已过期、尚未被删除的键。所以两者本身不保留过期键，但它们无法解决“正在运行中却长期滞留的过期键”问题——因为这些键还没被惰性或定期删除机制触达。
特别注意：如果关闭了持久化（save "" 且 appendonly no），过期键只靠运行时机制清理，风险更高；而开启 AOF 后，每个 EXPIRE 操作都会追加命令，但过期本身不产生 AOF 记录。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB 文件体积更干净，但恢复时无法还原“刚刚过期但尚未清理”的中间态
- AOF 重写时会执行一次全量键扫描，相当于强制触发一次清理，可作为辅助手段
- 不要依赖持久化文件来判断键是否还存在——运行时状态和磁盘文件永远存在时间差
缓存淘汰策略（maxmemory-policy）会优先踢过期键吗？
不会。Redis 的淘汰策略（如 allkeys-lru、volatile-lfu）在触发时，只考虑当前内存中的键，**完全无视其是否已过期**。也就是说，一个已经过期但尚未被惰性/定期删除机制清理的键，仍会参与淘汰计算，甚至可能挤占真正活跃数据的空间。
唯一与过期相关的策略是 volatile-ttl，它只在设置了过期时间的键中选 TTL 最小的淘汰——但它不区分“已过期”和“快过期”，而且要求键必须有 EXPIRE 或 PEXPIRE 设置，否则直接跳过。
- 用
volatile-*策略的前提是：所有缓存键都显式设置了过期时间，否则可能因无候选键导致写入失败（OOM command not allowed when used memory > 'maxmemory'） -
noeviction下，过期键不清除 + 内存满 = 新写入直接报错，这是最危险的配置组合 - 监控
evicted_keys和expired_keys两个指标，若后者远小于前者，说明过期清理严重滞后
如何让过期清理更及时、更可控？
没有银弹，但可以分层干预：对关键业务键，主动控制生命周期；对批量数据，避免 TTL 集中设置；对运维侧，用配置+监控形成闭环。
- 用
SCAN配合TTL手动清理（例如：每天凌晨扫SCAN 0 MATCH "cache:*" COUNT 1000，对TTL返回 -1 的键执行DEL），适合冷数据归档场景 - 客户端写入时，用
SET key value EX 3600 NX替代分开的SET + EXPIRE，避免中间状态残留 - 升级到 Redis 7.0+ 后，可启用
active-defrag-ignore-bytes和active-defrag-threshold-lower，让内存碎片整理顺便捎带过期键清理 - 警惕
KEYS *类全量扫描命令——它会阻塞定期删除线程，进一步恶化过期堆积
真正难处理的不是单个过期键，而是“大量键在同一秒过期 + 客户端高频访问 + 淘汰策略又没兜住”的三角叠加。这种时候，定期删除线程跑不过来，惰性删除来不及触发，淘汰策略又挑不到合适目标——内存就卡在那里不动了。
