学懂缓存雪崩，缓存击穿，缓存穿透仅需一篇，基于Redis讲解

缓存雪崩有两种诱因，不同诱因应对的策略是不同的。

针对大量数据同时过期：

• 均匀设置过期时间
• 互斥锁
• 后台更新缓存
• ......

1.均匀设置过期时间

目的是要避免大量数据设置成同时过期。给这些设置了过期时间的key加上一个随机数，让他们尽量不同时过期。尤其是在缓存预热的时候，更需要这样做。

2.互斥锁

当业务线程在处理用户请求时，如果发现访问的数据不在Redis里，就加一个互斥锁(setnx命令可以达到这个效果)，保证同一个时间内只有一个请求来构建缓存(从数据库中读，再更新到Redis)，构建完后释放锁，未能获取到锁的请求，要么等锁释放后重新读取缓存，要么返回空或默认值。

public%20class%20RedisTool%20{

%20%20%20%20private%20static%20final%20String%20LOCK_SUCCESS%20=%20"OK";
%20%20%20%20private%20static%20final%20String%20SET_IF_NOT_EXIST%20=%20"NX";
%20%20%20%20private%20static%20final%20String%20SET_WITH_EXPIRE_TIME%20=%20"PX";

%20%20%20%20/**
%20%20%20%20%20*%20尝试获取分布式锁
%20%20%20%20%20*%20@param%20jedis%20Redis客户端
%20%20%20%20%20*%20@param%20lockKey%20锁
%20%20%20%20%20*%20@param%20requestId%20请求标识
%20%20%20%20%20*%20@param%20expireTime%20超期时间
%20%20%20%20%20*%20@return%20是否获取成功
%20%20%20%20%20*/
%20%20%20%20public%20static%20boolean%20tryGetDistributedLock(Jedis%20jedis,%20String%20lockKey,%20String%20requestId,%20int%20expireTime)%20{

%20%20%20%20%20%20%20%20String%20result%20=%20jedis.set(lockKey,%20requestId,%20SET_IF_NOT_EXIST,%20SET_WITH_EXPIRE_TIME,%20expireTime);

%20%20%20%20%20%20%20%20if%20(LOCK_SUCCESS.equals(result))%20{
%20%20%20%20%20%20%20%20%20%20%20%20return%20true;
%20%20%20%20%20%20%20%20}
%20%20%20%20%20%20%20%20return%20false;
%20%20%20%20}
}

第一个为key，我们使用key来当锁，因为key是唯一的。

第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？分布式锁有一个条件，谁上的锁就必须谁解开，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用多种方法生成，只要能保证在一段时间内不重复。

第三个为nxxx，这个参数我们填的是NX，意思是SET%20IF%20NOT%20EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；

第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。

第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1.%20当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2.%20已有锁存在，不做任何操作。

不过这种方法就要注意一下死锁问题，然后我代码这样写的原因是，只有一个操作，是原子性的，如果把加锁和设置过期时间分开，可能会发生一些意想不到的问题。

3.后台更新缓存

业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。虽然不设置有效期，但是其实有一个逻辑过期的标识，一旦业务线程发现这个缓存过期，就把它交给后台线程去处理。业务线程返回”过期值“。

这种方法适合用于对于缓存一致性要求不会特别严格的场景

针对Redis宕机：

• 服务熔断或进行请求限流
• 构建Redis主从或集群来保证可靠

1.服务熔断或进行请求限流

暂停业务，直接返回错误。等Redis恢复正常后，再允许业务进行。目的是保护数据库。

也可以启用限流，只允许少部分请求访问数据库，大于能承受的压力的请求直接拒绝服务。等到Redis正常且预热完毕，再解除限流。

2.构建Redis主从和哨兵或集群

主从能够分担主节点压力，有了哨兵的话，能够在Redis主节点故障时，即使切换主节点，避免Redis故障导致的缓存雪崩问题。

Redis集群(cluster)也是同理。