面试被吊打系列 - Redis缓存雪崩

小张兴冲冲去面试，结果被面试官吊打！

小张：面试官，你好。我是来参加面试的。

面试官：你好，小张。我看了你的简历，大家平时在项目中用了redis，能说一下大家使用redis的场景吗？

小张：redis的话咱们主要是用来存储一些经常使用的配置类数据还有一些热点数据；还有存储一些到期失效的数据，好比登陆用户颁发的token等。

面试官：那好，既然大家用来存储热点数据。那么我来问你个实际场景，查询热点数据的时候会先从缓存加载，若是缓存没有命中则会检索数据库获取数据。每每咱们还会给热点缓存数据设置一个过时时间。那么个人问题是，假设在某一时间点热点缓存所有过时失效了，这样全部的请求都会直接进入数据库，一瞬间就会把数据库压垮，若是是你会怎么解决这个问题？

小张：emm...面试官，我肚子有点不舒服，我先回去了。小张卒！

面试官：由于缓存同一时间大面积的失效，或者缓存服务暂时不能提供服务等，从而致使全部请求都去查数据库，致使数据库CPU和内存负载太高，甚至宕机。这一现象被称之为 缓存雪崩。

缓存雪崩能够经过如下四个维度来解决：

• 缓存预热

数据加热的含义就是在正式部署以前，先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不一样的key。

• 加上互斥锁

能够在第一个查询数据的请求上使用一个互斥锁来锁住它，其余的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，而后将数据放到redis缓存起来。后面的线程进来发现已经有缓存了，就直接走缓存。

• 过时时间均匀分布

给缓存的时效时间加上随机因子，即给缓存设置不一样的过时时间，让缓存失效的时间点尽可能均匀。

• 构建高可用的缓存系统

把Redis设计成高可用的，即便个别节点、个别机器、甚至是机房宕掉，依然能够提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

面试官：各位看官朋友们，大家学会怎么解决缓存雪崩的问题了吗？但愿大家的面试不会被这个问题难倒哟~

小张：学到了学到了，我下次再来。（早知道不提什么热点数据了，不提面试官就不会问。）

面试官：小样，不问这个那么我不会问其余的了吗？你下次再来试试！