Redis过期策略优化定时任务效率，如何解决高并发下的缓存失效问题

2023年4月，一家电商平台在大促期间，因为大量商品信息缓存同时过期，导致瞬间数据库访问激增，网站响应变慢。同年8月，某社交应用通过改进缓存过期机制，将热点数据的加载时间平均缩短了40%。这些消息都指向一个核心问题：在高并发场景下，如何聪明地管理缓存的生死，避免系统被压垮。

别让缓存同时“死掉”

想象一下，你管理着一个大型仓库，里面堆满了各种货物的标签。这些标签都有有效期，一到点就自动作废。如果设置不当，让一堆重要货物的标签都在同一秒失效，那么所有搬运工都会瞬间冲向后台仓库去查新标签，通道肯定堵死。Redis的缓存过期就像这个标签系统。它的默认策略是“惰性删除”加“定期抽样”。惰性删除是指，只有当有人来查询某个键时，Redis才检查它是否过期，过期就当场删除并返回空。这就像搬运工去拿货时才发现标签过期了，只好临时去查。定期抽样则是Redis每隔一段时间（比如每秒10次），随机检查一定数量的键，删除其中过期的。这就像管理员偶尔巡逻抽查，清掉一些过期标签。但问题在于，如果大量高频访问的缓存键设置了相同的过期时间（比如都是整点失效），那么到了那个时间点，大量用户请求同时涌来，每个请求都会触发“惰性删除”，发现缓存没了，于是全部转向数据库查询，这就是可怕的“缓存雪崩”。

给过期时间加点“随机数”

解决上面问题的一个直接办法就是别让大家一起死。在给缓存设置过期时间时，不要都用固定的“过期10分钟”，而是采用“基础时间加一个随机波动值”的策略。比如，可以设置为“600秒到900秒之间”的随机值。这样，即使这些缓存是在同一时刻创建的，它们也会在接下来的五分钟内分散失效，而不是同时失效。压力就被平摊到一段时间里，数据库不会瞬间被击垮。这就像把员工的休息时间错开，避免所有人同时离开岗位导致工作停顿。对于依赖定时任务刷新缓存的情况，这个策略尤其有用。定时任务可以仍然在固定时间点（比如整点）触发，去更新或预热最关键的一部分数据。而其他非核心的、由用户请求触发生成的缓存，则通过随机过期时间来分散失效压力。两者结合，既保证了核心数据的及时更新，又避免了全局性的失效风暴。

请个“哨兵”提前预热缓存

光分散失效时间还不够，因为热点数据一旦失效，哪怕只有一个键，也可能在极高并发下引来海量请求穿透到数据库。这时候就需要一个“哨兵”机制，或者叫“互斥锁”模式。具体做法是：当某个缓存失效，第一个发现它失效的请求（这个请求会没拿到数据）并不是直接去查数据库，而是先去获取一个特殊的锁。只有拿到这个锁的请求，才有资格去数据库查询数据并重新把结果塞回缓存。其他并发的请求看到这个锁存在，就乖乖地等待一小会儿，或者先去兜底方案（比如返回一个旧的但可用的数据，如果业务允许的话），等新的缓存被设置好后再来读取。这就避免了成百上千个请求同时去挤数据库独木桥。在Redis里，可以用SETNX命令（设置如果不存在）来实现这个锁。记得给锁本身也设一个短的过期时间，比如几秒钟，防止获取锁的请求意外崩溃导致锁永远不解开。

设置两级缓存，一层挂了还有一层

对于一些极端重要的数据，可以考虑采用多级缓存架构来增加保险。比如，在应用服务器本地内存（如Caffeine）中设置一级缓存，在Redis中设置二级缓存。一级缓存可以设置更短的过期时间，比如30秒，而Redis里的二级缓存设置较长的过期时间，比如10分钟。当请求进来，先查本地内存，没有再去查Redis，Redis没有再查数据库。这样，即使Redis中某个热点缓存集中失效，由于各个应用服务器上的本地缓存过期时间点不同（服务器启动时间不同），也能抵挡住第一波冲击，只有少量请求会穿透到Redis和数据库。这就像在仓库门口设了几个临时货架，即使主仓库的标签系统暂时混乱，门口货架上的存货也能应付一阵子。当然，这带来了数据一致性的新挑战，需要根据业务容忍度来平衡。

引用来源：综合自Redis官方文档关于过期键删除策略（惰性删除、定期删除）的说明，以及高可用架构社区的技术文章，如《缓存穿透、击穿、雪崩解决方案》和《分布式缓存设计模式》等。其中过期时间随机化、互斥锁重建、多级缓存等实践方案在多个互联网公司的技术博客（如美团、阿里云开发者社区）中均有讨论和验证。