redis缓存异常

缓存穿透

用户请求的数据在缓存中不存在（没有命中，同时在数据库中也不存在），导致用户每次请求该数据都要去数据库中查询一遍。

恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。

关键：传进来的key在Redis中是不存在的，在Redis中查不到

解决方案：

• 将无效的key存放进Redis中：

当出现Redis查不到数据，数据库也查不到数据的情况，把key保存到Redis中，设置value="null"，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。（但这种处理方式是有问题的，如传进来的这个不存在的Key值每次都是随机的，存进Redis将无意义。）

对于空数据的key有限的，重复率比较高的采用这种

• 使用布隆过滤器：缓存之前再加一个布隆过滤器

如果布隆过滤器判定某个 key 不存在布隆过滤器中，那么就一定不存在，如果判定某个 key 存在，那么很大可能是存在(存在一定的误判率)。缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，不让其访问数据库，避免了对底层存储系统的查询压力。

针对这种key异常多、请求重复率比较低的数据用布隆过滤器直接过滤掉

缓存击穿

某个热点的key失效，大并发集中对其进行请求，造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。

缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效

解决方案：

• 降低打在数据库上的请求数量：

在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降

• 热点key不设置过期时间

物理不过期，针对热点key不设置过期时间；逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建

缓存雪崩

如果缓存在某一个时刻出现大规模的key失效，会导致大量的请求打在了数据库上面，导致数据库压力巨大，在高并发的情况下，可能会瞬间导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。

关键：同一时间的大规模的key失效

可能原因：

• Redis宕机
• 采用了相同的过期时间

解决方案：

1、事前：

• 均匀过期：设置不同的过期时间，让缓存失效的时间尽量均匀，避免相同的过期时间导致缓存雪崩，造成大量数据库的访问。如把每个Key的失效时间都加个随机值，setRedis（Key，value，time + Math.random() * 10000）；，保证数据不会在同一时间大面积失效。

• 分级缓存：第一级缓存失效的基础上，访问二级缓存，每一级缓存的失效时间都不同。

• 热点数据缓存永远不过期。永不过期实际包含两层意思：

  • 物理不过期，针对热点key不设置过期时间
  • 逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建

• 保证Redis缓存的高可用，防止Redis宕机导致缓存雪崩的问题。可以使用 主从+ 哨兵，Redis集群来避免 Redis 全盘崩溃的情况。

2、事中：

• 互斥锁：在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降

• 使用熔断机制，限流降级。当流量达到一定的阈值，直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上将数据库击垮，至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。

3、事后：

开启Redis持久化机制，尽快恢复缓存数据，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。