「这是我参与2022首次更文挑战的第38天，活动详情查看：2022首次更文挑战」

惰性清除

• 关于惰性删除我们在平时开发中也经常使用这种方式！当数据过期时redis并不急着去清除这些数据，而是等到该key被再次请求时进行删除！这样在最终效果上是没有问题的。
• 优点和定期清除一样他保证了CPU不必频繁的进行切换！但是缺点也很明显会导致很多已经过期的key任然在redis中。

惰性清除+定期清除

• 我们开头说过了既要高可用又要实时清理过期key 这是无法做到的！既然无法做到我们就需要在CPU和内存中间做一个权衡！redis内部是使用惰性清除和定期清除两种方式结合使用，最终保重CPU和内存之间的一种平衡！

总结

• 相信大家对上面三个概念有点模糊了。【键过期】、【淘汰策略】、【过期清除】
• 首先【键过期】是redis给我们开发者提供的功能。我们可以根据自己的业务需求合理的设置键的过期时间，从而保证内存的高可用
• 其次【过期清除】在我们之前设置的过期的key如何进行合理的清除，并不能一股脑一下子进行清除因为数据过大会导致服务的卡顿。这个时候我们需要通过定期清除减缓清除key代码的卡顿。在redis.conf中我们可以设置 hz 10 代表1S中平均执行几次这也是我们上面所说的100MS的由来。但是仅仅定期删除会产生遗漏数据所以我们还需要加上惰性清除，最终保证对客户端来说数据是准确实时清除的。
• 那么关于【淘汰策略】又是啥呢？在上面过期清除是如果用户一直不请求过期的key ，并且随着业务产生越来越多的过期key . 这时候redis服务中还会堆积很多过期的无效key 。这个时候如果内存不够用了的话那又该怎么办呢？这时候我们需要设置淘汰策略比如果volatile-lru . 就会将最近最少使用的设置过期key进行清除从而保证尽可能的接收更多的有效数据！
• 这就是为什么会设计三者的原因！好好理解上面三个主题我们再去想想为什么会发生【缓存雪崩】、【缓存奔溃】、【缓存击穿】就好理解一点了呢？
• 关于上述的redis常见的灾难场景，我们下章节继续分析如何产生的、并且如何进行修复进行展开讨论。