共计 901 个字符,预计需要花费 3 分钟才能阅读完成。
小张灰溜溜去面试,后果被面试官吊打!
小张:面试官,你好。我是来加入面试的。
面试官:你好,小张。我看了你的简历,你们平时在我的项目中用了 redis,能说一下你们应用 redis 的场景吗?
小张:redis 的话咱们次要是用来存储一些罕用的配置类数据还有一些热点数据;还有存储一些到期生效的数据,比方登录用户颁发的 token 等。
面试官:那好,既然你们用来存储热点数据。那么我来问你个理论场景, 查问热点数据的时候会先从缓存加载,如果缓存没有命中则会检索数据库获取数据。往往咱们还会给热点缓存数据设置一个过期工夫。那么我的问题是,假如在某一时间点热点缓存全副过期生效了,这样所有的申请都会间接进入数据库,一瞬间就会把数据库压垮,如果是你会怎么解决这个问题?
小张:emm… 面试官,我肚子有点不难受,我先回去了。小张卒!
面试官:因为缓存同一时间大面积的生效,或者缓存服务临时不能提供服务等,从而导致所有申请都去查数据库,导致数据库 CPU 和内存负载过高,甚至宕机。这一景象被称之为 缓存雪崩 。
缓存雪崩能够通过以下四个维度来解决:
- 缓存预热
数据加热的含意就是在正式部署之前,先把可能的数据先事后拜访一遍,这样局部可能大量拜访的数据就会加载到缓存中。在行将产生大并发拜访前手动触发加载缓存不同的 key。
- 加上互斥锁
能够在第一个查问数据的申请上应用一个互斥锁来锁住它,其余的线程走到这一步拿不到锁就等着,等第一个线程查问到了数据,而后将数据放到 redis 缓存起来。前面的线程进来发现曾经有缓存了,就间接走缓存。
- 过期工夫均匀分布
给缓存的时效工夫加上随机因子,即给缓存设置不同的过期工夫,让缓存生效的工夫点尽量平均。
- 构建高可用的缓存零碎
把 Redis 设计成高可用的,即便个别节点、个别机器、甚至是机房宕掉,仍然能够提供服务,例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
面试官:各位看官敌人们,你们学会怎么解决缓存雪崩的问题了吗?心愿你们的面试不会被这个问题难倒哟~
小张:学到了学到了,我下次再来。(早晓得不提什么热点数据了,不提面试官就不会问。)
面试官:小样,不问这个那么我不会问其余的了吗?你下次再来试试!