【Redis】回顾下Redis缓存击穿、缓存雪崩、缓存穿透知识点

CSDN话题挑战赛第2期
参赛话题：学习笔记

学习之路，长路漫漫，写学习笔记的过程就是把知识讲给自己听的过程。这个过程中，记录思考的过程，便于日后复习，梳理自己的思路。学习之乐，独乐乐，不如众乐乐，把知识讲给更多的人听，何乐而不为呢?
来来一起学习Redis缓存击穿、缓存雪崩、缓存穿透知识点

什么是缓存击穿?

Redis中的key可能会在某些时间点被超高并发地访问。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

缓存击穿带来的问题

当这个key在失效的瞬间，redis查询失败，持续的大并发请求就穿破缓存，直接请求数据库，最后数据库可能压力太大宕机。

缓存击穿解决方案

• 使用互斥锁(mutex key)：mutex，就是互斥。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用Redis的SETNX去set一个互斥key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现互斥的效果。

• 软过期：也就是逻辑过期，不使用redis提供的过期时间，而是业务层在数据中存储过期时间信息。查询时由业务程序判断是否过期，如果数据即将过期时，将缓存的时效延长，程序可以派遣一个线程去数据库中获取最新的数据，其他线程这时看到延长了的过期时间，就会继续使用旧数据，等派遣的线程获取最新数据后再更新缓存。

推荐使用互斥锁，因为软过期会有业务逻辑侵入和额外的判断。

什么是缓存雪崩?

在某一个时间段，缓存集中过期失效.

缓存雪崩带来的问题

对这批数据的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力.

缓存雪崩解决方案

• 解决缓存雪崩问题的关键是让缓存Key的过期时间分散。
• 因此我们可以把数据按照业务分类，然后设置不同过期时间。
• 相同业务类型的key，设置固定时长加随机数。尽可能保证每个Key的过期时间都不相同。
• 另外，Redis宕机也可能导致缓存雪崩，因此我们还要搭建Redis主从集群及哨兵监控，保证Redis的高可用。

什么是缓存穿透?

正常情况下，我们去查询数据都是存在。那么请求去查询一条压根儿数据库中根本就不存在的数据，也就是缓存和数据库都查询不到这条数据，但是请求每次都会打到数据库上面去。这种查询不存在数据的现象我们称为缓存穿透。

缓存穿透带来的问题

如果有黑客会对你的系统进行攻击，拿一个不存在的id 去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉。

缓存穿透解决方案

两种解决方案：

• 1. 把不存在的key设置null值到缓存中。
• 2. 使用布隆过滤器，在查询缓存前先通过布隆过滤器判断key是否存在，存在再去查询缓存