Redis缓存击穿、雪崩、穿透，Redis分布式锁（不常见）

Redis缓存击穿

key过期的瞬间，流量进入服务器，跳过redis，直接访问mysql

使用setnx锁

setnx锁的问题

如果请求执行因为某些原因意外退出了，导致创建了锁但是没有删除锁，那么这个锁将一直存在以至于以后缓存再也得不到更新

需要给锁加一个过期时间

• 需要借助 Expire 来设置
• 把两者用 Multi/Exec 包裹起来以确保请求的原子性，以免 SetNX 成功了 Expire 却失败了。
• 当多个请求到达时，虽然只有一个请求的 SetNX 可以成功，但是任何一个请求的 Expire 却都可以成功
• 如此就意味着即便获取不到锁，也可以刷新过期时间，如果请求比较密集的话，那么过期时间会一直被刷新，导致锁一直有效

Redis缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有

这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空

这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题

暴力解决，缓存空结果

如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴

布隆过滤器

• 设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中
• 一个一定不存在的数据会被这个bitmap拦截掉，避免了对底层存储系统的查询压力
• 如果一个查询返回的数据为空，不管是数据不存在还是系统故障，我们仍然把这个结果进行缓存，但是它的过期时间会很短最长不超过5分钟

 

Redis缓存雪崩

因为缓存层承载了大量的请求，有效的保护了存储层，但是如果缓存由于某些原因，整体不能够提供服务

于是所有的请求，就会到达存储层，存储层的调用量就会暴增，造成存储层也会挂掉的情况

缓存雪崩的英文解释是奔逃的野牛，指的是缓存层当掉之后，并发流量会像奔腾的野牛一样

大量后端存储存在这种问题的一个场景是

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，大量数据会去直接访问DB，此时给DB很大的压力

解决方案

设置redis集群和DB集群的高可用

• 如果redis出现宕机情况，可以立即由别的机器顶替上来，这样可以防止一部分的风险。

使用互斥锁

• 在缓存失效后，通过加锁或者队列来控制读和写数据库的线程数量
• 比如：对某个key只允许一个线程查询数据和写缓存，其他线程等待
• 单机的话，可以使用synchronized或者lock来解决，如果是分布式环境，可以是用redis的setnx命令来解决

不同的key,可以设置不同的过期时间，让缓存失效的时间点不一致，尽量达到平均分布

• redis中设置永久不过期，这样就保证了，不会出现热点问题，也就是物理上不过期

资源保护

• 使用netflix的hystrix，可以做各种资源的线程池隔离，从而保护主线程池

Redis分布式锁

分布式锁，强调准确度和一致性，多使用zookeeper