缓存预热

​ 缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据，大大减少数据库的查询压力。

缓存雪崩

​ Redis主机挂了，导致Redis全盘崩溃，比如缓存中有大量数据同时过期。

​ 如何解决呢？

​ 1、监控redis服务器的性能指标。

​ 2、构建多层的缓存机构，在nginx缓存下面做redis缓存，在redis缓存下面在做ehcache缓存。

​ 3、redis缓存集群要实现高可用，可以使用主从 + 哨兵模式，或者Redis Cluster。

​ 4、数据库的性能也要优化，把数据库里面的超时查询和耗时比较高的事务想办法优化。

​ 5、开启Redis持久化机制aof/rdb，能尽快恢复缓存集群。

​ 6、要做好降级措施，如果出现缓存雪崩，要有兜底机制。可以限流、降级，短时间范围内牺牲一些客户体验，限制一部分请求访问，降低应用服务器压力，待业务低速运转后再逐步放开访问。

​ 7、LRU和LFU进行切换，LRU和LFU可以保证删除数据的时候不要去淘汰按照时间淘汰的，要去淘汰按照访问次数的。

​ 8、调整有效期的策略，例如把商品和热点新闻，我们把他们的错峰时间分开，不要让他们一次性全崩，过期时间使用固定时间+随机值的形式，稀释集中到期的key的数量。

​ 9、定期做维护，对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时。

缓存击穿

​ Redis中某个key过期，该key访问量巨大，多个数据请求从服务器直接压到Redis后，均未命中，在短时间内发起了大量对数据库中同一数据的访问，数据库压力暴增甚至崩溃。热点key突然失效，大量请求打到了MySQL上。

​ 如何解决呢？

​ 1、预先设定：以电商为例，每个商家根据店铺等级，指定若干款主打商品，在购物节期间，加大此类信息key的过期时长。注意：购物节不仅仅指当天，以及后续若干天，访问峰值呈现逐渐降低的趋势。

​ 2、对于访问频繁的热点key，可以设置长一点的失效时间或者不设置过期时间。

​ 3、后台刷新数据：启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失。

​ 4、差异失效：设置二级缓存，主A从B，更新时先更新B再更新A，查询时先查询A再查询B，如果A没有（消失或者失效）再查B。设置A、B不同的失效时间，保障不会被同时淘汰。

​ 3、互斥独占锁防止击穿，不建议使用，在高并发情况下性能低下。

缓存穿透

​ 请求查询一条记录时，先去redis再去mysql都查询不到该条记录，但是会有大量这样的请求，每次请求都会打到数据库上去，导致数据库压力暴增甚至崩溃。**Redis中大面积出现未命中，出现非正常URL访问。**比如，查询根本不存在的数据、Redis获取到null数据未进行持久化，直接返回、出现黑客攻击服务器。

​ 如何解决呢？

​ 1、缓存null，对查询结果为null的数据进行缓存（长期使用，定期清理），设定短时限，例如30-60秒，最高5分钟。

​ 2、白名单策略，提前预热各种分类数据id对应的bitmaps，id作为bitmaps的offset，相当于设置了数据白名单。当加载正常数据时放行，加载异常数据时直接拦截（效率偏低）。

​ 3、实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比，然后使用黑名单进行防控（运营）。

5、key加密，问题出现后，临时启动防灾业务key，对key进行业务层传输加密服务，设定校验程序，过来的key校验。例如每天随机分配60个加密串，挑选2到3个，混淆到页面数据id中，发现访问key不满足规则，驳回数据访问。