🌏【架构师指南】带你分析认识缓存穿透 / 雪崩 / 击穿

使用场景

减低后端负载：对高消耗的 SQL 结果进行缓存，例如 join 结果集/分组统计结果

加速请求响应

大量写合并为批量写，如计数器先 Redis 累加再批量写到 DB

缓存更新策略

• LRU(Least Recently Used)，根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高，则延迟其淘汰时间” - LRU 缓存更新

• LFU(Least Frequently Used)根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”- LFU 缓存更新

• FIFO ，根据"先进先出" 思想来更新缓存数据

• 超时剔除 - expire

• 主动更新 - 开发控制生命周期

• 扩展：缓存污染 - 缓存污染降低了缓存的使用率，把不常用的数据读取到缓存，同时会把常用的数据移出缓存，这样会直接降低系统的数据命中率

缓存穿透问题

场景【key 不存在，高并发查询数据库】

缓存穿透是指使用不存在的 key 进行大量的高并发查询，导致缓存无法命中，每次请求都要都要穿透到后端数据库查询，使得数据库的压力非常大，甚至导致数据库服务压死。

解决方法

分布式队列及分布式锁

接口层实现 api 限流、防御 DDOS、接口频率限制、网关实现黑名单、用户授权、id 检查等

缓存空对象：

如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，但它的过期时间会很短，不超过 5 分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓存中获取就有值了，而不会继续访问数据库。当修改或者新增改 key 的数据信息的时候，需要删除或者更新 null 缓存值**

存在的问题：

1. 需要更多的键，所以通常设置较短过期时间

2. 缓存层和存储层数据"短期"不一致

借用图：高可用架构

布隆过滤器：

对所有可能查询的参数以 hash 形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。例如 Redis 可以使用 bitMap 来实现布隆过滤器。

借用图：高可用架构

缓存击穿问题

【单个热点 key 失效时，高并发查询数据库】

一个存在的热点 key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到数据库，造成瞬时数据库请求量大压力骤增。

解决方法

使用分布式锁

保证在分布式情况下，使用分布式锁保证对于每个 key 同时只允许只有一个线程查询到后端服务，其他没有获取到锁的权限，只需要等待即可；这种高并发压力直接转移到分布式锁上，对分布式锁的压力非常大。获取到锁的请求将数据写入成功到 redis 中， 通知没有获取锁的请求直接从 Redis 获取数据即可

使用本地缓存（双级缓存）

双击缓存机制

热点不过期

设置热点数据永不过期或者异步延长过期时间；

**到期前的续命

(在 value 设置一个比过期时间 t0 小的过期时间值 t1，当 t1 过期的时候，延长 t1 并做更新缓存操作。)

缓存雪崩问题

缓存雪崩是指，由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务（可能是机器宕机或大量的缓存(key)在同一时间失效 - 过期），于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

场景【多个 key 同时失效，高并发查询数据库】

缓存雪崩指缓存服务器重启（没有持久化）或者大量的缓存集中在某个时间段失效，突然给数据库产生了巨大的压力，甚至击垮数据库的情况。

解决方案

1. 对不用的数据使用随机动态分布的失效时间

2. 使用集群化分摊部署我们 key

3. 使用二级缓存

4. 使用分布式锁

5. 数据预热：可以通过缓存 reload 机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀

6. 依赖隔离组件为后端限流并降级 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。