彻底搞懂Redis击穿、雪崩、穿透（中）

最新推荐文章于 2024-08-15 13:27:07 发布

爱学习的执念

最新推荐文章于 2024-08-15 13:27:07 发布

阅读量679

点赞数 8

分类专栏：软件测试技术分享软件测试面试文章标签： redis spring 数据库

本文链接：https://blog.csdn.net/YJT1002/article/details/140572265

版权

软件测试同时被 3 个专栏收录

658 篇文章 5 订阅

订阅专栏

技术分享

381 篇文章 0 订阅

订阅专栏

软件测试面试

282 篇文章 0 订阅

订阅专栏

本篇我们继续来讨论缓存的另一个问题——缓存雪崩。

缓存雪崩

什么是缓存雪崩？

其实把缓存击穿搞清楚了，那么理解缓存雪崩就容易得多了。

缓存击穿是指1个热key失效，而缓存雪崩，顾名思义，指的就是大面积的key在同一瞬间全部失效，导致大量的请求打到数据库上，就像雪崩一样，从而造成数据库响应不及时挂掉。这种属于自然雪崩，主要是引起周期性的压力波峰，还有另一种非自然雪崩，就是缓存服务某个节点或多个节点甚至全部节点都突然宕机，导致所有的请求都打到数据库上，进而导致数据库宕机，这种也是不可预知的雪崩。

所以，对于缓存雪崩来说，一般少量的缓存失效，所带来的数据库并发压力是不会太大的，而是大量的缓存同时失效，导致所有key的并发加起来打到数据库上，才会影响到我们的数据库。

其实，在真实场景中，缓存雪崩是一个更容易发生的问题，因为它不像缓存击穿那么极端，1个key就有成千上万的并发量，直接把数据库击垮，而是一个key可能只有几十几百的并发量，然后大量的key同时过期，导致很多key的并发叠加起来，积累到成千上万，再把数据库击垮。

如何解决？

我们既然知道了缓存雪崩产生的原因，那么自然而然就能见招拆招，找到对应的解决方案。

因为缓存雪崩是大面积的key同时过期失效，才导致大量的并发直接打到数据库上，那么我们很正常的思路就是让并发分散开来。

第一种常见的做法是分散缓存数据的过期时间，防止同一时间大量数据过期现象发生。

我们可以通过随机初始化过期时间，使得key的过期时间分散开来，一个一个过期，并发量也就被分成一部分一部分，这样一来每次打到数据库上的只有少量请求。看起来就像是削峰操作，这种做法是最简单有效的，因此绝大多数情况下也是采用这种方法。

但是，如果你的业务对时间点的要求很高，比如：必须在每天的指定时间去更新数据。

由于业务需求，必须在固定的时间点刷新数据，并且不允许出现旧数据，也就是说必须让缓存数据在同一时刻全部失效。那么，像这样的业务我们又该如何解决呢？

因为这个场景非常类似削峰操作，所以自然而然联想到消息队列，也就是先把请求打到MQ上，然后再一个一个依次消费。

这种做法合理吗？从系统实现的角度来看，这样确实可以保证数据库的请求压力被扛下来，再进行异步消费。对于写操作，使用异步写是没有任何问题的，因为用户只要求把数据存入而已，但是对于读操作，是不应该使用到消息队列的，因为这样会影响用户接收到消息的时间，使用队列依次读取，那么大量用户的响应延迟就会变高，对于用户体验来说是不友好的。所以对于读请求，不适合使用队列的方式，因为它把请求串行化了，不再是并发执行。

既然这种做法不合理，那么还有其他的方法吗？这时，就有人提出让缓存提前更新的观点，也就是预加载缓存，提前主动加载热门数据到缓存中，在数据过期之前进行刷新，减少雪崩的风险。

但是提前更新可能会导致数据不准确，例如在23:58开始更新，然后在23:59的时候又有大量的数据被修改，用户在24:00查看数据时发现数据仍然没有变化，他们就会认为24:00系统更新数据的说法不靠谱。

因此Redis缓存还是必须要同一时间点失效，不能把时间分散开来。既然Redis的过期时间不能分散，不能在Redis上做文章，那么我们不妨改变一下思维方式，是谁来访问Redis，是service服务层，我们可以把service服务层的查询请求分散开来，利用客户端设置一个短暂的随机延迟时间，使得查询请求分散开，少量的请求先查询，就会读数据库，存入Redis缓存，其他请求由于随机时间，稍微慢一点再去Redis读数据。