redis应用问题的解决

1. 缓存穿透

缓存穿透是什么？

key对应的数据在数据源中并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户ID获取用户信息，不论是缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库

现象

1. 应用服务器压力增大（服务器）
2. redis命中率降低（redis）
3. 一直查询数据库（数据库）

造成的原因

1. redis查询不到数据（没有请求的缓存）
2. 出现了很多非正常的url访问（一般就是黑客攻击和服务器被攻击为了让服务器崩溃）

解决方案

1. 对空值缓存：如果一个查询返回的数据不为空（不管数据是否不存在），我们任然把这个空结果（null）进行缓存，设置过期时间会很短，最长不超过五分钟
2. 设置可访问的白名单：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmaps里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问
3. 进行实时监控:当发现redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务（对发送请求的人拉黑）

2. 缓存击穿

缓存击穿是什么？

key对应的数据存在，但在redis中过期，此时若有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮

现象

1. 数据库的访问压力瞬间增加
2. redis里面没有出现大量key过期
3. redis正常运行

原因

1. redis某个key过期了，但这个key又是最频繁被访问的key

解决方案

1. 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

2. 实时调整：现场监控哪些数据热门，实时调整key的过期时长

3. 使用锁：效率低

• 就是在缓存失效的时候（判断拿出来的数据为空），不是立即去load db 。
• 先使用缓存工具的某些带成功操作返回值的操作（比如redis的SETNX）去set一个mutex key
• 当操作返回成功时，再进行load db的操作，并回设缓存，最后删除mutex key
• 当操作返回失败，证明有线程在load db ，当线程睡眠一段时间再重试整个get缓存的方法

3. 缓存雪崩

缓存雪崩是什么？

key对应的数据存在，但在redis中过期，此时若有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮
缓存雪崩和缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key

现象

1. 数据库压力变大，服务器崩溃

原因

1. 在极少时间段，查询大量key的集中过期情况

解决方案

1. 构建多级缓存架构：nginx缓存+redis缓存+ 其他缓存（ehcache等）
2. 使用锁或队列：用加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行大量读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
3. 设置过期标志更新缓存：记录缓存数据是否快要过期（设置提前量），如果过期会触发另外的线程去后台更新实际key缓存
4. 将缓存失效时间分散开：比如我们可以在原有的失效时间基础上再加上一个随机值，比如1-5分钟随机，这样每个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件