Redis 缓存穿透、缓存雪崩原理及解决方案

Redis缓存的场景

客户端请求在缓存层命中就直接返回，如果miss就去读取存储层，存储层读取到就写入缓存层，然后再返回到客户端

Redis的优缺点

• 优点：加速读写，降低后端负载、减少DB压力
• 缺点：数据不能保证一致性，代码维护成本和运维成本

缓存穿透

引发原因

在查询一个一定不存在的数据，由于缓存是不命中时被动写入，并且处于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，缓存层失去意义。
当在大流量流入时，可能因为频繁访问存储层导致DB直接宕机，这样会形成被人利用不存在的key频繁攻击应用的漏洞。

解决方法

有多种方法能有效解决缓存穿透的问题

1. 最为常简的是采用布隆过滤器，将所有可能存在的数据哈希到一个足够发的 bigmap 中，一个一定不存在的数据会被该 bigmap 拦截掉，从而避免对底层存储系统造成查询压力。
2. 另一种更为简单的方法，如果一个查询返回的数据为空（无论数据为空，或是系统故障），将空结果进行缓存，设置一个最长不超过五分钟的过期时间。
   
   
   

缓存雪崩

引发原因

1. 设置缓存时采用了相同的过期时间，导致缓存在某时刻同时失效，请求全部转向DB，DB瞬时压力过重雪崩。
2. Redis宕机，导致客户端的请求之间流向DB，拖垮DB。
   
   
   

解决方发

有多种方法能有效解决缓存雪崩的问题

问题一的解决方案

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2. 简单方案就是将缓存失效时间分散开，我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

问题二的解决方案

1. 保持缓存层服务器的高可用。
   –监控、集群、哨兵。当一个集群里面有一台服务器有问题，让哨兵踢出去。
2. 依赖隔离组件为后端限流并降级。
   比如推荐服务中，如果个性化推荐服务不可用，可以降级为热点数据。
3. 提前演练。
   演练 缓存层crash后，应用以及后端的负载情况以及可能出现的问题。 对此做一些预案设定。