线上经常遇到一种很无解的缓存问题。给Redis的Key设置了过期时间比如10分钟自动失效。时间到了之后我们预想的是缓存清空、自动走数据库刷新数据。但实际线上表现很诡异过期之后一段时间内接口依然能读到旧缓存数据新数据迟迟不刷新。查Redis控制台Key确实没了。但代码就是能读到值真的折磨人。很多人第一反应怀疑过期时间没生效、代码时区问题、缓存没删干净排查一圈啥问题找不到。其实根本原因是很多后端不知道 Redis 的过期删除机制根本不是实时删。Redis不会精准到毫秒把过期key删掉它的删除逻辑分三套惰性删除、定时抽样删除、内存淘汰。绝大多数过期数据根本不是到点就消失。先说最坑的惰性删除。你的key过期后如果一直没人访问Redis根本不会管它。它安安静静躺在内存里占用空间、滞留数据。只有下一次代码主动去查这个key的时候Redis才会校验过期然后当场删掉返回空。这就解释了那个玄学问题过期了还能读到数据。如果过期后瞬间有请求进来刚好卡在删除前旧数据直接被读取出来业务读到过期缓存造成数据延迟更新。其次是定时抽样删除的局限性。Redis后台只会随机抽样一部分过期key清理不会遍历全量key。如果你的过期key特别多、冷热数据混杂大量过期垃圾key会一直残留内存迟迟清不干净。轻微的内存占用变高严重的一直读到脏数据。最隐蔽的坑是内存淘汰策略叠加过期机制。很多生产Redis配置的是volatile-lru只淘汰带过期的key。当内存紧张时优先删快要过期的已经过期的反而可能滞留。导致明明过期很久的缓存依旧常驻内存。本地测试、测试环境内存充足完全复现不了。只有线上流量大、内存满载的时候问题疯狂暴露。还有一个业务层大坑缓存更新只靠过期不主动删。很多团队偷懒数据更新、修改、删除之后不主动清理缓存。完全依赖过期时间自动刷新。过期机制本身就有滞后性再加上Redis删除不实时结果就是线上长期数据不一致用户看到的一直是旧内容。新手总觉得设了expire缓存就绝对可控。实际上expire只是“最晚失效时间”不是“精准删除时间”。做久了中间件运维我总结出一个很实在的经验所有对数据一致性有要求的缓存绝对不能靠过期自动刷新。数据更新必须主动删缓存过期时间只做兜底防止代码异常导致缓存永久滞留。很多线上数据不一致、缓存滞后、刷新不及时的bug根本不是业务代码写错是对Redis底层删除机制认知不足。看似简单的缓存过期其实藏着最多的隐形坑。