缓存雪崩

数据未加载到高速缓存中，或者高速缓存同时在较大区域中失效，这将导致所有请求都去查找数据库，从而导致数据库CPU和内存负载过高，甚至会出现宕机。

比如雪崩的一个简单过程：

1、redis集群大面积出现故障

2、缓存失效了，但是依旧会有大量的请求访问缓存服务redis

3、redis大量失效后，这个时候大量的请求转向到mysql数据库

4、mysql的调用量暴增了，一下子就扛不住了，甚至直接宕机

5、由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站完全崩溃

如何预防缓存雪崩

1.缓存的高可用性

高速缓存层设计为高可用，以防止大面积的高速缓存故障。 即使是个别节点、个别机器甚至机房宕掉，仍然可以提供服务。 例如，Redis Sentinel和Redis Cluster已实现高可用性。

2.缓存降级

可以使用诸如ehcache(暂时支持)之类的本地缓存，但主要是限制对源服务的访问，资源隔离(熔断)和降级。 当流量高峰和服务出现问题时，仍然需要确保服务仍然可用。 系统可以根据一些关键数据自动降级，也可以配置开关实现人工降级，在这一块会涉及到运维的配合。

降级的最终目的是保证核心服务可用，即使是有损的。

比如推荐服务中，很多都是个性化的需求，假如个性化需求不能提供服务了，可以降级补充热点数据，不至于造成前端页面是个大空白。

例如，在推荐服务中，很多都是个性化的需求， 如果个性化需求无法提供服务了，那就可以降级和补充热门数据，这样子就不会造成前端页面出现空白页面。

在降级之前，需要对系统进行梳理，例如：哪些企业是核心(必须保证)，哪些企业可以暂时忍受不提供服务(使用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案，比如：

(1)一般：例如，某些服务可能由于网络抖动或服务正在上线而超时，这些服务可以自动降级；

(2)警告：某些服务的成功率会在一段时间(例如95到100％之间)之间波动，可以自动降级或手动降级并发送告警；

(3)错误：例如，如果可用性低于90％，或者数据库连接池被打爆了，或者访问数量突然增加到系统可以承受的最大阈值，则可以根据情况自动降级或手动降级；

(4)严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

3.Redis备份和快速预热

1)Redis数据备份和恢复

2)快速缓存预热

4.提前演练

最后，建议在项目上线之前，演练缓存层宕掉之后，应用程序和后端负载情况以及可能出现的问题，对高可用提前预演，并提前发现问题。

缓存穿透

缓存穿透是指查询不存在的数据。 例如：缓存中的redis未命中，您需要从mysql数据库中查询，如果找不到数据，则不会将其写入缓存中。 这将导致每次请求该不存在的数据都将查询到数据库，从而导致缓存穿透。

解决思路：

如果查询数据库也为空，则直接为缓存设置默认值，以便第二次从缓存中获取该值时，它将具有该值，就不会继续访问数据库。 设置一个过期时间或在有值时替换高速缓存中的值。

可以为key设置一些格式规则，然后在查询之前过滤掉不符合规则的key。

缓存并发

并发是指由多个Redis客户端同时set key引起的并发问题。 实际上，redis本身是一个单线程操作。 多个客户端同时运行，按照先到先执行的原则，先到的先执行，其余的阻塞。 当然，另一种解决方案是将redis.set操作放在队列中以对其进行序列化，该操作必须一个接一个地执行。

缓存预热

缓存预热是在系统上线后将相关的缓存数据直接加载到缓存系统中。

这样就可以避免在用户请求的时候，先查询数据库，然后在用户请求时缓存数据的问题！ 用户直接查询预热的缓存数据！

解决思路：

1、直接写个缓存刷新页面，上线时手工操作一下；

2、数据量不大时，可以在项目启动的时候自动进行加载；