Redis 缓存击穿（失效）、缓存穿透、缓存雪崩怎么解决？

作者 | 码哥

来源 | 码哥字节

原始数据存储在 DB 中（如 MySQL、Hbase 等），但 DB 的读写性能低、延迟高。

比如 MySQL 在 4 核 8G 上的 TPS = 5000，QPS = 10000 左右，读写平均耗时 10~100 ms。

用 Redis 作为缓存系统正好可以弥补 DB 的不足，「码哥」在自己的 MacBook Pro 2019 上执行 Redis 性能测试如下：

$ redis-benchmark -t set,get -n 100000 -q
SET: 107758.62 requests per second, p50=0.239 msec
GET: 108813.92 requests per second, p50=0.239 msec

TPS 和 QPS 达到 10 万，于是乎我们就引入缓存架构，在数据库中存储原始数据，同时在缓存总存储一份。

当请求进来的时候，先从缓存中取数据，如果有则直接返回缓存中的数据。

如果缓存中没数据，就去数据库中读取数据并写到缓存中，再返回结果。

这样就天衣无缝了么？缓存的设计不当，将会导致严重后果，本文将介绍缓存使用中常见的三个问题和解决方案：

缓存击穿（失效）；
缓存穿透；
缓存雪崩。

缓存击穿（失效）

高并发流量，访问的这个数据是热点数据，请求的数据在 DB 中存在，但是 Redis 存的那一份已经过期，后端需要从 DB 从加载数据并写到 Redis。

关键字：单一热点数据、高并发、数据失效

但是由于高并发，可能会把 DB 压垮，导致服务不可用。如下图所示：

缓存击穿

解决方案

过期时间 + 随机值

对于热点数据，我们不设置过期时间，这样就可以把请求都放在缓存中处理，充分把 Redis 高吞吐量性能利用起来。

或者过期时间再加一个随机值。

设计缓存的过期时间时，使用公式：过期时间=baes 时间+随机时间。

即相同业务数据写缓存时，在基础过期时间之上，再加一个随机的过期时间，让数据在未来一段时间内慢慢过期，避免瞬时全部过期，对 DB 造成过大压力

预热

预先把热门数据提前存入 Redis 中，并设热门数据的过期时间超大值。

使用锁

当发现缓存失效的时候，不是立即从数据库加载数据。

而是先获取分布式锁，获取锁成功才执行数据库查询和写数据到缓存的操作，获取锁失败，则说明当前有线程在执行数据库查询操作，当前线程睡眠一段时间在重试。

这样只让一个请求去数据库读取数据。

伪代码如下：

public Object getData(String id) {String desc = redis.get(id);// 缓存为空，过期了if (desc == null) {// 互斥锁，只有一个请求可以成功if (redis(lockName)) {try// 从数据库取出数据desc = getFromDB(id);// 写到 Redisredis.set(id, desc, 60 * 60 * 24);} catch (Exception ex) {LogHelper.error(ex);} finally {// 确保最后删除，释放锁redis.del(lockName);return desc;}} else {// 否则睡眠200ms，接着获取锁Thread.sleep(200);return getData(id);}}
}

缓存穿透

缓存穿透：意味着有特殊请求在查询一个不存在的数据，即数据不存在 Redis 也不存在于数据库。

导致每次请求都会穿透到数据库，缓存成了摆设，对数据库产生很大压力从而影响正常服务。

如图所示：

缓存穿透

解决方案

缓存空值：当请求的数据不存在 Redis 也不存在数据库的时候，设置一个缺省值（比如：None）。当后续再次进行查询则直接返回空值或者缺省值。
布隆过滤器：在数据写入数据库的同时将这个 ID 同步到到布隆过滤器中，当请求的 id 不存在布隆过滤器中则说明该请求查询的数据一定没有在数据库中保存，就不要去数据库查询了。

BloomFilter 要缓存全量的 key，这就要求全量的 key 数量不大，100 亿条数据以内最佳，因为 100 亿条数据大概要占用 3.5GB 的内存。