【架构-18】缓存雪崩？缓存穿透？缓存击穿？

缓存雪崩和击穿主要是因为数据不在缓存中了,而缓存穿透则是因为数据既不在缓存中,也不在数据库中。

缓存击穿

缓存击穿：少量热点的key缓存时间失效了
说白了，就是某一个热点数据，缓存中某一时刻失效了，因而大量并发请求打到数据库上，就像redis被打了一个窟窿，被击穿了一样，此时，该数据redis中没有，数据库中才有。

缓存击穿解决策略

1.双key策略：主key设置过期时间，备key不设置过期时间，在主key过期时使用备key并更新两者的数据。
2.设置热点数据不过期。
3.在更新数据库时，同时更新key
4.每次获取key都检查，key 还有多久过期，如果快过期，则更新这个 key

缓存雪崩

缓存雪崩：大量的key是已存在的，但同时失效了
当某⼀时刻发⽣⼤规模的缓存失效的情况，例如缓存服务宕机、大量key在同一时间过期，这样的后果就是⼤量的请求进来直接打到DB上，可能导致整个系统的崩溃，称为雪崩。

缓存雪崩解决方案

1.构建高可靠集群：提高系统的容错能力以防止单点故障。
2.分散过期时间：为了避免大量的缓存在同一时间过期，可以把不同的 key 过期时间随机生成，避免过期时间太过集中。
3.熔断降级：服务熔断：当缓存服务器宕机或超时响应时，为了防止整个系统出现雪崩，暂时停止业务服务访问缓存系统。
服务降级：当出现大量缓存失效，而且处在高并发高负荷的情况下，在业务系统内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的 fallback（退路）错误处理信息。

缓存穿透

缓存穿透：大量的key在redis里是不存在的
缓存穿透是指要访问的数据既不在 Redis 缓存中，也不在数据库中，导致请求在访问缓存时，发生缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据。此时，应用也无法从数据库中读取数据再写入缓存，来服务后续请求，这样一来，缓存也就成了“摆设”。

缓存穿透解决方案

1.布隆过滤器，在查询缓存之前先判断查询的key是否存在于布隆过滤器中，如果不存在则直接返回。
2.接口校验，在请求入口的前端进行请求检测，验证数据的合法性。