Redis 应用问题
Redis 应用问题
1、缓存穿透
1.1、问题概述
key 对应的数据在数据源中不存在，每次针对此 key 的请求从缓存获取不到，请求都会压到数据源（也就是不断的去查数据库，从而使得数据库系统崩溃）。比如一个不存在的用户 id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击，就会可能直接导致数据库崩溃；
1.2、解决方案
一个一定不存在的缓存以及查询不到的数据，由于缓存是命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要去存储层去查询，失去了缓存的意义；
- 对空值缓存：如果一个查询返回的数据的结果为空，那么我们就把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不能超过五分钟；
- 设置白名单：使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmaps 里面的 id 进行比较，如果 id 不在 bitmaps 里面，进行拦截，不允许访问；
- 采用布隆过滤器：这个是 1970 年，由布隆提出的，他实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中，他的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。将所有可能存在的数据哈希到一个足够大的 bitmaps 中，一个一定不存在的数据会被这个 bitmaps 拦截掉，从而避免了给底层存储系统的造成压力；
- 进行实时监控：当发现 Redis 的命中率开始急剧降低，需要排查访问对象和访问的数据，和运维人员配合，设置黑名单来对指定的 IP 限制服务；
2、缓存击穿
2.1、问题描述
key 对应的数据是存在的，但是在 Redis 是过期的，此时有大量的请求过来，要访问这个 key，这些请求发现缓存过期，一般都会从后端 DB 家在数据并回设到缓存中，但是此时的高并发的请求，可能会直接将后端 DB 压垮。
key 可能会在某些时间点被超高并发的访问，是一种热点数据，这个时候，就需要考虑缓存击穿的问题；
2.2、解决方案
- 预先设置热门数据：在 Redis 高峰访问之前，把一些热门数据提前存入到 Redis 里面，并且加大这些热门数据 key 的存活时间；
- 实时调整：现场监控哪些是热门数据，实时调整 key 的过期时长；
- 使用锁：具体操作看下图
3、缓存雪崩
3.1、问题描述
key 对应的数据是存在的，但是在 Redis 中是过期的，此时如果有大量的请求发送过来，这些请求发现缓存过期一般都会直接请求数据库数据，并加载到 Redis 中，而此时的高并发的请求可能会直接把后端的数据库系统压垮；但是和前面的缓存击穿的不同点在于，这边指的是很多 key 缓存，前者指的是一个 key；
3.2、解决方案
缓存失效时，对底层系统的冲击是很可怕的，结果是很严重的；
- 构建更多的缓存架构：Nginx 缓存 + Redis 缓存 + 其他缓存（ehcache等）；
- 使用锁或者队列：用锁或者队列的方式来保证不会有大量的线程对数据库系统进行一次性的读写，从而避免失效时大量的并发请求落到存储系统上，这样不适用于高并发情况；
- 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台更新实际 key 的缓存；
- 将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个韩村的过期时间的重复率就会降低，就很难引发集体失效的事件；
