Redis应用问题及解决
目录
一.缓存穿透
1.1 问题描述
1.2 解决方案
二.缓存击穿
2.1 问题描述
2.2 解决方案
三.缓存雪崩
3.1 问题描述
3.2 解决方案
当数据库压力变大，导致服务访问数据库响应变慢，导致服务的压力变大，最终可能导致服务宕机。
一.缓存穿透
1.1 问题描述
key对应的数据在数据库中并不存在，每次针对key的请求从缓存中获取不到，于是会请求数据库。当该key的请求很多，会导致数据库的压力变大，从而导致数据库宕机。
此时缓存还是平稳运行的，但是并没有起到作用。
比如：用一个不存在的用户id获取用户的信息，不论是缓存还是数据库都不存在该数据。若黑客利用此漏洞进行攻击可能压垮数据库。
1.2 解决方案
一个一定不存在的缓存以及查询不到的数据，如果在数据库中找不到数据不写入缓存，则在缓存中找不到数据每次请求都需要到数据库中查询。这将导致缓存失去意义。
- 对空值进行缓存：如果从数据库中没有查询到数据，返回为空，不管存不存在，我们仍然把这个空值(null)进行缓存，但是设置空值的过期时间很短，不超过5分钟。只能作为临时的方案。
- 设置可以访问的名单(白名单)：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmaps里面的id进行比较。如果id不在bitmaps里，进行拦截，不允许访问。
- 使用布隆过滤器：布隆过滤器的底层也是使用的hash，优点是空间效率和查询时间效率高，缺点是有一定的误识别率和删除困难。
- 进行实时监控：当发现redis缓存中的命中率急剧降低，排查访问对象和访问数据，和运维人员配合，设置黑名单限制访问。
二.缓存击穿
2.1 问题描述
key对应的数据存在，但是在redis中过期，此时若有大量的并发请求过来，这些请求发现缓存过期，会将请求发送到数据库中，查找到数据后将数据缓存到redis中。这个时候大量的并发请求可能瞬间把数据库击垮。
同一时间有大量的请求，请求到了redis中过期的数据，请求转发到数据库，大量的请求导致数据库压力过大，导致数据库宕机。
现象：1.数据库的压力瞬时增加。2.redis中并没有大量的key过期。3.redis正常运行，压力并没有变大。
原因：1.redis中某个key过期，并且有大量的访问使用到这个key。
2.2 解决方案
key可能会在某个时间点被超高并发的访问，是一个非常热点的数据。如果缓存中该key过期了，会导致数据库的压力变大，进而导致宕机，出现缓存击穿问题。
- 预先设置热门数据：在redis高峰访问之前，把热门数据提前存入到redis里面，并且加大这些热门数据key的过期时长。
- 实时调整：现场监控哪些热门数据，监控那些数据被频繁访问，实时调整key的过期时长。
- 使用锁：
- 在缓存失效的时候(判断拿出来的值为空)，不是立即去访问数据库。
- 先使用缓存工具的某些带成功操作返回值的操作(比如：redis的setnx)去set一个mutex key。
- 当操作返回成功时，在进行请求数据库的操作，并回设缓存，最后删除mutex key。
- 当操作返还失败时，证明有线程在访问数据库，当前线程等待一段时间再重试整个get缓存的方法。
- 加锁的缺点会导致效率变低。每次访问数据库只能一个线程去访问。
三.缓存雪崩
3.1 问题描述
key对应数据存在，但是再redis中过期，此时若有大量的并发请求过来，这些请求发现缓存过期一般会将请求发送到数据库中，并且将数据设回缓存，这个时候大量的并发请求会瞬间压垮数据库，导致数据库宕机。
缓存雪崩和缓存击穿的区别在于，缓存雪崩针对的是很多个key过期，缓存击穿只是针对一个key过期。
现象：1. 在极短的时间段内，redis中有大量的key过期。
3.2 解决方案
缓存失效时的雪崩问题对底层系统的冲击时非常可怕的。
- 构建多级缓存架构：nginx缓存+redis缓存+其他缓存(echache等)。如果redis不能处理，在其他缓存中查找。
- 使用锁或者队列：使用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行大量的访问。从而避免失效时大量的并发请求落到底层存储系统上，不适用于高并发的情况。
- 设置过期标志更新缓存：记录缓存数据是否过期(设置提前量)，如果过期会触发通知另外一个线程在后台去更新实际key的缓存。
- 将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分支随机，这样每一个缓存的过期时间的重复率会降，就很难引发集体失效的时间。