缓存异常之缓存雪崩、缓存击穿和缓存穿透

变速风声
1,313 阅读8分钟

参考资料

缓存异常的3个问题

设计一个缓存系统，就会面对缓存异常的 3 个问题

  1. 缓存雪崩
  2. 缓存击穿
  3. 缓存穿透

缓存雪崩与缓存击穿的区别：缓存雪崩是针对很多 key 缓存失效的情况，缓存击穿是针对某一个 key。

分类原因备注
缓存雪崩1.大量缓存数据同时过期；2.redis故障
缓存击穿热点数据缓存过期要请求的数据，不在缓存中，但在DB中
缓存穿透数据既不在缓存，也不在数据库缓存和DB中均无要请求的数据

缓存雪崩

产生原因

  1. 大量缓存数据在同一时间过期或失效
  2. Redis 故障宕机

解决办法

1.均匀设置过期时间，避免同一时间过期

避免将大量的数据设置成同一个过期时间。对缓存数据设置过期时间时，可以给过期期时间加上一个随机数，这样就可以保证数据不会在同一时间过期。

setRedis(Key，value，time + Math.random() * 10000)；

2.互斥锁

使用互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里）。当缓存构建完成后，再释放锁。

未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

3.双key策略

对缓存数据使用两个 key，一个是主 key，会设置过期时间；一个是备 key，不会设置过期。它们只是 key 不一样，但 value 值是一样的，相当于给缓存数据做了个副本。

当业务线程访问不到主 key 的缓存数据时，就直接返回备 key 的缓存数据，然后在更新缓存的时候，同时更新主 key 和备 key 的数据。

4.后台更新缓存，定时更新或使用消息队列通知更新

业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新或使用消息队列通知更新。

  1. 定时更新：后台线程定时的把数据更新到缓存中。
  2. 使用消息队列通知更新：在业务线程发现缓存数据失效后（缓存数据被淘汰），通过消息队列发送一条消息通知后台线程更新缓存。

在业务刚上线的时候，我们最好提前把数据缓起来，而不是等待用户访问才来触发缓存构建，这就是所谓的 「缓存预热」。后台更新缓存的机制刚好也适合干这个事情。

5.请求限流

启用请求限流机制，只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。

缓存击穿

产生原因

  1. 热点数据缓存过期

如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，造成缓存击穿。

解决办法

1.互斥锁

同「缓存雪崩」的「互斥锁」解决方案。

2.不给热点数据设置过期时间，由后台异步更新缓存

不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间。

缓存穿透

产生原因

当用户访问的数据，既不在缓存中，也不在数据库中。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

缓存穿透的发生一般有这 2 种情况

  1. 业务误操作，缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据
  2. 黑客恶意攻击，故意大量访问某些读取不存在数据的业务

解决办法

1.限制非法请求

在接口调用时候，判断求请求参数是否合理，请求参数是否含有非法值，请求字段是否存在等情况。如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。

2.缓存空值或者默认值

当线上业务发现缓存穿透时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。

3.使用布隆过滤器快速判断数据是否存在

使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在。

缓存设计中的一些问题

缓存热点

对于突发事件，大量用户同时去访问热点信息，这个突发热点信息所在的缓存节点就很容易出现过载和卡顿现象，甚至 Crash，我们称之为「缓存热点」。

这个在新浪微博经常遇到，某大 V 明星出轨、结婚、离婚，瞬间引发数百千万的吃瓜群众围观，访问同一个 key，流量集中打在一个缓存节点机器，很容易打爆网卡、带宽、CPU 的上限，最终导致缓存不可用。

「缓存热点」的解决方案如下

  • 首先要先找到这个热 key，比如通过 Spark 实时流分析，及时发现新的热点 key。
  • 将集中化流量打散，避免一个缓存节点过载。由于只有一个 key，我们可以在 key 的后面拼上「有序编号」，比如 key#01、key#02 等多个副本，这些加工后的 key 位于多个缓存节点上。
  • 每次请求时，客户端随机访问一个即可。

缓存大Key

当访问缓存时，如果 key 对应的 value 过大，读写、加载很容易超时，容易引发网络拥堵。另外缓存的字段较多时，每个字段的变更都会引发缓存数据的变更，频繁的读写，导致慢查询。如果大 key 过期被缓存淘汰失效，预热数据要花费较多的时间，也会导致慢查询。

所以我们在设计缓存的时候，要注意缓存的粒度，既不能过大，如果过大很容易导致网络拥堵；也不能过小，如果太小，查询频率会很高，每次请求都要查询多次。

「缓存大Key」的解决方案如下

  • 设置一个阈值，当 value 的长度超过阈值时，对内容启动压缩，降低 kv 的大小。
  • 颗粒划分，将大 key 拆分为多个小 key，独立维护，成本会降低不少。
  • 大 key 要设置合理的过期时间，尽量不淘汰那些大 key。

Spring Cache和缓存击穿、缓存穿透

缓存击穿

系统中若有热点数据缓存过期，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，造成缓存击穿。

在使用 Spring Cache 时，可使用 @Cacheable 注解的 sync=true属性，采用同步方式，在缓存不存在时只允许一个线程执行对应方法（如请求DB），其他线程将阻塞，直到将方法返回的结果写入缓存中。

@Cacheable(cacheNames="expensiveOp", sync=true)
public void executeExpensiveOperation(String id) {
    //若无缓存，则请求DB
}

缓存穿透

当用户访问的数据，既不在缓存中，也不在数据库中。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

在使用 Spring Cache 时，若采用 Redis 作为缓存实现方案，可以在配置文件中，指定如下属性，避免缓存穿透。

# 是否缓存空值 防止缓存穿透
spring.cache.redis.cache-null-values=true
avatar
文章
阅读
粉丝