如何预防 Redis 集群的缓存穿透与雪崩问题

1. 前言

在我们的平常的项目中多多少少都会使用到缓存，因为一些数据我们没有必要每次查询的时候都查询到数据库。特别是高QPS的系统，每次都去查询数据库，对于你的数据库来说将是灾难。

我们缓存时，我们的业务系统大概的调用流程如下图片：

但是在某些情况下，会导致缓存穿透和缓存雪崩的问题，导致请求全部打到DB上,进而导致DB崩溃，最后整个业务服务崩溃的严重问题。下面我们就来讲一下如何避免这些问题。

2.缓存穿透

2.1 什么是缓存穿透

一言以蔽之,大量用户查询的key在redis中没有查询到，导致请求全部打到了MySQL。

2.2 什么情况下会发生缓存穿透

• 大批量的key同时过期
• 黑客对系统进行攻击，拿一个不存在ID去查询数据，产生大量的请求到数据库去查询
• 某一个热点key过期，热点数据集中失效问题
• 业务自身代码或数据出现问题

下面我就对以上的各种情况给出预防方法.

黑客对系统进行攻击：

方案一：

遇到缓存和db中都没有的key，缓存一个特殊值 (unknown)，后面再出现查询这个key 的请求的时候，直接返回unknown，就不用再数据库中去走一圈了，但是别忘了设置过期时间。

方案二：

布隆过滤器

在缓存之前在加一层 BloomFilter，在查询的时候先去 BloomFilter 去查询 key 是否存在，如果不存在就直接返回，存在再走查缓存 -> 查 DB.

从SpringBoot构建十万博文聊聊缓存穿透

http://www.imooc.com/article/details/id/290930

方案比较：

针对于一些恶意攻击，攻击带过来的大量 key 是不存在的，那么我们采用第一种方案就会缓存大量不存在 key 的数据。此时我们采用第一种方案就不合适了，我们完全可以先对使用第二种方案进行过滤掉这些 key 。针对这种 key 异常多、请求重复率比较低的数据，我们就没有必要进行缓存，使用第二种方案直接过滤掉。而对于空数据的 key 有限的，重复率比较高的，我们则可以采用第一种方式进行缓存。

某一个热点key过期

方案一:设置不同的失效时间

为了避免这些热点的数据集中失效，那么我们在设置缓存过期时间的时候，我们让他们失效的时间错开。比如在一个基础的时间上加上或者减去一个范围内的随机值。

方案二：加锁，限制访问DB线程数

通常解决方案往往是使用互斥锁，让一个线程访问数据库，并将数据更新到缓存中，其他线程访问缓存中数据。如果是基于jvm锁机制的话，只能解决单机问题，也就是只让本机一个线程访问缓存，但是分布式条件下是不能使用的。所以要基于缓存的分布式锁来实现。

//查询缓存
if(redis.contains(key)){
 return value
}
------------ 用锁保护mysql --------------------
tryLock....................
//查询数据库
if(redis.contains(key)){ //在锁里面在检查一次
 value = queryDB()
} else {
 return value;
}
redis.set(key,value) //重建缓存
return value;
unLock.......................
--------------------------------

3.缓存雪崩

什么是缓存雪崩

缓存雪崩场景如下：由于某些原因（比如关晓彤和鹿晗宣布恋爱了）导致出现了热点key，这个key被频繁访问，导致某一个redis cluster集群节点负载过高而宕机, 这些无处安身的key会被槽转移到其他节点，继而导致这个节点也宕机....最终导致缓存集群全部宕机。

在互联网系统运行过程中会出现缓存热点key的情况，比如微博上的某个热点话题，会有大量的人关注，这个key会集中在某一个redis cluster分片机器上，造成这台机器宕机，这些热点key转移到其他分片又会造成其他机器继续宕机，造成了雪崩的问题。

解决办法

事前：

使用集群缓存，保证缓存服务的高可用

这种方案就是在发生雪崩前对缓存集群实现高可用，如果是使用 Redis, 可以使用主从 + 哨兵，Redis Cluster 来避免 Redis 全盘崩溃的情况。

事中：

ehcache本地缓存 + Hystrix限流&降级，避免MySQL被打死

使用 echcache 本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，ehcache 本地缓存还能够支撑一阵。

使用 Hystrix 进行限流 & 降级，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。

解决雪崩的三个关键点

一.是如何快速发现热点可以

二.是及时把热点key缓存到JVM堆内存（EHCache）

三.限流

可以参考有赞TMC的思路，及时发现热点key，然后缓存到本地堆内存，TMC 在提供“热点探测” + “本地缓存”的核心能力同时，也为应用服务提供了灵活的配置选择，应用服务可以结合实际业务情况在“热点阈值”、“热点 key 探测数量”、“热点黑白名单”维度进行自由配置以达到更好的使用效果。