Redis 数据删除策略

发布时间:2026/7/2 4:56:15
Redis 数据删除策略 Redis 的删除策略分三大块过期键删除策略、内存淘汰策略内存满了删谁、主动手动删除平时做缓存开发这两块是高频踩坑点我分开说清楚。一、过期键删除策略给 key 设置过期时间后怎么删掉失效数据我们业务里大量缓存都会加expire设置过期Redis 有三种删除方式配合使用。1. 惰性删除被动删除核心机制逻辑key 过期后不会立刻删下次访问这个 key 的时候Redis 先判断是否过期过期直接删除再返回空。优点几乎不消耗 CPU只有读写时才做判断平时无额外开销。缺点如果一个过期 key 长期没人访问会一直占内存造成内存泄漏。比如冷门商品缓存过期后没人查一直堆积。2. 定期删除主动抽样清理弥补惰性删除缺陷Redis 每隔一段时间默认 100ms执行一次清理任务随机抽取一定数量带过期的 key删掉其中已经过期的如果本轮过期 key 占比超过阈值继续多抽一轮防止过期 key 堆积。优点均衡 CPU 和内存避免大量过期 key 占内存。缺点只是抽样不是遍历全库依然会残留部分过期 key没法彻底清干净。3. 结合使用Redis 默认是惰性删除 定期删除搭配。 但即便这样高并发、海量 key 场景下还是会有大量过期数据残留内存持续上涨这时候就需要内存淘汰策略兜底。二、内存淘汰策略maxmemory 达到上限时系统自动删数据业务机器内存有限配置maxmemory限制 Redis 最大使用内存内存打满后执行淘汰策略共 6 种分两大类第一类不淘汰任何数据线上缓存基本不用noeviction默认策略内存满后所有新增、修改 key 的写命令直接报错读命令正常执行。 适合 Redis 只存少量固定配置、不做大量缓存写入的场景缓存业务绝对不能用流量上来直接大量报错。第二类淘汰带过期时间的 key优先删过期缓存推荐业务使用volatile-lru只在设置了过期时间的 key 里淘汰最近最少使用LRU的数据。volatile-lfu只在过期 key 里淘汰访问频次最低LFU的数据新版本更推荐。volatile-random过期 key 里随机删基本不用命中率不可控。volatile-ttl过期 key 里优先删剩余存活时间最短的适合有统一过期时效的临时缓存。第三类淘汰全部 key包含没设过期的持久化数据allkeys-lru / allkeys-lfu / allkeys-random不区分是否设置过期整个库内按规则删除。 如果 Redis 既存持久化业务数据又存缓存不建议开会把重要永久数据删掉。线上缓存选型总结面试加分绝大多数互联网缓存allkeys-lfuRedis4.0按访问频次淘汰热点数据永远留在内存冷缓存优先清理缓存命中率最高区分业务一部分永久数据、一部分过期缓存volatile-lfu只动过期缓存保护永久配置 key简单临时缓存统一过期时间volatile-ttl。补充Redis LRU/LFU 不是完整算法为了性能Redis 不是维护完整链表统计所有 key而是随机抽样少量 key 对比近似实现性能损耗极低。三、主动手动删除策略业务代码主动清理除了自动删除我们开发时会手动操作清理数据分几种场景DEL key同步删除单个 / 多个 key阻塞主线程大数据量 hash/list 慎用UNLINK key异步删除线上推荐 把释放内存操作丢到后台子线程主线程不阻塞删除大集合无卡顿批量清理flushdb清空当前库所有 keyflushall清空所有数据库 支持flushdb async异步清空避免阻塞集合精细化删除hdel、lpop、zrem 等只删除集合内部分元素不删除整个 key业务主动更新更新数据库时同步删除对应缓存避免缓存脏数据Cache-Aside 常用方案。四、业务踩坑总结只靠过期删除不配置 maxmemory 淘汰过期冷 key 堆积内存溢出 OOM使用 noeviction流量高峰新增缓存直接报错接口大量 500大量使用 DEL 删除大 list/hash主线程阻塞Redis 卡顿改用 UNLINK永久业务 key 和缓存混存使用 allkeys 淘汰核心配置被误删业务故障LRU 适合短期热点LFU 适合长期稳定热点现在新项目优先 LFU。简短收尾总结Redis 删除分为三层过期 key 靠「惰性删除 定期删除」自动清理过期数据内存打满触发 6 种内存淘汰策略线上缓存优先 allkeys-lfu业务侧通过 DEL/UNLINK、批量清空命令主动手动删除 生产环境必须配置 maxmemory 合理淘汰策略防止内存溢出同时大对象删除优先异步 unlink 避免阻塞。