Redis过期问题怎么处理才不崩溃，聊聊那些异常情况和应对办法

关于Redis过期问题怎么处理才不崩溃，以及相关的异常情况和应对办法，结合Redis官方文档和社区常见实践,可以这样来聊：

Redis的过期键删除机制本身是主动和被动结合的，被动删除是当客户端尝试访问一个键时，Redis会检查它是否过期，如果过期就删除并返回空，主动删除则是Redis定期随机测试一些设置了过期时间的键，过期就删除，但问题就出在这里，如果过期键太多，而Redis主动删除的采样频率（默认配置下）可能跟不上，再加上如果长时间没有客户端访问那些过期键，它们就会大量堆积在内存里，直到内存用满，这就是一个典型的异常情况：内存明明有很多键过期了，但使用率却下不来，最终可能触发内存上限策略，导致写入失败或者更糟的崩溃。（来源：Redis官方文档关于过期时间的描述）

应对这个问题的直接办法是调整Redis的主动删除策略，Redis配置里有hz参数，它控制后台任务（包括过期键扫描）的执行频率，适当调高hz（比如从默认的10调到100）可以让扫描更频繁，更快地清理过期键，但注意，调太高会增加CPU负担，需要在CPU和内存之间找个平衡，另一个关键配置是maxmemory-policy，当内存达到上限时，Redis的行为，如果业务允许，可以设置为allkeys-lru或volatile-lru，在内存紧张时淘汰一些键，为新的写入腾出空间，避免直接崩溃。（来源：Redis配置文档关于hz和maxmemory-policy的说明）

一个非常危险的异常是 “缓存雪崩” ，这指的是大量缓存在同一时刻集体过期，导致所有请求瞬间都涌向数据库，数据库压力激增甚至被打垮，进而整个系统崩溃，应对这个问题的核心思路是让过期时间分散开，不要在设置缓存时使用固定的过期时间，比如都设成1小时，而是在基础值上加上一个随机扰动值，比如1小时加上一个几分钟的随机数，这样就能让键的过期时间点错开，避免同时失效。（来源：广泛认可的缓存雪崩解决方案，常见于技术社区如Stack Overflow、阿里云开发者社区等）

另一个常见问题是 “缓存击穿” ，这指的是某个非常热点的键过期了，此时有海量请求同时来访问这个不存在的键，所有请求都冲向数据库，就像在数据库上凿了个洞，应对办法通常是用互斥锁，当发现缓存失效时，不是所有线程都去查数据库，而是让一个线程去查数据库并重建缓存，其他线程等待，在Redis里，可以用SETNX命令实现一个简单的分布式锁，拿到锁的线程去加载数据，没拿到的等待或返回默认值，这样可以避免数据库被重复查询压垮。（来源：高并发缓存解决方案的常见模式,在技术博客和架构文章中广泛讨论）

还有 “缓存穿透” ，这指的是查询一个根本不存在的数据，缓存里没有，数据库也没有，恶意攻击者可能利用这点，用大量不存在的数据请求，导致请求每次都落到数据库上，应对办法主要有两种：一是缓存空值，即使数据库查不到，也把一个空值或特殊标记（如NULL）存到缓存，并设置一个较短的过期时间，这样后续请求在缓存层就返回了，二是使用布隆过滤器这种数据结构，在查询缓存前先经过布隆过滤器判断数据是否存在，如果布隆过滤器说“很可能不存在”，那就可以直接返回，不用查缓存和数据库了。（来源：布隆过滤器在缓存穿透中的应用是经典方案，见于《Redis实战》等书籍及技术文章）

还有一个容易被忽略的异常情况：主从复制下的过期问题，在Redis主从架构中，过期键的删除主要由主节点控制，主节点删除一个过期键后，会向从节点发送一个DEL命令，但问题在于，从节点自己不会主动删除过期键，它只等待主节点的命令，如果由于网络问题，主节点的DEL命令没有及时传到从节点，那么从节点上就可能存在逻辑上已过期但物理上还在的数据，客户端从从节点读到脏数据，应对这个问题的办法是，对于一致性要求高的数据，尽量从主节点读取，保持Redis版本较新，因为新版本（如4.0以上）对过期处理有改进，从节点也会在读到过期键时尝试逻辑删除。（来源：Redis官方文档关于主从复制中过期键处理的说明）

处理Redis过期问题不崩溃，关键是要理解它的删除机制不是实时的，然后针对性地预防，主要就是四件事：一是调整配置让清理更及时，防止内存淤积；二是用随机过期时间避免雪崩；三是用锁或空值应对击穿和穿透；四是在主从环境下注意脏数据风险，把这些点做到位,Redis因为过期问题崩掉的概率就会小很多。